It is a talk regarding how AWS is utilized to manage around 200 services, 4+ million users and 20+ teams in Posti Group. The speaker will demonstrate how Posti is maintaining and controlling the ‘Infrastructure side’ of a variety of different cross-functional teams, with a unified approach. The presentation will focus on the approach, tools and tech with some concrete examples. It should be fairly comprehendible even for non-hands on IT professionals, however aimed at Software engineers, Infra and DevOps engineers and IT leaders.

1. INFRASTRUCTURE AND AWS AT SCALE
The story of Posti
by Goran Gjorgievski, 2023

2. ABOUT POSTI
01
PROBLEM
02
SOLUTION
03
Q&A
04
Agenda

3. ”PLATFORMS ARE A MEAN OF
CENTRALIZING EXPERTIZE, WHILE
DECENTRALIZING INNOVATION TO THE
CUSTOMER OR USER.”​
Peter Gillard-Moss, Thoughtworks​

4. •
•
•
•
•
•
•
Head of Software @ Posti Group
Technical advisor and leader
Living in Helsinki, Finland
10 years of experience in Software engineering
Currently overviewing: approx. 22 teams, 80 FTE
engineers
Tech: Typescript, React, GraphQL, Apollo, Python,
AWS, AppSync, etc.
Industries: Parcel & Logistics, Satellites, Streaming,
Healthcare, Finance “Insert fancy quote here.”
Goran Gjorgievski, Head of
Software
MEET GORAN

5. Posti Group
https://www.posti.fi/en
MEET POSTI
We are the leading postal and logistics service company
in Finland. Our core business includes parcel and e-
commerce services, postal services, freight and other
logistics services. ​
•
•
•
•
•
•
Net sales EUR 1 595 million (2021) ​
~21 100 employees​
~200 000 business customers​
Owner: The State of Finland​
Founded in 1638​
Operations in 7 countries:
Finland, Sweden, Norway, Estonia,
Latvia, Lithuania and Poland

6. MEET POSTI

7. MEET POSTI

8. TECH HUB AT POSTI

9. different services
200+
different teams
50+
repositories
1000+
•
•
•
•
•
•
•
Establish a standard unified way of infra
throughout all the teams
Decentralize knowledge
On demand scaling: environments,
instances, resources, services and more
Cross-team collaboration and shared
services
Integrations and isolations
Billing and business processes
Maintenance, security, logging, disaster
recovery, development practices, … the list
goes on.
THE PROBLEM(S)

10. RANDOM BASIC INFRA

11. FEW ADDONS
•
•
•
Availability Zones
Logs
CI/CD pipelines

12. MORE ADDONS
•
•
•
•
Availability Zones
IAM
Few microservices
CI/CD pipelines

13. SCALE IT UP
•
•
•
•
multiple teams
multiple environments
multiple services
Infra/DevOps team

14. 1.
2.
a.
b.
c.
d.
3.
4.
5.
6.
How do you track billing, map it to business units and
teams?
Who maintains this AWS infrastructure?
How to quickly scale when:
A new initiative(project) appears
Teams merge or divide
A service needs to be 'killed'
Enable developers to be able to participate
Keep history track of changes and disaster recovery
Address different needs from different teams
…
BACK TO THE
PROBLEM(S)

15. AWS
LANDING
ZONE
A landing zone is a well-architected, multi-account AWS
environment that is a starting point from which you can
deploy workloads and applications. It provides a
baseline to get started with multi-account architecture,
identity and access management, governance, data
security, network design, and logging.

16. Dark old days*
1.
2.
3.
4.
5.
Single AWS account
Split DEV/PRD with VPC
Basic IAM and policies for access
controls
Billing consolidation, tags and fun
:)
IaC begginings
Dark not so old days
1.
2.
3.
4.
5.
Multi account
1 Admin account & N linked
accounts
Billing consolidated under the
admin account
manual creation
IaC presence
ReInvent 2016
1.
2.
3.
AWS Organizations
Automated account creation
Custom automation scripts by
Infra and DevOps engineers
AWS LZ HISTORY
*Spending the night in server or rooms remote management, HYPER-Vs, physically VMs, etc. is not taken into account

17. AWS (2018)
1.
2.
3.
LZ 1.0: automated solution for
deploying best-practice AWS
accounts, security, logging,
identities.
Editing was challenging: iterate
through CloudFormation
templates with 1000s of lines of
code
Rollback of a deployment was a
no-go
AWS LZ v2.0
1.
2.
3.
Fixed most of the bugs, issues
and problems with LZ2.0. Coming
6 months later.
Upgrade from v1→v2 a challenge
CloudFormation templates
worked better
AWS Control Tower (2019)
1.
2.
Does everything AWZ LZ v2.0
does, with abstraction
Managed service, harder to
customize but possible with AWS
Control tower customizations
AWS LZ HISTORY

18. •
•
•
•
•
•
•
•
•
In the middle: we want the flexibility and we want the LZ2.0
Sceptre for orchestrating CloudFormation
Stateless
Yaml templates
Python support
CLI is few commands
Easy to integrate with your CI/CD (Posti uses Github Actions)
Learning curve is steep
Not 'everything' is automated, you have control
WHERE IS POSTI?

19. ├── config
│ └── dev
│ ├── config.yaml
│ ├── subnets.yaml
│ └── vpc.yaml
│ └── prd
│ ├── config.yaml
│ ├── subnets.yaml
│ └── vpc.yaml
└── templates
├── subnets.py
└── vpc.py
HOW DOES IT LOOK
LIKE?
$ sceptre create dev/subnets.yaml
dev/subnets - Creating stack
dev/subnets Subnet AWS::EC2::Subnet CREATE_IN_PROGRESS
dev/subnets Subnet AWS::EC2::Subnet CREATE_COMPLETE
dev/subnets sceptre-demo-dev-subnets AWS::CloudFormation::Stack
CREATE_COMPLETE
•
•
•
•
Organizes "Stacks", e.g. CloudFormation templates, into "Stack
Groups", e.g. Environments
Stacks are .yaml configs
You can chain "Stack" result with another "Stack" command
Sceptre is based on meta-operations, e.x.:
- LogicalResourceId: Subnet
- PhysicalResourceId: subnet-445e6e32
Cross-stack dependencies are possible

20. HOW DOES IT LOOK
LIKE?

21. HOW DOES IT LOOK
LIKE?

22. OVERVIEW - ORGANIZATION LEVEL

23. OVERVIEW - TEAM LEVEL

24. THANK YOU
Q&A