Introduction
AWS Secure Landing Zone is crucial to addressing the rapid cloud adoption by enterprises and the expansion of AWS environments. A main driver for this is elastic scalability that cloud environments provide. Another key driver is the shift from capital expenditure to operating expenditure through consumption-based cloud services. However, these and other drivers led to organizations blindly leveraging cloud infrastructure with minimal planning and management. This has led to cloud resource sprawl within many organizations, accompanied by decentralized resource provisioning. Additionally, this has led to inconsistent security controls across many organizations, along with governance complexity growing exponentially. Other major concerns are reduced visibility across workloads and a growing attack surface. There is a growing need for standardized foundations as organizations adopt more mature cloud computing practices.
Why Cloud Security Starts with Architecture
The need for AWS Secure Landing Zone architecture has arisen due to the rapid expansion of AWS environments. This has caused different business units to create their own AWS Accounts and OU structures. This results in different ownership models, increasing organizational complexity with different teams having different compliance and security requirements. This is further exacerbated whenever there are mergers and acquisitions, with their own OU structures are imported into the cloud environment. Security issues that arise are inconsistent security controls, sliced security practices, and permission sprawl. These result in security gaps, making any security posture non-existent, exposing the environment to inevitable attacks. Other account governance challenges include resource configuration drift, operational inefficiencies, and increased management overhead. Therefore, there is a need for an architecture to address enterprise-wide governance and security standardization.
The Purpose of an AWS Landing Zone
It is necessary to establish a standardized cloud foundation to prevent inconsistent implementations due to different business units. Also, to reduce security gaps due to inconsistent security practices, it is critical to establish an enterprise security baseline. Since different business units have multi-account needs, it is essential to implement a multi-account governance model. However, the most important characteristic of an enterprise-wide environment is consistent architecture patterns enabling coherent management of the environment. This establishes security guardrails that prevent inconsistent security implementations across accounts. It also sets up compliance controls that enforce compliance standards across all resources and reduce compliance drift. The AWS Landing Zone establishes the architectural patterns that are consistently applied across the organization.
What Is an AWS Secure Landing Zone?
Core Definition
The AWS Secure Landing Zone is the foundational architecture upon which all subsequent AWS workloads are built and governed. This forms the enterprise cloud foundation that establishes the operational constraints on business units leveraging AWS. Furthermore, it standardizes the AWS environment to reduce variation, which is the source of compliance failures, operational inefficiencies, and security gaps. It comprises the set of architectural decisions, structures, and controls upon which all future workloads are built. This includes reusable architectural patterns and a cloud governance framework that allows a scalable cloud architecture through a consistent deployment model.
AWS Security Landing Zone establishes the governance foundations that regulate how business units within the enterprise leverage AWS. It enforces architectural standards for workloads that business units deploy on the AWS environment, including permissions and infrastructure architecture. With permissions, it establishes the foundations of identity management, centralizes authentication, and enforces authorization standards. For networking, it enforces workload isolation through networking foundations and enforces network segmentation. It also ensures observability by centralizing logging and enforcing monitoring capabilities across the AWS environment. The AWS Security Landing Zone establishes a consistent security posture by providing baseline security controls, enforcing preventive security measures, and establishing compliance foundations.
Why Enterprises Need an AWS Secure Landing Zone
Large enterprises use AWS, while other organizations that use AWS continue to grow and increase their use of AWS resources. They have multiple business units, resulting in multi-account environments, and when left unmanaged, AWS account proliferation occurs. However, organizations need multiple accounts since business units have diverse workload requirements. Therefore, they require autonomy bounded by constraints imposed across the organization through a governance model. Hence, the enterprise needs a centralized governance model implementing consistent controls and architecture.
Operational scalability is a core governance requirement since many organizations expand with additional business units, leading to cloud expansion. These cloud environments are often under scrutiny by stakeholders and regulators, and the governance model must facilitate their auditing. Significantly, the governance model must reduce risk and mitigate the security risks associated with unmanaged networks. Centralized management is a key requirement of enterprise cloud, making centralized observability a critical requirement as well. It must improve operational efficiency and ensure long-term maintainability.
Security Trade-Offs in an AWS Secure Landing Zone
There is a tension between business-unit and developer autonomy and the need to establish boundaries for their behavior in the cloud. Cloud-based businesses striving to be adaptable often find cloud guardrails inhibiting their need for flexibility. This tension is especially pronounced around security guardrails that often collide with the need for development groups to be agile. Enterprise governance requirements must ensure that there are no unnecessary constraints that inhibit businesses. This includes establishing a controlled self-service for teams to add workloads.
However, centralized governance brings many benefits that often outweigh the obstacles many teams face in the long term. The most important benefit is that it reduces security drift that inevitably exposes the cloud environment to attacks, often causing irreparable harm. Closely associated with this is reduced configuration drift, having both security and management implications. By enforcing standardized implementations and consistent deployments, it improves maintainability and makes operations predictable. Centralized governance promotes a strong security posture and reduces operational risk. Furthermore, by enforcing enterprise consistency, it ensures sustainable cloud growth.
Core Components of an AWS Secure Landing Zone
Enterprise cloud governance models are frameworks. An AWS Secure Landing Zone consists of components enabling business units to deploy workloads in a controlled manner while maintaining security posture.
AWS Secure Landing Zone Organizations and Organizational Units
The AWS Account is the fundamental unit of any governance framework. However, most business units’ workloads span multiple accounts, necessitating their logical grouping and centralizing their management. Organizational Units (OUs) group AWS Accounts that contains both AWS Accounts and other OUs. It imposes guardrails on all its members, and its member OUs will propagate these guardrails to their members. This hierarchy typically aligns with the organization’s business unit hierarchy. The entire hierarchy falls under AWS Organizations, which sets and enforces guardrails across the entire AWS organization hierarchy. These governance mechanisms are discussed in greater detail in AWS Organizations and Service Control Policies (SCPs).
AWS Organizations and the OU organization structure establish a hierarchical governance structure that propagates constraints down the hierarchy. Policies implement these boundaries and constraints, with each OU member inheriting the policies from its containing OU. Each AWS Account is typically a grouping of workloads, grouped for a common goal. The AWS Account imposes its own policies and those it inherited from its containing OU on its member workloads. In addition to resembling the organizational structure, OUs are grouped by environment, typically development, test, and production. This policy inheritance enables centralized enforcement of governance across the enterprise’s cloud environment.
AWS Secure Landing Zone Multi-Account Isolation
Workloads grouped according to a common purpose typically require minimal interaction with workloads grouped for a different purpose. Additionally, limiting a workload’s exposure to other workloads limits the potential reach of compromised workloads. Therefore, resource isolation is fundamental to securing workloads and resources within the enterprise cloud environment, as discussed in AWS Resource Isolation Security. An AWS Secure Landing Zone implements a multi-account architecture by mapping logically grouped workloads to their own AWS Account. The AWS Account is the security boundary that isolates them from faults, failures, and compromised workloads. The enterprise can then overlay independent security and governance controls over the multi-account architecture.
Multi-account architecture enhanced by OU and AWS Organizations hierarchy allows for workload separation across several dimensions. Business unit separation is a key dimension in which workloads sharing a common business or product function are grouped within an AWS Account. Another dimension is environment separation, which includes development, test, and production environments. This is critical for production environments that need to be isolated from developer experiments that can cause serious business disruption. Limiting workload exposure reduces security risk. Additionally, decoupling workloads allows for their independent lifecycle management, simplifying maintenance.
AWS Secure Landing Zone Identity and IAM Federation
Granting entities permissions to access AWS resources is another critical layer for limiting workload exposure. Entities typically include other workloads and members of the enterprise. Additionally, access to workloads should be short-lived. This prevents entities from accessing workloads when they have no need to do so, thereby limiting workload exposure. AWS implements this through IAM Roles, which provide authorization for resources.
Another key practice for preventing long-lived access by enterprise members is to separate their authentication from the authorization provided by IAM Roles. Additionally, authentication should be centralized to manage access by enterprise members. Typically, federation provides centralized identity management through a single sign-on service to control authentication. That identity can then assume IAM Roles granted to it.
This permission management framework enforces the principle of least privilege, minimizing resource exposure by limiting access. Centralizing identity management enforces identity governance, allowing boundaries to be set for granting permissions to entities. It also standardizes permission management across the enterprise and ensures consistency for access. This also enforces segregation of duties through role-based access control, simplifying identity management by decoupling authentication and authorization. Overall, it adds another layer to the enterprise security posture. These architectural principles are explored further in AWS IAM Architecture Best Practices.
AWS Secure Landing Zone Logging and Monitoring
An AWS Secure Landing Zone relies on centralized logging and monitoring to detect and respond to threats that bypass preventive controls. However, this risk is never eliminated, and observability is required to detect and respond to attacks. Logging and monitoring provide this observability, and these are aggregated and centralized for control across the enterprise cloud environment. Log aggregation improves security event detection since analysis tools have more details in event patterns. Centralized observability enforces consistency, reducing gaps and enabling coordinated response to any security incidents. A broader enterprise observability strategy is covered in AWS Logging and Monitoring Guide.
Aggregated and centralized logging and monitoring provide an integrated approach to understanding the health of the environment and to detecting and responding to incidents. Sophisticated tools using machine learning consume integrated observability data to alert operators of pending or occurring incidents. They are integrated with other tools that provide automated responses to these events, enabling isolation and remediation of impacted resources. Observability data is also used for forensics to identify any security gaps and improve detection and response. Organizations store this data long-term for auditing and evidence that the cloud environment is meeting regulatory requirements. For secure audit log retention, see AWS CloudTrail Logs to S3: Secure Setup & Best Practices.
AWS Secure Landing Zone Shared Services Architecture
There are many functions of the enterprise cloud environment that are common to all the business units. They are also common to development, test, and production environments. Implementing them separately for each business unit or environment introduces operational inefficiencies and potential security gaps. Therefore, implementing them as shared services addresses these inefficiencies by reducing duplication and fostering reuse. This enforces consistency across all the lines of business and reduces the risk of security gaps. Core services that are shared include identity management and security services, strengthening the security posture.
There are many key benefits to implementing common enterprise capabilities as shared services. Shared services support service reuse and reduce duplication, thereby improving cost efficiency. Furthermore, shared services consolidate the infrastructure needed to support these services, extending improved cost efficiencies. This introduces economies of scale through improved resource utilization, further boosting the efficiency of enterprise cloud environments. Another key benefit is that they centralize operations, simplifying cloud administration and reducing overheads, further improving efficiency. Associated with this is reduced management complexity and consistent service governance.
AWS Secure Landing Zone Network Segmentation
Network segmentation adds another layer of workload isolation, further reducing the ability for attackers to reach AWS resources. It is implemented as a Virtual Private Cloud (VPC) that complements trust boundaries implemented as AWS Accounts. Network segmentation isolates workloads by restricting network connectivity to minimal network paths with security controls on these paths. It achieves this by partitioning the enterprise cloud network into network segments and grouping workloads within them. Similar to AWS Account trust boundaries, network segmentation groups workloads according to their common function or purpose. These network segments typically map to VPCs and IP subnets.
The core security architecture principle is reducing the attack surface of workloads and resources. Sound architectures achieve this by maximizing workload isolation and allowing only the interactions necessary to achieve their business function. Network segmentation provides isolation for workloads, allowing only the network paths needed to complete business functions. It adds an additional layer of security by establishing security controls on these paths, as well as monitoring traffic on these paths. This significantly restricts lateral movement and reduces the attack surface in strengthening network security posture.
AWS Secure Landing Zone Guardrails and SCPs
Both large enterprises and complex systems have continual tension between centralized control and local autonomy. This maps to enterprise cloud environments where AWS Accounts need autonomy to fulfill their missions. However, enterprises need to impose restrictions to prevent a weakening of the security posture, unnecessary costs, or unnecessary complexity. Hence, guardrails are placed at all levels of the hierarchy that allow sufficient freedom within accounts while restricting activities detrimental to the enterprise. These also enforce consistency, reducing security and operational gaps, and secure the environment by default.
Enterprises implement guardrails through Service Control Policies (SCPs) that restrict permissions across the AWS Organizations hierarchy. SCP can be applied to both AWS Accounts and OUs. SCPs applied to an OU are inherited by all its members, including OUs and AWS Accounts. Each OU or AWS Account can implement SCPs in addition to the ones inherited from its parent OU. SCP guardrails are preventative, allowing enterprises to enforce restrictions across their cloud environments. This preventative framework reduces the risk of individual entities performing actions that could weaken an enterprise’s security posture.
Designing Security Boundaries in an AWS Secure Landing Zone
Accounts as Security Boundaries
Workloads with a common function are typically grouped within the same AWS Account, forming a security boundary around them. This isolates them from other enterprise workloads since there is far less need to interact with them than with each other. A business unit within an enterprise typically has one or more such workload groupings corresponding to AWS Accounts. These AWS Accounts are placed under an OU that corresponds to the business unit. Furthermore, these AWS Accounts enable the separation of administrative functions and resource ownership for workloads within their respective accounts. Additionally, AWS Accounts placed under an OU allow that business unit autonomy within the guardrails imposed on it.
The AWS Account serves as a security boundary for the resources and workloads within it. It isolates them from other workloads within the enterprise. The AWS Account also serves as the administrative boundary for its workloads and resources. While the business unit owns these resources, enterprise members administer them as IAM Identities. The account grants these entities permission to administer its workloads and resources. These permissions are further refined within the account through IAM controls that restrict what identities can do within the account. The account also serves as a governance boundary by imposing the enterprise guardrails implemented as SCPs and organizational policies. It also establishes trust boundaries for cross-account access by workloads within other AWS Accounts that require access.
Workload Isolation
Workload isolation is the core principle for protecting AWS resources. The closest physical analogy is a ship’s watertight compartments to prevent flooding. Security architecture revolves around this principle by isolating workloads through network segmentation and establishing trust boundaries around them. Network segmentation divides the enterprise cloud network into segments, limiting lateral movement across the network. This limits network connectivity to resources and reduces their exposure, thereby minimizing the attack surface. Network segments typically correspond to security boundaries and reinforce them by minimizing the number of network paths. This follows the principle of least necessary communication by allowing communication only to the workloads it needs to interact with.
Workload isolation also prevents the workload from impacting other resources in the network during any incident associated with it. This primarily covers security incidents, but also includes faults or failures that may arise in the workload. A special class of security incidents is when the workload is compromised, which can adversely affect other resources. Therefore, network segments provide fault, failure, security incident, and compromise containment, thereby improving the likelihood of business continuity. A key additional benefit of segmentation is reduced interdependencies by making segmented workloads independent from each other. This decoupling allows independent lifecycle management of workloads and simplifies maintenance.
Trust Boundaries
AWS Accounts serve as security boundaries that isolate workloads by complementing network segmentation. They establish a trust boundary in which interaction is allowed only with other workloads within that same trust boundary. Workloads outside that trust boundary have no implicit access to anything within that trust boundary. Cross-account interaction is only possible when explicit trust is established between the two accounts. External entities can access resources within a trust boundary, but only after they have authenticated themselves and have the necessary authorization.
AWS Accounts establishes trust minimization, in which trust is explicitly granted only to entities required to interact with resources within the account. There are two types of entities that require access to resources within AWS accounts. These are other resources within AWS, and entities within the enterprise outside of AWS. Cross-account access grants permissions through authorization to workloads in other AWS accounts. Enterprise members outside of AWS must authenticate and are then assigned permissions based on their authorization within AWS accounts.
Blast Radius Reduction
The need to contain workloads experiencing an incident (i.e., faults, failures, or compromises) from other resources is framed as blast radius reduction. A workload’s blast radius is the number of other workloads it can affect whenever it is experiencing an incident. The most serious of these is whenever a workload is compromised (e.g., it is infected with malware). Reducing the blast radius is to contain this workload so it is unable to affect other resources in the enterprise network. This extends to containing any other security incidents so they do not affect other resources. AWS Accounts and network segments achieve this by limiting the blast radius to within their trust boundary and network segments. The added benefit is that operations only need to remediate resources within the blast radius, with other business functionality minimally impacted.
Reducing the blast radius is achieved through multi-layer isolation. This is because compromised workloads may circumvent certain controls to reach other resources, but other controls can prevent this. Network boundaries can limit network paths to other resources, but compromised workloads can reach other resources through these paths. Trust boundaries deny access to workloads even though they can reach resources in other accounts via network paths. However, they can exploit cross-account trust access, but authorization boundaries help to limit their access. Even if they were able to assign themselves permissions, then governance boundaries can override these permissions, preventing harmful actions. All these layers provide defense-in-depth, reducing the blast radius to the compromised workload’s security boundary.
AWS Control Tower and Landing Zone Automation
An AWS Secure Landing Zone is a governance architecture built on AWS Organizations, Organizational Units (OUs), and AWS Accounts as the primary building blocks. Enterprises can establish and manage this multi-account structure manually by creating and managing all the building blocks. However, AWS Control Tower automates the deployment and management of the landing zone foundation using the Landing Zone as a blueprint. It automates account provisioning and governance controls while providing centralized governance capabilities and standardizes the deployment of enterprise guardrails across multiple AWS accounts.
What AWS Control Tower Provides
A core tenet of architectural practices is to automate repetitive operational tasks wherever possible, and AWS Control Tower follows this principle. AWS Control Tower automates the deployment of a landing zone governance architecture built on AWS Organizations. It creates a standardized AWS environment that includes automated multi-account setup and implements foundational governance controls.
AWS Control Tower consists of a set of core capabilities, and the main one is Account Factory for account provisioning. It creates accounts from a standard template, setting up baseline security controls, centralized logging integrations, and governance configurations while placing accounts into the appropriate Organizational Unit (OU). It also supports the creation and management of Organizational Units and the application of governance controls to those OUs. Additionally, it establishes centralized logging and dedicated accounts for common governance functions such as auditing and log archival.
A core capability of AWS Control Tower is the implementation of governance controls across the AWS environment. It integrates Service Control Policies (SCPs) with AWS Organizations to prevent actions that violate governance constraints, such as creating Internet Gateways (IGWs) in restricted environments. It also integrates AWS Config to continually monitor whether resources comply with governance policies. In addition, AWS Control Tower supports proactive controls that evaluate CloudFormation deployments and prevent non-compliant resources from being created.
Benefits of Automated Governance
Automation is optimal for repeatable processes, making it an effective tool for account provisioning in multi-account environments. Accounts are created and configured according to governance standards, reducing governance drift and the need for manual remediation. Furthermore, accounts are structured according to their business units and environments to ensure they have the necessary guardrails.
Large enterprises end up with at least hundreds of accounts, making manual creation and provisioning expensive and time-consuming. Automating this process reduces manual effort, enabling teams to focus on higher-value activities while ensuring consistent account onboarding. Also, it makes the account onboarding process more consistent, reducing the risk of configuration drift.
Implementing repeatable processes manually increases the risk of divergence, whereas automation significantly reduces it. There is far greater confidence in consistent guardrail enforcement and governance monitoring. This also includes standardized security baselines with reduced governance gaps. Automation also includes policy implementation, ensuring that they are consistently applied throughout the enterprise cloud environment.
Limitations and Trade-Offs
Different enterprises have differing requirements, and architects cannot apply exactly the same architecture to two or more enterprises. Therefore, they need to adapt their governance model to the unique requirements of each enterprise and continually refine it as those requirements change. Hence, automation will not replace the Organizational Unit (OU) strategy or the account hierarchy planning.
There are several considerations for architects when customizing AWS Control Tower templates for particular enterprises. An enterprise’s regulatory environment and the compliance constraints will drive Service Control Policies and additional guardrails. Also, the architecture must integrate with existing governance processes and security policies. Also, governance customization must factor in organization-specific operating models.
Like many architectural systems, AWS Control Tower is optimal for greenfield enterprise cloud environments and, to an extent, greenfield organizations. Many enterprises have already implemented cloud environments, and even more have legacy IT systems. Architects need to make informed choices on a hybrid approach of using AWS Control Tower and other migration tools to refactor existing architectures.
Common AWS Landing Zone Mistakes
The AWS Landing Zone is a powerful toolbox for organizing an enterprise cloud environment. However, misapplying these tools can significantly weaken the security posture and erode operational integrity. Misaligned security boundaries diminish workload isolation and increase the risk of their exposure. Guardrail implementation can be either too restrictive or too permissive, upsetting the trade-off between control and flexibility. These antipatterns can result in architectural decisions that carry lasting consequences.
Flat Account Structures
Workload isolation depends upon a well-defined trust boundary and network segmentation topology design. Flat account structure typically results in overloaded accounts where there are few accounts containing a large number of workloads. Many workloads within the same account have no required interaction and should be isolated from each other, expanding the attack surface.
Organizational hierarchy promotes a multi-account governance model that groups workloads around a common function. This is more likely to have workloads within each account limited to those with required interaction with one another. This improves workload isolation and reduces blast radius. It also groups accounts around their business unit, enabling policy inheritance through OUs.
Weak SCP Strategies
Overly permissive SCPs err on the side of excessive local autonomy, usually granting unrestricted access to administrative actions. This is either due to missing governance guardrails or inconsistent policy enforcement leading to governance gaps. This will lead to an increased attack surface, a degraded security posture, and reduced organizational control.
Imposing overly restrictive Service Control Policies centralizes more decisions than necessary and leads to administrative bottlenecks. This introduces administrative bottlenecks that delay workload deployment and reduce organizational agility. A very bad consequence is developers placing workloads, leading to shadow IT risks.
Over-Centralized IAM
Similar to restrictive SCP policies, over-centralized IAM typically involves centralized permission management. This excessive central administration results in administrative bottlenecks and reduces business-unit autonomy. Furthermore, it causes operational delays and slow access provisioning, hampering product development and organizational agility. Additionally, it also leads to scaling challenges and increases support overhead, introducing unnecessary expenses.
Sound IAM management principles follow a federated governance model that decouples authentication and authorization. Authorization is delegated to the business units, with necessary guardrails that enable business unit autonomy. Authentication is centralized to limit identity sprawl, inconsistent permissions, and high administrative overhead. Additionally, role-based access control enables segregation of duties by decoupling authorization across work functions.
Excessive Shared Services Coupling
Shared services create a key architectural tension between the coupling of business functions and minimizing the replication of common functionality. Providing shared services within an enterprise cloud environment results in dependencies upon these services, which carry certain risks. This includes reduced workload resilience, cascading failure potential, and expanded failure domains. This also causes cross-account dependency chains that impact trust boundaries.
There are clear benefits to shared services, and the architecture needs to leverage them while minimizing their disadvantages. The architecture should establish clear ownership boundaries to effectively manage dependencies and minimize cross-account dependencies. It must extend this to support workload isolation, thereby establishing fault containment. Finally, it must facilitate independent lifecycle management for shared services.
Best Practices for Enterprise Landing Zone Security
It is therefore imperative to apply best practices when implementing the enterprise Landing Zone. This ensures that the security posture is strengthened rather than weakened. The foundational best practices are preventive security controls that isolate resources from any unnecessary interaction with other workloads. Security boundaries and trust boundaries implement these practices. These best practices must also support enterprise scalability and long-term maintainability while ensuring sustainable cloud governance.
Separate Security Accounts
There are many security-related activities that impact all workloads across the enterprise. A core best practice is to separate responsibilities for these activities from responsibility for operational activities. This is implemented by establishing dedicated security accounts with their associated security boundaries. Such an implementation makes security administration independent from operations and reduces conflict of interest.
Security-related activities primarily focus on observability and auditing of observability data. Therefore, there are separate accounts responsible for the storage and management of log and monitoring data. This storage is made tamper-resistant and enables centralized security visibility and analysis. There are separate audit accounts, making audit capabilities independent from the rest of the enterprise.
Enforce Least Privilege
Least privilege is a critical layer of workload isolation for minimizing unnecessary interactions between resources and other workloads. It reduces the risk of unauthorized access and the attack surface when combined with security boundaries. Role-based access control enforces this principle that segregates duties and allows access only on a need-to-know basis.
Several mechanisms complement role-based access control to strengthen the enforcement of least privilege. Authorization granted by roles is separate from authentication, enabling temporary and time-bound access while simplifying permission management. Additionally, removal of unused permissions is simplified to removing the roles associated with those permissions. Furthermore, access is maintainable by managing the roles granting permissions.
Centralize Logging
In addition to their own account, logging and monitoring data should be centralized to enable observability across the enterprise. Furthermore, aggregating security events yields deeper intelligence than analyzing security events locally. An integrated approach to security management reduces security gaps with a localized approach that is fragmented.
Aggregating CloudTrail and AWS Config data strengthens their protection and preservation through centralized management. Correlation assists with security event detection, and centralized data better supports centralized incident response. It also assists with forensic activities whenever security incidents occur. Furthermore, centralized data helps with compliance evidence collection and managing historical audit records.
Use Preventive Guardrails
Enterprise cloud environment architecture seeks to maximize local autonomy for efficient operations. However, many actions can degrade workload isolation and permissions, introducing gaps in the enterprise security posture. Therefore, guardrails are needed to prevent these actions and their harmful consequences by imposing constraints. Service Control Policies are the mechanisms that impose these governance constraints on these business units. This forms part of a broader preventive and detective guardrail strategy that combines enforcement with continuous compliance monitoring.
SCPs are preventive controls because they stop actions from occurring in the first place. But Landing Zones should also prevent the creation of resources that violate governance requirements. These are proactive controls that ensure only approved instance types or network configurations are created. Proactive controls also ensure the inclusion of security controls, such as encryption and tagging, for management. This reduces any needed remediation efforts.
Automate Compliance Monitoring
Resource configuration is essential to maintaining optimal security with security boundaries and security controls. However, preventive controls do not completely eliminate the resource configuration drifting from its required state. Causes may be intentional, unintentional, or the result of changing governance requirements. Therefore, resource configuration compliance must be continually monitored and assessed to ensure compliance.
ThisAWS Config monitoring enforces this requirement, which continually assesses resources’ configuration against the required configuration. It provides compliance reporting, automated collection of compliance evidence, and governance insights. Additionally, it provides governance feedback loops and enables remediation. Furthermore, it enables continuous improvement of governance controls. Organizations commonly implement these assessments through AWS Config Conformance Packs.
Design for Future Scale
Many enterprises continue to grow, and the number of AWS workloads is increasing. Security boundaries and controls should be designed with future growth in mind, ensuring they continue to provide effective resource isolation and permission governance as the environment expands. Therefore, the architecture must scale to accommodate the growing enterprise cloud environment. Architectural principles must not only address the current environment but also how it will grow in the future.
It is necessary to ensure the orderly management of business unit growth, including growth in their functionality and the creation of new business units. This will lead to additional trust boundaries and the guardrails imposed on them. Therefore, the architecture must support multi-account growth, OU expansion readiness, and organizational restructuring. Addressing evolving enterprise requirements will ensure long-term maintainability.
Real-World Enterprise Landing Zone Example
Large financial services enterprises are an important example of a Landing Zone due to their stringent security and regulatory requirements. They typically consist of multiple business units, requiring a well-defined organizational structure and multi-account architecture. Additionally, these structures are replicated for production and non-production workloads. Financial services operate in highly hostile cyber environments, making workload isolation paramount and establishing strong trust boundaries. Given the regulatory environment, there are stringent governance requirements.
Enterprise Account Structure
There is no fixed recipe for account structure since each organization is different, and organizations often restructure due to changing environments. A representative structure for a small financial services firm may use multiple Organizational Units (OUs) within AWS Organizations. These OUs are typically organized around operational and shared governance functions. Operational OUs include Production and Non-Production OUs, whereas common OUs include Security, Shared Services, and Sandbox OUs. Under the Production OU, there are production AWS Accounts corresponding to each business unit. An example is Retail Banking, Payments, and Treasury Production Accounts. The corresponding Non-Production accounts support Development and Test workloads. The Security OU contains separate Audit and Log Archive accounts to support independent governance and observability functions. The Sandbox OU and Shared Services OU each contain a single account.
Centralized Governance and Security
The financial services firm leverages this structure to establish and enforce governance constraints across its Production and Non-Production OUs. The Log Archive and Audit accounts provide security oversight across the firm’s cloud environment. They perform different functions and are segregated into separate accounts for isolation and separate lifecycles for simpler management. The Shared Services account supports centralized security operations by aggregating observability and configuration data across the organization. This provides enterprise-wide visibility into operational and security activities. The firm leverages SCPs to enforce governance constraints across the firm’s cloud environment. The Audit account collects compliance evidence and prepares the firm for either internal or external auditing. Additionally, the Log Archive account ensures retention of historical records for governance transparency.
Security and Connectivity Architecture
Given the potential financial and reputational impact of security incidents, the financial services firm must maximize workload isolation and enforce strong trust boundaries. Network segmentation minimizes network paths to workloads and centralizes network connectivity using the Transit Gateway architecture. Hybrid enterprise environments should also consider the security implications discussed in AWS VPN vs Direct Connect Security. Restricting internet access is a critical task, limiting access to malicious actors. Workload isolation is further reinforced with the firm’s AWS Accounts that establish trust boundaries around AWS resources. This also enforces least-privilege access, limiting any unnecessary connectivity to workloads.
The account structure enables governance enforcement through SCPs and consistent security controls across the organization. The network also facilitates centralized observability that supports regulatory compliance. Shared Services enables business-unit autonomy while reducing duplication of common capabilities. As the firm grows, new business functions can be accommodated by adding accounts to the appropriate OUs without replicating shared capabilities.
Conclusion
Security Through Architecture
An AWS Secure Landing Zone establishes security as an integral part of the architecture rather than an afterthought or the sole responsibility of security controls. Designing security within the architecture establishes prevention as the first stage of security, without detection carrying the whole burden. The core pattern of security architecture is workload isolation, which limits any unnecessary interaction with workloads. This is primarily implemented by combining and aligning security boundary enforcement and trust boundary enforcement, establishing defense in depth. A key additional layer is permission boundaries that enforce the principle of least privilege, further strengthening workload isolation. This limits the impact of compromised workloads on other resources, thereby reducing the blast radius of security incidents.
Governance at Enterprise Scale
Architectural integrity that supports the security posture is easily degraded when teams make choices contrary to sound architectural principles. Hence, the enterprise cloud environment must impose constraints preventing these actions. These constraints form the governance framework across a multi-account environment that supports multiple business units and their products. The governance framework must balance effective security controls with the autonomy required for business units to fulfill their missions. Governance constraints act as automated guardrails on accounts, preventing actions that degrade the cloud environment’s integrity. SCPs are the mechanisms in AWS that enforce these guardrails and are either assigned to accounts or inherited by them from their OUs. Resource configuration must also support architectural integrity, making compliance monitoring an essential governance activity.
Building the AWS Security Foundation
Standardized account structures preserve architectural integrity by preventing the creation of accounts that weaken the enterprise governance model. The Landing Zone is an architectural framework consisting of account and organization building blocks that serve to ensure standardized account creation. These accounts and organization units support workload isolation patterns to ensure security by design and an architecture-first security approach. Complementary security boundaries also extend to encryption architecture, as discussed in AWS KMS Architecture: Designing Encryption Boundaries in AWS. The Landing Zone’s building blocks enable the creation and enhancement of organizational hierarchies that drive organizational evolution. This also supports the scalability of the cloud environment and long-term maintainability while ensuring security architecture maturity. Ultimately, the AWS Landing Zone provides the architectural foundation upon which secure, scalable, and well-governed enterprise cloud environments can evolve.
Further Reading
Affiliate Disclaimer
Disclosure: Some of the links below are affiliate links. This means that, at no additional cost to you, AI Cloud Data Pulse may earn a small commission if you make a qualifying purchase. We only recommend books, training, and resources that we believe provide genuine educational value and are relevant to the topics discussed in this article.
AWS Documentation
- AWS Well-Architected Framework – Security Pillar
- Organizing Your AWS Environment Using Multiple Accounts (AWS Whitepaper)
- AWS Organizations User Guide
- AWS Control Tower User Guide
- AWS Config Developer Guide
- AWS CloudTrail User Guide
- Amazon VPC User Guide
- IAM Identity Center / IAM User Guide
- AWS Cloud Adoption Framework (CAF)
Related Learning
Developing expertise in AWS Landing Zones, AWS Organizations, governance, identity management, and enterprise security architecture requires both theoretical understanding and hands-on experience. Pluralsight offers learning paths and courses covering AWS architecture, security, governance, and AWS Control Tower that complement the concepts discussed in this article.
