Governance, risk, and compliance when establishing your cloud presence

June 22, 2021: We’ve updated this post to reference the recently published Management & Governance Lens, an extension of the AWS Well-Architected Framework.

When speaking with the business and technology leaders I work with, they express the need to bring new products and services to market quickly. They must also stay secure while doing so. At the same time, they must maintain a resilient environment while adapting workloads to changing business needs over time. In this multi-part blog series, I share AWS best practices to help our customers plan their AWS environments to meet these security, scalability, and adaptability requirements.

Recently, AWS published the Management and Governance Lens, an extension of the AWS Well-Architected Framework. The M&G Lens provides a set of prescriptive guidance collected from thousands of migrations and activation days. From this work, we learn about how to manage and govern so that you have migration ready, scale ready and optimized for efficiency cloud ready environments. My goal is to guide customers in design considerations for managing their cloud presence. This series will be followed by additional blog posts that guide the implementation of common use cases and patterns aligning with this guidance.

Introducing a landing zone

As more teams adopt AWS within a customer’s company, separation of concerns becomes both more difficult and important. Businesses must ensure that different users, business units, and product teams do not interfere or negatively impact one another with environmental changes. Their costs are budgeted and allocated to the appropriate cost centers. That security is implemented appropriately based on the sensitivity of individual workloads and the scope of impact stemming from security and operational events is limited. Customers need resource containers to enforce isolation across their AWS environments in a secure and repeatable manner. As customers grow their presence and scale, they need a mechanism to manage and orchestrate these resource containers – this is called a ‘landing zone.’

A landing zone is a well-architected, multi-account AWS environment that is scalable and secure. It represents a starting point for your cloud migration journey. A landing zone at AWS is built on AWS Organizations and multiple AWS accounts. AWS Organizations provides the management and organization of those AWS accounts into logical groupings. Individual AWS accounts provide isolated resource containers with independent billing, user identity and access management. They also contain network boundaries that, by default, do not have access to resources in other AWS accounts.

To manage a large number of AWS accounts in your landing zone, a best practice is to use a foundational set of accounts for operational services. For example, security monitoring, network transit to on-premises hybrid environments, and log archival services are common needs across a landing zone.

Framework for establishing your landing zones

This guidance for establishing your landing zone is based on input from various AWS teams, best practices derived from customer feedback and interactions. This multi-account framework provides the level of isolation necessary to secure your AWS environment, while also allowing your operations to scale and adapt to organizational change as needed.

You use AWS Organizations to group AWS accounts based on function into two categories of organizational units (OUs): Foundational and Additional. An OU is a way to group AWS accounts based on common security policy requirements. The Foundational OUs are shared services (such as security log archival, networking) that provide functionality required across all of your AWS accounts and are typically the responsibility of central teams. They are building blocks for establishing the rest of the accounts structure. The Additional OUs are for establishing the customer overall environment and have dependencies on the Foundational OUs.

The Foundational OUs are further categorized into two groups: Infrastructure OU and the Security OU. Infrastructure OU accounts are used for shared services across your AWS Organization for things like shared IT services and networking infrastructure. The Security OU accounts are used for centralized security services, such as log archival, security tooling, and break-glass / forensics.

The Additional OUs are aligned with business use-cases. For example, a Sandbox OU is used for enabling individual developers to have their own accounts to experiment and test new services or products. A Workloads OU may be used to isolate and tightly control production workloads / application services.

The OUs should be seen as a guide for implementation rather than explicit requirements. You may have more or fewer OUs defined within your AWS Organization depending on business needs and operational maturity. And, you may adapt some of the OUs that I recommend based on your unique use cases. I would love to hear from you on your approach so I can continually evolve this guidance and best practices based on your feedback.

For more information, read our best practices for using AWS Organizations documentation. The second part of this blog series provides additional details into recommended OUs within the multi-account framework.

Automating set up of your landing zone

As the number of AWS accounts in your landing zone grows, automation becomes necessary for efficient governance and management. In line with AWS philosophy, I believe you should use the right tool for the job and recommend two options to assist in you in the orchestration of your landing zones through automated means. The first is to use AWS Control Tower, an AWS managed service to set up and govern a multi-account environment that uses AWS Organizations and a number of other services to automate the orchestration. For those that are building out a new landing zone or prefer an easier solution without the need for heavy customization, AWS Control Tower assists you getting started quickly with centrally managed governance and best practices preconfigured. The second option is direct management through AWS Organizations for customers that need a high level of customizability and that are experienced in building tooling to manage their environments.

A future blog highlights the considerations for using either method to manage your landing zones.

Conclusion

Customers consistently express the need to move quickly and securely when launching new business innovations. The multi-account framework provides best practice guidance to help customers plan their AWS environment. The framework is designed to meet security needs, while maintaining the ability to scale and adapt their environments with changing business demands. This post of the blog series outlines the key business drivers for using landing zones.

Keep an eye out for the next three parts of the series that provide:

• Details into the multi-account framework OU structure.
• Key internal capabilities to properly implement and manage your landing zones.
• Considerations for the different options in automating your landing zone deployment.

About the Author

Brandon is a security solutions architect helping financial services organizations secure their critical workloads on AWS. In his spare time, he enjoys exploring outdoors and experimenting in the kitchen.