Moving to Cloud: the Landing Zone

By Morten Jensen

| 6 minutes read

In military terms a Landing Zone is an area where aircraft can land; in effect a base camp from where operations can extend.

AWS has for the last year or two used the term Landing Zone to convey an infrastructure foundation and security baseline on which applications and services can “land”. The applications inherit & adopt a set of shared services, integration and design patterns. The purpose of the Landing Zone is to establish an organisational baseline that supports its requirements for infrastructure and security and is rooted in “best practices”, which seek to balance business and security risks against innovation and value.

The foundation generally includes:

  • A Multi-Account structure that is linked with AWS Organizations and Consolidated Billing
  • Central root account management and break-glass procedures for all accounts using hardware MFA tokens
  • Central authentication & authorization between accounts (from a single Shared Services account), using cross-account roles and IAM users & groups to map to those roles
  • A set of security and audit enablers, including CloudTrail in all accounts/regions and replication of the trails to a central Security & Logging account
  • A set of central alerting enablers such as SNS topics and integration to alerting/messaging platforms (for instance SMS, email to mailing groups like Google - or even Slack)
  • Two sets of VPC patterns; one for shared services and management access (bastion, proxy etc.) and one for each environment; perhaps each environment is also hosted in a separate account
  • An application/services environment account structure that isolates Software Development Life-cycle environments by VPC and/or account; perhaps even by service/application
  • Integration with On-Premise Data Centres via VPN - either environment-by-environment or perhaps via the use of a central Transit VPC account, which acts either as Proxy or Routing
  • Centralised Bastion and VPC peering from e.g. Shared Services to environment accounts for centralised SSH access where warranted
  • Cloudwatch Dashboards for Infrastructure metrics

It is important to note building a full Landing Zone from scratch is no easy feat. It’s therefore important to start off in small bites and evolve the Landing Zone over time. A suggested priority order is this:

  • Decide on a suitable AWS account structure: Shared Services, Security & Logging and a number of environment accounts. Create an AWS account and continue any further account creation via AWS Organizations.
  • Establish as set of bootstrap IAM users, groups and roles that will support the Infrastructure/DevOps team and initial Developers, Testers, DBAs and Operations staff
  • Use AWS Cloudformation Stack-Sets to rollout common resources and configuration for e.g. CloudTrail, Cloudwatch and Config across all of the accounts. The advantage of Stack-Sets is that adding another account to the Landing Zone is very straightforward
  • Enable CloudTrail and Config in all accounts and regions and copy trails and config to a central account
  • Establish an Infrastructure (Code)pipeline to automatically rollout infrastructure changes across the accounts

The Landing Zone security baseline should also include considerations and tools like:

  • VPC FlowLogs and NACLs (Network Access Controls).
  • Configuration management and tracking across all accounts, e.g. using AWS Config - with monitoring of baseline rules through AWS Config Rules
  • Regular use of Trusted Advisor (with Business Support) for security and cost optimisation recommendations
  • Monitoring & Alerting; Consider alerting endpoints like Slack, which offer mobile push notifications and a collaborative space to work on issues
  • GuardDuty for threat detection where the VPCs are public facing or are connected via VPNs to on-prem or 3rd party Data Centres and services
  • Blast radius limitation. Things to consider are whether development and test environments should be publicly accessible. Consider using AWS CloudFront with WAF to whitelist access; similarly Application Load Balancers can also have whitelisted IP access (e.g. from Cloudfront only)
  • Encryption requirements; encrypt data at rest (EBS volumes, RDS storage, S3 objects and Cloudwatch Logs ) and in transit (TLS/SSL between client and app/service). Consider whether encryption keys should be managed from a central account, which makes other accounts consumers (only) of the keys without means to delete the keys
  • Data Exfiltration & malware phone-home mitigations. For instance using an Egress Proxy (as opposed to NAT Gateways that have unrestricted outbound routing) like Squid to whitelist domains and IP addresses for read-only and rewrite activity. Whitelist egress traffic for e.g. operating system updates etc. For outbound traffic exceptions consider replacing NAT Gateways with NAT instances because NAT instances can have Security Groups assigned to them
  • Developer, Tester, DBA and Operations access. Workspaces can be an excellent option for facilitating access to AWS that is “out-of-band”, i.e. there’s no need for bastion or Internet access to facilitate access.

Establishing a good Landing Zone foundation is important in order to avoid sprawl, inconsistency and security concerns when it comes to migrating or rolling out services in AWS. Below is a list of relevant Landing Zone resources for getting started on the Landing Zone journey. The list includes AWS announcements and links to predefined templates that are a good starting point.