By Marc LeBlanc, DevOps Engineer at Onica and Joseph Johansson, DevOps Engineer at Onica.
AWS is constantly iterating and innovating to make it easier for people to succeed on the cloud. Previously, creating a safe and effective foundation for a migration required substantial cloud expertise and was a complex process. Cloud users would attempt to follow vaguely defined “best practices” before a single resource could be spun up safely. A lack of consensus on what really are the “best practices” and the complexity of preparing accounts led AWS to introduce the AWS Landing Zone in June 2018.
What is the AWS Landing Zone Solution?
The standards and architecture of the AWS Landing Zone solution are designed by AWS, based on their definition of best practices. Previously, many companies using AWS extensively would have to take great care in order to ensure they stayed within the guidelines of the AWS Well-Architected Framework or would have to refactor extensively to meet said guidelines. The AWS Landing Zone solution instead enables a business to start with a well-architected environment and maintain it as they grow.
The AWS Landing Zone solution includes the setup of AWS Organizations and a set of AWS accounts tasked with different parts of your overall cloud strategy. For example, a centralized logging account is set up that compiles CloudTrail logs for efficient analysis. A security account is set up to monitor your cloud resources across accounts using Amazon GuardDuty. A shared services account is provisioned for any services like Active Directory that need to be accessible across workloads. An Account Vending Machine is created as a Service Catalog product, enabling permitted users to create AWS accounts in an efficient and secure way. These accounts are created with integrations to the above AWS Landing Zone features automatically. All of these accounts are comprehensively billed in a central place without extra setup to provide cost controls. With the right configuration, the AWS Landing Zone solution can be a cost-effective way to move some workloads to AWS or to evolve existing workloads in AWS to a well-architected design.
Our Use Case
Based on all of the features that the AWS Landing Zone solution brings to the table, the product was a natural choice for our customer, a Software-as-a-Service (SaaS) vendor. In addition to ease of deployment, the AWS Landing Zone solution also simplified compliance with the customer’s regulatory requirements, including GDPR and PIPEDA. Further, the ability to give every developer the freedom and safety of a full AWS account drives increased developer productivity and innovation.
Having a better handle of what the AWS Landing Zone solution is and its benefits, we will now take a look at setting up a basic AWS Landing Zone deployment to get experience with the solution. A diagram of the finished architecture can be found here.
Step 1: Design
A good design goes a long way. You may find yourself deploying the AWS Landing Zone solution multiple times in a test Organization Master account to refine your design. Be sure to include in your design:
- The Organizational Units needed in the Organization and the Service Control Policies needed for each Organizational Unit.
- The list of Organization Member accounts you need to start with, noting that additional accounts can be created with the Account Vending Machine later.
- A naming convention for root user email addresses for the AWS accounts. If your email service supports it, you could create one email distribution group for the Organization, such as aws-[landing-zone-organization]@domain.tld, and use “+” alias email addresses for each Organization Member Account, such as aws-[landing-zone-organization]+[member-account]@domain.tld.
- A strategy for secure random generation, storage, and sharing of passwords and MFA tokens for the root user on each Organization Member Account.
Step 2: Increase Account Service Limits
There is a limit to the number of Member accounts in an Organization; this limit is not visible to the user, and the starting limit varies per AWS customer, so place an AWS support ticket from the Organization Master account to increase this service limit before you begin. It is also highly recommended to increase the account service limit on the number of AWS CloudFormation stacks you can have in each account.
Pro Tip: Hitting these limits during a deployment may cause issues that are challenging to troubleshoot, so ensure this is completed before starting the AWS Landing Zone deployment. Note that deleted accounts may still count towards this limit during the 90 day deletion waiting period, so be sure to request a limit high enough to include some head room for trial and error.
Step 3: Create Root User Email Addresses for Organization Member Accounts
With the power and flexibility provided by the Account Vending Machine, an effective naming convention for email addresses helps keep these root user accounts organized. You will need to receive emails sent from AWS to the root user on each AWS account. It is recommended to use email distribution groups with two or more members, instead of an administrator’s personal mailbox to maintain continuity of access. For the Security Notifications email address, use a separate mailbox that your security team can access.
Pro Tip: An email address can only be used for one AWS account root user at a time. If an AWS account is deleted, the email address cannot be reused for another AWS account. If you need to delete an AWS account, be sure to change the root user email address to an address that won’t be needed in the future, before requesting account deletion.
Step 4: Deploy the AWS Landing Zone Initialization AWS CloudFormation stack
The AWS Landing Zone Initialization AWS CloudFormation stack takes about 2 minutes for a successful deployment, then 1 – 4 hours for the AWS CodePipeline to complete. It is recommended to leave Rollback on failure enabled, and set a Timeout of 10 minutes instead of the AWS CloudFormation default of 60 minutes; the stack uses AWS CloudFormation Custom Resources backed by AWS Lambda functions, so if the Custom Resource fails to initialize, a shorter timeout and rollback on failure allows you to retry sooner.
Pro Tip: Subscribing to the “All changes” emails in the template results in thousands of emails, and is not recommended.
Step 5: Create Member Accounts with Account Vending Machine
1. Log into the Master Account
2. Navigate to the Service catalog
3. From the “Products List”, page click on “Launch Product” as in the picture below
4. Enter the values requested by the wizard based on the requirements of the account. These include account name, account email (see sections above), network configuration, and tagging options
5. Review all account details before pressing launch
6. Launch the product and wait for the provisioning to finish
Note: Each account that is launched with the Account Vending Machine can take up to 1 hour to provision.
Step 6: Secure Root User for All Organization Member Accounts
AWS generates a random password for the root user when a Member account is created by the AWS Landing Zone deployment or the Account Vending Machine, but this password is not provided to the user. Go through the account recovery process for the root user on each Organization Member account to set a password and configure MFA. While you go through this process, select a support plan for each Member account.
After going through the guide above you should have a baseline AWS Landing Zone set up. However, every business has different requirements and there are many other parts to a successful multi-account rollout. Below is a list of common tools, services, and settings used in multi-account setups that are not set up by default with the AWS Landing Zone solution.
AWS Single Sign-On (SSO)
AWS SSO enables easy and granular access to the various accounts that can be created via the AWS Landing Zone solution. AWS SSO can be used with either Microsoft Active Directory, or a built-in directory provided by AWS. The AWS Landing Zone solution includes an AWS Service Catalog product that implements AWS Managed AD (Enterprise Edition), AD Connector, and AWS SSO, or AWS SSO can be configured manually with the built-in user directory, or with an existing AD.
AWS Transit Gateway
AWS Transit Gateway provides a managed network hub to which other accounts’ VPCs can join as spokes. On-premises infrastructure can also be attached for an easier transition to the cloud or to provide access to legacy systems.
Amazon Route 53 + Route 53 Resolver
Route 53 Resolver along with Amazon Route 53 enable a more centralized DNS approach to a multi account environment. Enabling communication between account resources or even on-premises resources allows for an easier transition and greater service discovery.
The AWS Landing Zone solution offers a great degree of stability, security and flexibility to customers. If you think the AWS Landing Zone solution is right for your business and want someone to guide you through the intricacies above and other more complex scenarios involving the AWS Landing Zone solution, don’t hesitate to contact Onica.