The following table provides some high level considerations on deciding between a single multi-account landing zone (MALZ) vs multiple multi-account landing zones (for example, two multi-account landing zones - Prod and non-Prod). In general, the choice depends upon individual needs, legal requirements, and operating practices.
Entity | Single AMS landing zone | Multiple (two or more) landing zones |
---|---|---|
Base cost |
Lower, optimized at approximately $3,000 per month. |
Higher, an additional cost of approximately $3,000 per environment. |
Billing |
Single bill, due to single Billing/ Management account. |
Separate bill for each multi-account landing zone. Currently AWS Org does not support multi-Management accounts with a single bill. |
Portability of existing reserved instances (RIs) |
Low. AWS RIs are currently not convertible across multiple billing accounts. You would repurpose existing RIs for multi-account landing zone. |
Lower. You would repurpose and distribute RIs across all multi-account landing zone. |
Product tiering discounts |
High. See Volume discounts. |
Low. See Volume discounts. |
Initial setup overhead (on project/migration timelines) |
Low. Active Directory, networking and single sign-on (SSO) integrations once only. |
High. You would perform Active Directory, network integration, and SSO integrations for every landing zone. This could cause potential delays to any migration project. |
Common services configurability |
Low efforts. You configure common/shared services like DNS, backup, monitoring, logging etc. |
High efforts. Additional planning is required to address where the common infrastructure or services will be sitting. Traffic traversing across multiple transit gateways (TGWs) in each landing zone, could lead to extra cost. |
Scalability |
Medium. AMS has a current practical limit of 150 accounts per multi-account landing zone. Multiple teams or vendors running applications in same account could have access to stacks owned by different teams. This limitation can be mitigated by controlling access to application-specific stacks at the ServiceNow layer (by integrating the AMS ServiceNow Connector application and making use of tags). Ask AMS technical delivery managers (TDMs) or cloud architects (CAs) how to implement this. |
High. Ability to leverage multiple multi-account landing zone to distribute the accounts while achieving an account or application level of segregation. Managing large numbers of accounts could lead to operational or cost overhead. |
Operational Risk |
(Depends) Low. Operational integration and readiness once only. Less chance of process drifts. |
(Depends) Low. Multiple integration and operational activities. Drift in multiple landing zones over the period could lead to operational risks. |
Multi AWS Region |
Single AWS Region. AMS multi-account landing zone is restricted to a single AWS Region. To span multiple AWS Regions, use multiple multi-account landing zone. |
Multi AWS Region. With multiple multi-account landing zones, you can have each MALZ deployed in one region and interconnect them using transit gateway (TGW) peering. |
Account migration or portability |
Yes. Moving accounts from one OU to another within the same AWS Organization is possible. |
No. AMS doesn't support migration of an account across landing zones; that is, across AWS Organizations. Workloads can reach across landing zones with transit gateway (TGW) or VPC peering. |
Change management |
Medium. Making destructive changes to common components like TGW, Active Directory (AD), or outbound (egress) can impact all workloads in a multi-account landing zone. However, changes to AMS-managed components are tested internally and are pushed in rolling updates. |
Low. Making destructive changes to common components like TGW, AD, or outbound (egress) can impact only the workloads in that specific multi-account landing zone. |
Data and access controls |
(Depends) Low control if you’d like to connect to different on-premise ADs and networks for Prod vs Non-Prod workloads. SAML federation, TGW domains, and security groups (SGs) can help implement required controls too. |
(Depends) High control if you’d like to connect to different on-premise ADs and networks for Prod vs Non-Prod workloads. Use separate landing zones for strict compliance requirements. |
Compliance and Security |
(Depends) Low if there are strict compliance needs to completely segregate material vs non-material workloads. AMS standard preventative and detective controls in place. |
(Depends) High as multiple multi-account landing zone could help achieve strict compliance requirements by completely segregating material vs non-material workloads. AMS standard preventative and detective controls in place. |
Recommendation: Without strict Compliance or multi-Region need, starting with single AMS multi-account landing zone would strike a good balance among cost, security, operational excellence, and migration complexity. You can always setup additional landing zone, if any account or business constraints are encountered.