Moving to Cloud: the Landing Zone

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.

Resources:

• AWS Landing Zone was very recently announced and promises a starting point for many of the aspects covered in this article. At the time of publishing, the AWS Landing Zone was not yet publicly available. It features a number of interesting services including the Account Vending Machine and anInfrastructure (Code) Pipeline
• Setting up Consolidated Billing and Linked Accounts via AWS Organizations is essential when operating a multi-account Landing Zone set-up. The process is fairly straightforward and it’s even possible to create accounts from AWS Organizations without having to go through the usual account creation process.
• Preparing for Cloudformation cross-account StackSets is strongly recommended for a consistent cross-account set-up. Pre-baked roles and policies to enable StackSets can be found at Prerequisites: Granting Permissions for Stack Set Operations
• Starting point for monitoring and alerting on API access via CloudTrail (unauthorized access attempts, login failures and create/update/delete operations on some resources); Example Cloudformation Template
• One could do worse than start with the UK-OFFICIAL management and environment VPC blueprint, which includes a set of ready-to-go templates for standing up the VPCs. However, some caveats include: this set-up utilises only a single AWS account (one may want to stand up the management VPC in a shared services account) and egress traffic is unbounded via NAT Gateways per default
• One can utilise cross-account roles for Developer, Tester, DBA & Operations API access (just like the Console) for better security posture, e.g. via the AWS CLI. The CLI facilitates both MFA and token caching so that one doesn’t have to type in an MFA code at each call
• New Multi-Account, Multi-Region Data Aggregation Capability in AWS Config
• Automate Amazon GuardDuty Provisioning Over Multiple Accounts and Regions with AWS CloudFormation StackSets Integration
• There are a bunch of relevant Cloudformation templates available in the AWS Labs github repository. Cloning it and grepping for areas of interest is highly recommended when starting with something new.