Creating a Landing Zone concept from scratch that will cater to all current and future organizational needs can be intimidating. Five areas are essential for all organizations, big or small, to build an AWS foundation that scales. We will discuss them in this section, starting with the multi-account structure.
Defining a structure for organizational units and accounts
At the core of your Landing Zone design is an account structure that enables an organization to move fast, enforce granular controls, establish isolation boundaries, and reduce blast radius, while remaining flexible to future changes. So far in this chapter, we have discussed quite a few areas that benefit from a multi-account structure. All of this aligns well with the AWS Organizations service offerings, which help you manage your entire AWS landscape under the same umbrella. It gives you organizational controls that are otherwise difficult to establish, and maintain, across many discrete AWS accounts that act as independent entities. So, enabling AWS Organizations is essential if you don’t leverage it already. Available at no charge, it gives you immediate benefits around consolidated billing, service integrations, policies to centralize service usage control, and grouping your accounts for budgetary and compliance needs. Let’s discuss them in more detail and highlight some best practices as we progress.
Grouping accounts for compliance and regulatory needs
Organizational units (OUs) are an AWS Organizations feature that allows you to amalgamate multiple AWS accounts into one logical entity. It’s a soft structure that can be used to groupcertain accounts that exhibit the need for similar governance and control. For example, there might be a subset of enterprise applications that are regulated by the Health Insurance Portability and Accountability Act (HIPAA), and as a result, might not allow usage of certain AWS services. It’s easy to group these accounts, form an OU, and enforce policies at the OU level, which are then inherited by all accounts. Furthermore, any other AWS account that gets placed in this OU, even in the future, automatically follows the same rules, thereby ensuring continuous compliance. As another example, some companies might want to group all their dev workload accounts together so that they can apply certain policies that block the usage of high-cost compute. Keeping custom requirements aside for a moment, certain OUs apply to the majority of organizations, as covered here:
- Shared services OU: This OU contains the platform services’ accountsthat would be consumed by all other AWS accounts, basically a shared resource. It is common to host systems such as Active Directory, network appliances, or proxy services in this OU (in dedicated accounts) that can only be accessed by authorized personnel.
- Security OU: This is where you group yourAudit and LogArchive accounts, which external auditors and in-house security teams will have access to. All platform logs coming from CloudTrail and Config should be pushed into the central LogArchive account, as a best practice, so that they can be independently analyzed by Security Information and Event Management (SIEM) systems for threat detection purposes.
- Automation OU: A while ago, we slightly touched upon the need for deployment frameworks that make the Landing Zone concept a reality. It’s a good practice to host an independent Automation account in this OU, which contains the frameworks responsible for rolling out resources across all other accounts, in an automated fashion. Since this account has privileged access to almost every other account in the organization, access is generally limited to the tools that manage the entire AWS landscape. Human access, if any, should be actively monitored.
- Maintenance OU: Once the security and regulatory policies have been applied to an OU, it’s difficult to sometimes carry out maintenance procedures on the accounts contained therein. Therefore, it’s recommended to create a maintenance OU that temporarily hosts all the AWS accounts that need to be prepared for a specific need or operated upon. A common use case is to enable AWS opt-in regions by placing the AWS account in this OU. Normally, this would be a restricted action across all OUs and accounts as users could enable regions that might break the compliance posture of the company. Once the regions are enabled, accounts are placed back into their original OU. Think of this OU as apit stop, used in racing competitions for minor servicing and refueling. As a security measure, it’s also important to revoke permissions from all other AWS users that allow them to manually move any account into this OU, as that would immediately lift all the restrictions by which the accounts were otherwise blocked.
- Suspended OU: All suspended AWS accounts remain in the same state for 90 days, as a cool-off period, before they are removed. As a security measure, this OU restricts all actions in these accounts to prevent any additional billing or unauthorized usage.
- Development OU: Striking the right balance between security controls and agility is key to innovation. Organizations often enforce a standard set of policies and controls across all AWS accounts, which holds back developers from testing new ideas and innovating in the cloud. As AWS puts it, a good Landing Zone design follows the Guardrails, but not blockers principle. Therefore, it is important to create a dedicated OU where individual developers or team accounts can be hosted acting as the innovation space. You can still apply certain budgetary constraints on these OUs and block IAM actions that could hinder the security posture of the organization.
Having covered the most important OUs in any Landing Zone, let’s see what an OU setup would look like for a huge organization that has dedicated teams specializing in different areas of the technology stack, and application workloads that need to adhere to regulated standards such as HIPAA.