CLOUD LANDING ZONE
Cloud landing zone
A large enterprise hit scaling problems as cloud adoption grew. Manually triggered deployment scripts no longer kept up with the number of accounts and environments. There was no deployment history, and Infrastructure as Code was used sporadically and not enforced.
AWS landing zone
An AWS landing zone built for a footprint that grows account by account.
Automated deployments
Manual and scripted deployments replaced with a versioned, automated pipeline.
Infrastructure as Code
CloudFormation-based infrastructure with deployment history and version control.
Central management
Cloud infrastructure managed centrally across all accounts and environments.
Security baseline
A central security baseline applied to every account and resource by default.
Self-service cloud
A self-service platform that lets teams provision resources within the guardrails.
01Summary
The customer needed a central definition of their entire public cloud platform as code: a textbook Infrastructure as Code mandate, plus a versioned deployment pipeline. A cloud landing zone would let cloud usage grow without adding management overhead for each new account or resource. The pipeline had to provide its own assurance of conformity and security for the landing zone’s automation.
02The challenge
We started by mapping the current deployment practices in detail, so the new landing zone would cover everything already in production. The new architecture took the existing features and added a GitOps way of working: every change to the platform or its components starts from the code repo as the single source of truth. The AWS landing zone framework was used as the base for the design.
Several baseline resources used AWS APIs that CloudFormation could not call directly. We worked around this with custom resources, which required careful design of CREATE, UPDATE and DELETE so the stack stayed idempotent on every run.
A few baseline resources had to coordinate with the core accounts. To keep the baseline resources immutable and idempotent, the work was done through cross-account IAM roles, leaving each baseline definition self-contained.
The existing repository did not integrate well with the available CI/CD tools, so the code was moved to a self-hosted GitLab server. From there, GitLab’s native CI/CD ran the deployment pipeline, with a few custom components for the customer’s specific cases.
03The solution
The finished landing zone gave the customer a simple way to provision new accounts: an Account Vending Machine. This is a collection of Lambda-backed custom resources that creates AWS Organization accounts with a baseline of AWS resources, including:
- Managed account access via ADFS single sign-on.
- A choice of default network topologies, e.g. a VPC with two private and two public subnets.
- AWS Config rules, IAM boundary policies and GuardDuty as baseline security.
The Account Vending Machine ships as an AWS Service Catalog product, so it can be shared with nested Organisational Units. Other business units provision new accounts themselves while the security baseline still applies. Updates to the AVM’s baselines roll out automatically to every account that uses it.
AWS, Azure
Design, Plan, Build
Everything in code: speed, consistency, repeatability
Centrally managed cloud infrastructure
Self-service cloud
Centralised security baseline
Read about our cloud landing zone service
Landing zones bundle cloud configuration: security, compliance, IAM/RBAC, networking, billing, logging, monitoring and auditing, plus the products that support specific workloads. They are delivered with Infrastructure as Code, so deployments are consistent and repeatable.
Read the service