Secure multi account, multi region landing zone for regulated workloads

Getting the foundation right once means that every team which follows inherits security and compliance by default, rather than rebuilding it and arriving at a different answer each time. The design here is deliberately practitioner facing. Everything that can be expressed as configuration is expressed as configuration, the addressing is real and planned, and the network is built the way AWS now recommends for more than one region, which is AWS Cloud WAN rather than a single Transit Gateway. The two regions are Canada Central, in Montreal, as the primary, and Canada West, in Calgary, as the secondary, which keeps data inside Canada while still giving a genuine second region to fail over to. AWS Control Tower establishes and continuously governs the baseline, and the Landing Zone Accelerator on Amazon Web Services expresses the parts that need to live as version controlled configuration so that the whole environment can be reviewed, audited, and rebuilt from source.

Requirements

Before the architecture, the requirements it has to satisfy. These are the functional needs, the quality attributes the platform is judged on, the constraints it must respect, and the assumptions it rests on. Every decision in the next section traces back to one or more of them.

Functional requirements

Number	Requirement
1	Host production and non production workloads with strong isolation between them and between teams.
2	Provide an isolated environment for systems in scope for the Payment Card Industry Data Security Standard, with that scope kept as small as possible.
3	Connect the cloud estate to on premises data centres over private and inspected links.
4	Vend new accounts on demand, each created with the security baseline, the logging, and the network attachment already in place.
5	Centralize every audit and security record in one account that no routine operator can alter.
6	Force all traffic between networks, and all traffic to and from the internet, through inspection that the organization controls.
7	Recover from the loss of an entire region within defined and rehearsed objectives.

Quality attributes

Number	Attribute	Intent
1	Security	Defense in depth, least privilege, and an inspected path for every flow.
2	Reliability	Tolerate the loss of an availability zone with no human action.
3	Recoverability	Recovery point objective near zero for transactional data, and recovery time objective in minutes for a regional failover.
4	Auditability	Reconstruct who did what and when, with records retained for at least one year.
5	Operability	The whole environment defined as version controlled configuration that can be rebuilt from source.
6	Cost efficiency	Central shared services rather than duplication, and a warm standby rather than a full second copy.

Constraints and assumptions

Number	Constraint
1	All data must remain within Canada.
2	Only the two approved regions, Canada Central and Canada West, may be used.
3	The platform must support a Payment Card Industry assessment with minimized scope.
4	Managed Amazon Web Services services are preferred over self managed equivalents wherever one exists.

Number	Assumption
1	A corporate identity provider exists and can be federated for single sign on.
2	Workloads run primarily on containers and managed databases rather than long lived virtual machines.
3	At least two physically separate Direct Connect locations are available for hybrid connectivity.

Architecture decisions and rationale

These are the decisions that shaped the design. Each one records what was chosen, what was considered and set aside, why the choice was made, and what it costs, so that a reader can challenge the reasoning rather than only inspect the result.

1. A multi account organization rather than one large account

Decision. Divide the estate into many single purpose accounts grouped under organizational units, with each account a hard boundary.

Alternatives. A single account, or a small handful of accounts, separated only by identity and access permissions.

Rationale. An account is the strongest isolation boundary Amazon Web Services provides, so separating production, logging, security tooling, and the cardholder data environment into their own accounts limits the blast radius of any single mistake or compromise and gives clean billing and separation of duties. This serves functional requirements 1 and 5 and the security attribute.

Consequences. More accounts mean more to govern, which is the reason the baseline is automated through the account factory rather than applied by hand.

2. AWS Cloud WAN as the network backbone rather than a Transit Gateway

Decision. Use one AWS Cloud WAN core network with an edge in each region, and attach every network to it.

Alternatives. A Transit Gateway in each region peered together, or direct peering between every pair of networks.

Rationale. Cloud WAN expresses the segments, the routing, and the inspection in one version controlled policy that applies to both regions at once, which removes the per region route table drift that peered Transit Gateways accumulate, and the number of relationships to manage does not grow with the square of the number of networks. Its service insertion feature also provides centralized inspection without hand built routes. This serves the operability attribute and functional requirement 6.

Consequences. Cloud WAN carries a higher hourly cost than a single Transit Gateway, which is accepted because at two regions the assurance and the operational savings outweigh it.

3. Centralized inspection through service insertion rather than distributed firewalls

Decision. Run AWS Network Firewall in a dedicated inspection network in each region and steer every path through it using Cloud WAN service insertion.

Alternatives. A firewall in every workload network, or hand built routes that force traffic through a central appliance.

Rationale. A single declared chokepoint can be proven from one policy document, where distributed firewalls multiply cost and configuration and are easy to bypass by accident, and service insertion removes the fragile static routing that the older central appliance pattern required. This serves functional requirement 6 and the security attribute.

Consequences. All traffic depends on the inspection networks, so they are built across two availability zones and exist in both regions for resilience.

4. Hard segment isolation rather than relying on application controls

Decision. Set the isolate attachments property on the production, nonproduction, and cardholder data segments, so that networks within a segment cannot reach one another.

Alternatives. Allowing free routing within a segment and relying on security groups and application authentication to prevent unwanted access.

Rationale. Removing the route entirely is a stronger control than filtering on a route that exists, and it denies the lateral movement that an attacker relies on after a first foothold. This serves functional requirement 1 and the security attribute.

Consequences. Any legitimate communication between two networks must pass through inspection, which is the intended behavior and is accepted as slightly less direct.

5. A dedicated account and segment for the cardholder data environment rather than tag based separation

Decision. Place the cardholder data environment in its own account and its own isolated Cloud WAN segment.

Alternatives. Keeping it inside a shared workload account and separating it with tags, security groups, and naming.

Rationale. The assessment scope for the Payment Card Industry standard is reduced most effectively by the strongest available boundaries, and an account boundary combined with an isolated network segment is far stronger than separation by convention inside a shared account. This serves functional requirement 2 and constraint 3.

Consequences. The environment is less convenient to share resources with, which is exactly the point, and is accepted in exchange for a small and defensible assessment scope.

6. Two regions with a warm standby rather than a single region or a fully active pair

Decision. Run a primary region and a secondary region in warm standby, with data replicated continuously and the standby promoted on failover.

Alternatives. A single region with no regional recovery, or two regions both serving live traffic at all times.

Rationale. A single region cannot meet the recovery requirement, and a pair that is fully active in both regions roughly doubles cost and adds the difficulty of resolving conflicting writes, which is more than this recovery objective needs. This serves functional requirement 7 and the recoverability attribute, within constraint 1.

Consequences. A failover is a deliberate and rehearsed action that takes minutes rather than being instantaneous, which is acceptable for the stated recovery time objective.

7. A minimal management account with delegated administration

Decision. Keep the management account nearly empty and run the network and security services from delegated administrator accounts.

Alternatives. Operating the security and network services directly from the management account.

Rationale. The management account holds the most dangerous privileges in the organization, so keeping routine operations out of it reduces the chance that an ordinary action becomes a serious incident. This serves the security attribute.

Consequences. A small amount of one time setup is required to delegate administration of each service.

8. The whole environment as version controlled configuration rather than console changes

Decision. Define the organization, the guardrails, the network policy, and the accounts as version controlled configuration through AWS Control Tower and the Landing Zone Accelerator.

Alternatives. Configuring the environment by hand in the console and documenting it separately afterwards.

Rationale. Configuration that lives in source can be reviewed, tested, audited, and rebuilt, which is what both operational excellence and a regulator expect, and it removes the drift that manual changes accumulate over time. This serves the operability and auditability attributes.

Consequences. Changes move at the speed of a reviewed change request rather than a console click, which is a deliberate trade of speed for control.

The account structure

The first decision is to stop using one account for everything. A single account places production, development, security tooling, and logging inside the same blast radius and the same set of permissions, which is exactly what a regulated environment must avoid. Instead the organization is divided into accounts grouped under organizational units, where each account is a hard security and billing boundary and each organizational unit is a place to apply policy to many accounts at once. New accounts are not created by hand. They are vended through the Control Tower account factory, so that every account is born with the same baseline of guardrails, logging, and network attachment already in place.

The management account sits at the top and does almost nothing by design. It holds AWS Organizations, AWS Control Tower, and billing, and it is kept clean of workloads because its privileges are the most sensitive in the entire estate. The detection and network services are run from delegated administrator accounts rather than from the management account, which is the current AWS guidance and which keeps day to day operations out of the most dangerous account. Beneath the management account, the Security organizational unit holds two accounts. The Log Archive account is the immutable destination for every log in the organization, and it is an account that almost no human is allowed to touch. The Security Tooling account is the delegated administrator for the detection services, so that findings from every other account are aggregated and reviewed in one place rather than scattered.

The Infrastructure organizational unit also holds two accounts. The Network account owns the AWS Cloud WAN core network and all of the shared connectivity described below, and the Shared Services account holds the things that many workloads depend on, such as private interface endpoints, a directory for identity, name resolution rules, and the golden pipelines that build and deploy software. The Workloads organizational units separate production from everything that is not production, because the rules that should apply to a payment service are not the rules that should apply to a developer experiment. Finally, a dedicated organizational unit isolates the cardholder data environment, which lives in its own account so that the boundary around it is an account boundary, the strongest one available.

Governance and guardrails

Policy is applied in layers, and the layers are chosen so that the most important rules are the ones a person cannot accidentally remove. Service control policies are preventive and they describe what is forbidden, for example denying the ability to disable logging, denying the use of any region other than the two that are approved, and denying changes that would weaken encryption. Resource control policies, a more recent addition, restrict who may access a resource regardless of the permissions granted inside the account that owns it, which closes a class of gaps that account level permissions alone could not, such as a storage bucket policy that would otherwise allow access from outside the organization. Declarative policies, newer still, let you state a desired configuration for a service across the whole organization in a way that cannot be overridden locally and that continues to apply even to capabilities released in the future, which is how the organization can guarantee, for instance, that block public access stays on for every storage account forever. On top of these preventive controls, AWS Config rules act as the detective layer, continuously checking that resources match the intended state and recording every drift.

Human access follows the same principle of no standing privilege. People do not hold long lived credentials in any account. They sign in through AWS Identity and Access Management Identity Center, federated to the organization's existing identity provider, with multi factor authentication required, and they assume a role for a bounded period to do a specific job. The audit trail therefore records not only what happened but which human assumed which role to make it happen.

The network backbone, AWS Cloud WAN

For a single region, a Transit Gateway is enough. For two regions and a regulated posture, AWS Cloud WAN is the better choice, and it is the one AWS now steers customers toward. The reason is that Cloud WAN gives you one global core network, with a presence in each region called a core network edge, and you describe the whole thing, the segments, the routing, and the inspection, in a single policy document rather than assembling it from per region route tables that drift apart over time. The intent lives in one place, it is version controlled, and it is applied consistently to every region at once.

Each region runs its own inspection virtual private cloud, and the workload networks in each region attach to the local edge. Connectivity to the organization's data centres is provided by AWS Direct Connect attached to the core network, with a second Direct Connect location for the second region so that the loss of one facility does not sever the hybrid path. The inspection networks deliberately use addresses from the carrier grade range rather than the private range, which is a small but real practice that keeps the large private address blocks free for actual workloads.

Segmentation and inspection, written once as policy

The heart of the design is the segmentation. A Cloud WAN segment is an isolated routing domain, and this landing zone defines four of them, named shared, production, nonproduction, and pci, plus a network function group that represents the inspection virtual private clouds. A virtual private cloud is placed into a segment automatically based on a tag, so a network simply tagged as belonging to the production segment is attached to the right segment without anyone editing a route table. The production, nonproduction, and pci segments set the isolate attachments property, which means that even two networks inside the same segment cannot reach one another, removing the lateral movement that attackers rely on. The shared segment, which carries only the common endpoints and name resolution, is the one segment shared with all the others.

The inspection itself is handled by the Cloud WAN feature called service insertion, which AWS released for exactly this purpose. Rather than hand building the static routes that used to be required to force traffic through a firewall, you declare the intent in the policy. A send via action steers traffic that travels between virtual private clouds through the inspection network function group first, and a send to action steers traffic bound for the internet or on premises through the same inspection point. AWS Network Firewall runs inside each region's inspection network, performing stateful inspection, intrusion prevention, and domain filtering, and because service insertion is aware of both regions, it chooses an inspection network deterministically and falls back to the other region if one is unavailable. A representative excerpt of the core network policy looks like this.

{
  "version": "2021.12",
  "core-network-configuration": {
    "asn-ranges": ["64512-64555"],
    "edge-locations": [
      { "location": "ca-central-1" },
      { "location": "ca-west-1" }
    ]
  },
  "segments": [
    { "name": "shared" },
    { "name": "production",    "isolate-attachments": true, "require-attachment-acceptance": true },
    { "name": "nonproduction", "isolate-attachments": true },
    { "name": "pci",           "isolate-attachments": true, "require-attachment-acceptance": true }
  ],
  "network-function-groups": [
    { "name": "inspection", "require-attachment-acceptance": true }
  ],
  "segment-actions": [
    { "action": "share",    "segment": "shared", "share-with": "*" },
    { "action": "send-via", "segment": "production", "mode": "single-hop",
      "via": { "network-function-groups": ["inspection"] } },
    { "action": "send-to",  "segment": "production",
      "via": { "network-function-groups": ["inspection"] } },
    { "action": "send-via", "segment": "pci", "mode": "single-hop",
      "via": { "network-function-groups": ["inspection"] } }
  ],
  "attachment-policies": [
    { "rule-number": 100,
      "conditions": [{ "type": "tag-value", "key": "segment", "operator": "equals", "value": "pci" }],
      "action": { "association-method": "constant", "segment": "pci" } },
    { "rule-number": 200,
      "conditions": [{ "type": "tag-value", "key": "segment", "operator": "equals", "value": "production" }],
      "action": { "association-method": "constant", "segment": "production" } }
  ]
}

Ingress from the internet is handled with dedicated inspection networks that place AWS Network Firewall behind a Gateway Load Balancer, so that traffic arriving from the internet is examined before it ever reaches an application network. The result is that every direction of travel, into the estate, out of the estate, and between networks, passes through a firewall that the organization controls, and that fact is provable from a single policy rather than inferred from dozens of route tables.

Regional addressing in detail

The addressing is planned rather than improvised, because the day you need to connect two of these environments together, or attach a data centre, overlapping ranges become a painful and expensive problem. Each region is given a clean block, the first region under one tenth of the private space and the second region under another, so that the two never collide and the region is obvious from the address. Within each region, every workload network spans two availability zones and is divided into public subnets that hold only the load balancers, private subnets that hold the application compute, and data subnets that hold the databases.

Network	Segment	ca-central-1	ca-west-1
vpc-inspection	inspection	100.64.0.0/24	100.64.64.0/24
vpc-shared-svc	shared	10.4.0.0/16	10.68.0.0/16
vpc-prod-payments	production	10.16.0.0/16	10.80.0.0/16
vpc-nonprod	nonproduction	10.48.0.0/16	10.112.0.0/16
vpc-pci-cde	pci	10.32.0.0/16	10.96.0.0/16

One further habit keeps traffic off the public internet entirely. The Shared Services account hosts private interface endpoints for the Amazon Web Services interfaces that workloads call, and these are reachable through the shared segment, so a service in a workload account reaches Amazon Simple Storage Service or a queue over the private network rather than over the internet, which both reduces exposure and reduces the volume of traffic that has to traverse the inspection path.

Resilience and data across two regions

Two regions are only useful if the data and the recovery plan are designed for them, so the data tier is multi region from the start rather than as an afterthought. The primary database is an Amazon Aurora Global Database, which replicates from the primary region to the secondary in well under a second and can be promoted quickly when needed. Object storage is replicated between the regions with cross region replication, and encryption keys are AWS Key Management Service multi region keys, which share the same key identifier in both regions so that an object encrypted in one region can be decrypted in the other without re encrypting it. Traffic is directed to the healthy region by Amazon Route 53 together with the Application Recovery Controller, which performs readiness checks and supports a controlled, deliberate failover rather than an automatic one that might flap.

The pattern here is a warm standby rather than a fully active second region, which is the right balance for most regulated workloads between the cost of running everything twice and the need to recover quickly. The recovery point objective is near zero because the database replicates continuously, and the recovery time objective is measured in minutes because the standby is already running and only needs to be promoted and have traffic shifted to it. The single most important discipline here is not the technology but the rehearsal. A failover that has never been practised is a hope, not a plan, so the regional failover is exercised on a schedule and the runbook is kept honest.

Logging, detection, and encryption

A regulated environment is one in which you can answer, after the fact and with evidence, who did what and when. Every account in every region sends its records to the Log Archive account, which receives an organization wide trail from AWS CloudTrail, the configuration history from AWS Config, and network flow logs, all written into an Amazon Simple Storage Service bucket that is protected with object lock so that records cannot be altered or deleted, and encrypted with a customer managed key. Because this account is almost untouchable, the audit trail remains trustworthy even against an attacker who has compromised a workload account. Detection is centralized in the Security Tooling account, which is the delegated administrator for Amazon GuardDuty for threat detection, AWS Security Hub for posture and standards conformance, Amazon Macie for discovering sensitive data, and Amazon Inspector for vulnerabilities, with Amazon Security Lake normalizing the findings from every account and region into one queryable place.

Encryption is on everywhere and the keys belong to the organization rather than to defaults. Data is encrypted in transit on every path and at rest in every store, using customer managed keys separated by account and by sensitivity so that the blast radius of any single key is small. The cardholder data environment uses its own keys, distinct from the rest of the estate, so that access to data elsewhere can never imply access to cardholder data.

The cardholder data environment and the Payment Card Industry standard

The single most valuable thing an architecture can do for the Payment Card Industry Data Security Standard is to make its scope small. The standard applies to every system that stores, processes, or transmits cardholder data, and to every system connected to those, so an environment without segmentation pulls almost everything into scope and makes the assessment enormous and expensive. This design does the opposite, and it does it in two reinforcing ways. The cardholder data environment lives in its own account and its own organizational unit, which is the strongest boundary available, and it also lives in its own Cloud WAN segment with the isolate attachments property set, so the network itself refuses to carry traffic into the environment except through the inspection path. The environment has no public subnets at all. It is reachable only through inspection and the AWS web application firewall, it holds its own keys, it captures its own network flow logs, it is scanned for vulnerabilities, and its audit history is retained for at least one year as the standard expects. Because both the account boundary and the network policy prevent anything else in the organization from reaching it, the rest of the estate stays out of scope, and the assessment becomes a question about one well defined account rather than about everything.

How this serves the wider goals

The structure also answers all six pillars of the AWS Well Architected Framework, which is worth stating plainly because a regulated platform is judged on more than security alone. Operational excellence comes from defining the whole environment, including the network policy, as version controlled configuration that can be reviewed, tested, and rebuilt. Security comes from the layered guardrails, the centralized inspection, and the segmentation described above. Reliability comes from spreading every tier across two availability zones within a region and across two regions for disaster recovery, with a rehearsed failover. Performance efficiency comes from placing workloads close to their users in region and from keeping service traffic on private endpoints rather than the public internet. Cost optimization comes from running the inspection and the shared services once and sharing them, rather than duplicating them in every account, and from running the second region as a warm standby rather than a full duplicate. Sustainability comes from favoring managed and serverless services that are scaled to actual demand rather than provisioned for peak and left running. This landing zone is the foundation that the other reference architectures in this collection are designed to sit inside.