Skip to content
PuglieseWeb Engineering HandbookSystemDox Pages

Multi-account landing zone with redundant connectivity

The structure below is a conventional enterprise landing zone: accounts separated by function and environment, connectivity centralised in a shared services account, and security tooling in its own account. It is a sound starting point for a regulated or multi-team estate. It is not, on its own, a five-nines architecture — see what five nines actually costs at the end, because that claim is made about designs like this one more often than it is earned.

Account structure

Section titled “Account structure”
AccountHolds
ManagementAWS Organizations, service control policies, consolidated billing. No workloads.
SecurityGuardDuty, Security Hub, AWS Config, the CloudTrail organisation trail, and the log archive.
Shared servicesDirect Connect and Transit Gateway attachments, Route 53 private zones, ACM certificates, monitoring, the CI/CD pipeline and artefact storage.
Development, Test, Staging, ProductionOne account per environment, each with its own multi-AZ VPC, applications and databases.
Disaster recoveryStandby infrastructure in a second Region, receiving cross-Region replication.

Identity is federated from an external identity provider into IAM Identity Center, with MFA enforced, rather than IAM users being created per account.

Connectivity

Section titled “Connectivity”
  • Two Direct Connect connections, ideally through different providers and terminating at different locations, so they do not share fate.
  • A Site-to-Site VPN as a third, independent path.
  • A Transit Gateway in the shared services account as the hub; each environment VPC attaches to it, so routing is centralised rather than a mesh of peerings.
  • Every VPC spans at least two, preferably three, Availability Zones.

Network and account topology

Section titled “Network and account topology”
graph TB subgraph Org["AWS Organizations"] MasterAcct["Management account<br/>Organizations, SCPs, billing"] subgraph Sec["Security account"] SecurityTools["GuardDuty · Security Hub<br/>AWS Config · CloudTrail"] IAM["IAM Identity Center<br/>External IdP · MFA"] end subgraph Shared["Shared services account"] SharedInfra["Direct Connect · Transit Gateway<br/>Route 53 · ACM"] Monitoring["CloudWatch · Grafana<br/>Prometheus"] CI["CodePipeline · Jenkins<br/>Artefact storage"] end subgraph NetHub["Network hub"] DX1["Direct Connect 1"] DX2["Direct Connect 2"] VPN["Backup VPN"] TGW["Transit Gateway"] end subgraph Dev["Development account"] DevVPC["Dev VPC (multi-AZ)"] DevApps["Applications"] DevDB["Databases"] end subgraph Test["Test account"] TestVPC["Test VPC (multi-AZ)"] TestApps["Applications"] TestDB["Databases"] end subgraph Stage["Staging account"] StageVPC["Staging VPC (multi-AZ)"] StageApps["Applications"] StageDB["Databases"] end subgraph Prod["Production account"] ProdVPC["Production VPC (multi-AZ)"] ProdApps["Applications"] ProdDB["Databases"] end subgraph DRAcct["Disaster recovery account"] DR["DR Region<br/>Standby VPCs · replicated data"] end end MasterAcct --> SecurityTools MasterAcct --> IAM MasterAcct --> SharedInfra SharedInfra --> Monitoring SharedInfra --> CI SharedInfra --> TGW DX1 --> TGW DX2 --> TGW VPN --> TGW TGW --> DevVPC TGW --> TestVPC TGW --> StageVPC TGW --> ProdVPC DevVPC --> DevApps DevVPC --> DevDB TestVPC --> TestApps TestVPC --> TestDB StageVPC --> StageApps StageVPC --> StageDB ProdVPC --> ProdApps ProdVPC --> ProdDB CI --> DevVPC CI --> TestVPC CI --> StageVPC CI --> ProdVPC ProdVPC --> DR ProdDB --> DR

Access model

Section titled “Access model”

Access is granted through IAM Identity Center permission sets, assigned per account rather than per VPC:

TeamDevelopmentTestStagingProductionPipeline
DevelopmentFullReadReadNoneTrigger only
Platform / DevOpsFullFullFullFullFull
SupportReadReadReadRead, plus a scoped break-glass roleNone

Production write access outside the pipeline should be a time-bound, approved elevation that is logged, not a standing permission.

What five nines actually costs

Section titled “What five nines actually costs”

99.999% availability is 5 minutes 15 seconds of downtime per year. The structure above does not deliver it, and it is worth being precise about why, because “designed for five nines” is a claim that gets attached to landing-zone diagrams routinely.

The components do not compose to it. Amazon EC2’s Region-Level SLA — for instances deployed across multiple Availability Zones — is a Monthly Uptime Percentage of at least 99.99%; the Instance-Level commitment is 99.5%. RDS Multi-AZ is 99.95%. Redshift Multi-AZ is 99.99%. Route 53 is the outlier at 100% for authoritative DNS. A workload cannot be more available than the serial chain of things it depends on, so a single-Region design built on these components has a ceiling below 99.999% before any of your own code is considered.

Getting past that ceiling means removing the Region from the chain. In practice that requires:

  • Active/active across Regions, with traffic already flowing to both, so failover is removal from rotation rather than a promotion.
  • No dependency on a single Region’s control plane in the recovery path — including the authentication, DNS and deployment systems used during an incident.
  • Data replication with a conflict-resolution model you have actually specified, because active/active writes force the question.
  • Change control governed by an error budget, since at five nines a single bad deployment consumes the entire year’s allowance.
  • Continuous verification — game days and fault injection — because 5 minutes a year is far below the threshold at which you would notice a broken failover path by accident.

Start from the budget, not the diagram. Write down the availability target per workload, decompose it across the dependency chain, and see what each tier has to achieve. That arithmetic usually shows that the expensive part is not the infrastructure at all — it is the operational discipline, and the small number of workloads that genuinely need the target.

Section titled “Related”