AWS Landing Zone -- Architecture Patterns¶

What this page explains

How and why the main AWS project setups work: single VPC, multi-VPC (Transit Gateway, peering, PrivateLink, Cloud WAN, VPC Lattice), multi-account with AWS Organizations, multi-AZ and multi-Region, disaster recovery, network perimeter, and landing zones built with AWS Control Tower. It also covers the security model (IAM, SCPs, RCPs, declarative policies, IAM Identity Center). Quotas, prices, and look-up tables are in Reference. Commands are in How-to Guides.

How the Pieces Fit¶

A typical enterprise AWS estate has three layers. The organization layer (AWS Organizations, Control Tower, IAM Identity Center) decides who can do what in which account. The network layer (a Network account owning Transit Gateway or Cloud WAN, inspection, egress, and hybrid links) decides which VPCs can talk. The workload layer is the per-team accounts and VPCs that attach to both. The rest of this page takes these layers one at a time, from the simplest single-VPC design up to a full landing zone.

This diagram shows the three layers and the account that owns each shared component.

flowchart TB
    subgraph OrgLayer["Organization layer (management account)"]
        ORG["AWS Organizations<br/>OUs, SCPs, RCPs, declarative policies"]
        CT["AWS Control Tower<br/>landing zone, controls, Account Factory"]
        IDC["IAM Identity Center<br/>permission sets"]
    end
    subgraph NetLayer["Network layer (Network account)"]
        HUB["Transit Gateway or Cloud WAN"]
        INSP["Inspection VPC<br/>AWS Network Firewall"]
        HYB["Direct Connect gateway / Site-to-Site VPN"]
    end
    subgraph SecLayer["Security layer (Log Archive + Audit accounts)"]
        LOGS["Org CloudTrail + Config to S3"]
        FIND["GuardDuty, Security Hub, Inspector"]
    end
    subgraph WlLayer["Workload accounts"]
        VPC1["App VPCs, EKS, ECS, Lambda, RDS"]
    end
    CT --> ORG
    ORG -->|"policies inherited"| WlLayer
    IDC -->|"roles per account"| WlLayer
    VPC1 <-->|"attachment shared via AWS RAM"| HUB
    HUB <--> INSP
    HUB <--> HYB
    WlLayer -->|"logs and findings"| SecLayer

1. Single Account with Single VPC¶

Architecture Summary¶

A single VPC is the basic building block on AWS. A VPC is an isolated virtual network. You define a private CIDR block, create subnets across Availability Zones, and attach route tables and gateways. For a single project, one VPC with multi-AZ subnets gives isolation, high availability, and simplicity.

The request path of a three-tier web app in one VPC across two AZs looks like this.

flowchart TD
    Users["Internet users"] --> CF["CloudFront + AWS WAF"]
    CF --> ALB["Application Load Balancer<br/>public subnets, AZ-a and AZ-b"]
    subgraph VPC["VPC 10.0.0.0/16"]
        ALB --> AppA["EC2 Auto Scaling group<br/>private subnet AZ-a"]
        ALB --> AppB["EC2 Auto Scaling group<br/>private subnet AZ-b"]
        AppA --> DBP["RDS primary<br/>DB subnet AZ-a"]
        AppB --> DBP
        DBP -.->|"synchronous standby"| DBS["RDS standby<br/>DB subnet AZ-b"]
        AppA --> NAT["NAT gateway"]
        AppB --> NAT
        NAT --> IGW["Internet gateway"]
    end

Key Services¶

Service	Role
VPC	Isolated virtual network with custom CIDR, subnets, route tables
Subnet	Segment within a VPC, bound to a single AZ. Public or private
Route Table	Main route table (auto-created) + custom routes. Controls traffic forwarding
Internet Gateway (IGW)	Enables internet access for public subnets
NAT Gateway	Outbound internet (SNAT) for private subnet resources. Zonal, or regional since 2025-11
ALB / NLB	Application (L7) or Network (L4) Load Balancer distributes traffic across AZs
Security Group	Stateful per-ENI firewall (allow rules only, implicit deny)
Network ACL	Stateless subnet-level packet filter (allow and deny rules)
Elastic IP (EIP)	Static public IPv4 address for a NAT gateway, NLB, or single EC2 instance. Billed like every public IPv4 address

Recommended Configurations¶

CIDR planning: Use RFC 1918 ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). Leave headroom. The VPC CIDR must not overlap with any VPC you plan to peer or connect through TGW later. Start with /16 for the VPC and /24 for subnets. Amazon VPC IP Address Manager (IPAM) can allocate non-overlapping CIDRs across an organization.
Multi-AZ subnets: Create at least two subnets per tier in different AZs. Place ALB, EC2, and RDS replicas across them.
Subnet tiers: Split into public (DMZ), private (application), and private (database) subnets. Use route tables to enforce the tiered traffic flow.
No public IPs on app/DB: App and database instances get no public IPs. Use a NAT gateway for outbound internet and the ALB for inbound. Every public IPv4 address costs money since 2024-02-01 (Reference).
Security Groups: One SG per tier (web, app, db) with least-privilege rules. Reference SGs in rules rather than IP addresses.

Regional NAT gateway (since 2025-11)

A regional NAT gateway is one gateway ID that expands to every AZ where you have workloads. It needs no public subnet. It removes the per-AZ NAT gateway and per-AZ route-table bookkeeping. You still pay the hourly rate for each active AZ, so it simplifies operations rather than cutting cost.

Real-World Example¶

A SaaS startup deploys a three-tier web application in us-east-1. One VPC (10.0.0.0/16) has subnets in AZs a and b. Public subnets host an ALB. Private subnets host EC2 Auto Scaling groups. A managed RDS PostgreSQL instance runs with Multi-AZ HA. A NAT gateway provides egress. CloudFront with AWS WAF provides edge security.

2. Multi-VPC Architecture¶

When workloads span several VPCs, AWS offers five main ways to connect them. Common reasons are environment isolation (dev/staging/prod), business-unit separation, or regulatory compliance. Transit Gateway and Cloud WAN are routed networks. VPC peering is a point-to-point link. PrivateLink and VPC Lattice connect services, not networks.

2a. Transit Gateway (TGW) -- Hub-and-Spoke¶

Architecture Summary¶

AWS Transit Gateway is a regional hub. It connects VPCs, VPN connections, Direct Connect gateways, and other TGWs (through inter-Region peering). It acts as a cloud router. Traffic flows through TGW route tables. This gives central routing policy, traffic isolation, and inspection.

A single TGW supports up to 5,000 attachments (a hard quota). Each VPC attachment carries up to 100 Gbps per AZ. Inter-Region peering connects TGWs across Regions over the AWS backbone, encrypted and without the public internet. Full quotas are in Reference.

The standard enterprise hub-and-spoke puts the TGW, inspection, egress, and hybrid links in a Network account and shares the TGW with workload accounts through AWS Resource Access Manager (RAM).

flowchart LR
    subgraph NetAcct["Network account (us-east-1)"]
        TGW["Transit Gateway<br/>route tables: prod, nonprod, shared, inspection"]
        subgraph InspVPC["Inspection VPC"]
            NFW["AWS Network Firewall<br/>one endpoint per AZ"]
        end
        subgraph EgressVPC["Egress VPC"]
            NATGW["NAT gateway"] --> IGW["Internet gateway"]
        end
        DXGW["Direct Connect gateway"]
    end
    subgraph Spokes["Workload accounts (TGW shared via AWS RAM)"]
        ProdVPC["Prod VPC 10.1.0.0/16<br/>/28 TGW attachment subnets"]
        DevVPC["Dev VPC 10.2.0.0/16"]
        SharedVPC["Shared services VPC 10.0.0.0/16"]
    end
    ProdVPC <--> TGW
    DevVPC <--> TGW
    SharedVPC <--> TGW
    TGW <-->|"appliance mode or native attachment"| NFW
    TGW <--> NATGW
    TGW <--> DXGW
    DXGW <--> OnPrem["On-premises data center"]
    TGW <-.->|"inter-Region peering"| TGW2["Transit Gateway (eu-west-1)"]

Key Services¶

Service	Role
Transit Gateway	Regional hub. Connects VPCs, VPNs, Direct Connect, and peered TGWs
TGW Route Table	Controls which attachments can talk. Several route tables give isolation
TGW Attachment	Link between TGW and a VPC, VPN, Direct Connect gateway, Connect (GRE/BGP), Network Firewall, or peered TGW
Inter-Region Peering	Encrypted, non-transitive link between TGWs in different Regions (static routes only)
Direct Connect Gateway	Connects Direct Connect circuits to TGW for hybrid connectivity
AWS RAM	Shares the TGW from the Network account to accounts or whole OUs

Recommended Configurations¶

Use separate TGW route tables for production, non-production, and shared services to enforce isolation.
Inspection VPC pattern: Route traffic through a central inspection VPC with AWS Network Firewall. Enable TGW appliance mode on that attachment for symmetric routing. Since 2025-06 (all Regions since 2025-07), Network Firewall can also attach natively to the TGW. That removes the inspection VPC subnets and route tables.
Dedicated TGW subnet: In each VPC, create a small /28 subnet per AZ for the TGW attachment. It keeps TGW ENIs apart from workload subnets.
Enable every AZ: Attach the TGW in each AZ where workloads run. This keeps workloads reachable and avoids cross-AZ hops and charges.
Use unique ASNs: When you deploy several TGWs (for example for DR), give each one a unique ASN for BGP.
Automate with IaC: Manual TGW attachment changes cause misroutes. Use Terraform or CloudFormation pipelines and check TGW configuration with AWS Config.

Real-World Example¶

A financial services company has separate VPCs for trading, risk analytics, and back office in us-east-1. A TGW connects them with three route tables. shared lets all VPCs reach shared services. prod holds trading and risk, isolated from dev. dev holds back office and sandbox. An inspection VPC with AWS Network Firewall sits between the TGW and the internet gateway and inspects all north-south traffic. A Direct Connect gateway gives hybrid connectivity to the on-premises data center.

2b. VPC Peering¶

Architecture Summary¶

VPC peering is a direct, one-to-one link between two VPCs. It works within a Region and across Regions. Unlike TGW, there is no central hub. Peering is not transitive. If A peers with B and B peers with C, A cannot reach C through B.

Each side needs a route to the other side's CIDR that points at the peering connection (pcx-).

flowchart LR
    subgraph A["VPC-A 10.0.0.0/16"]
        RTA["Route table:<br/>10.1.0.0/16 to pcx-"]
    end
    subgraph B["VPC-B 10.1.0.0/16"]
        RTB["Route table:<br/>10.0.0.0/16 to pcx-"]
    end
    subgraph C["VPC-C 10.2.0.0/16"]
        RTC["Route table:<br/>10.1.0.0/16 to pcx-"]
    end
    A <-->|"peering pcx-ab"| B
    B <-->|"peering pcx-bc"| C
    A -.-x|"no transitive path"| C

Recommended Configurations¶

Make sure that CIDR blocks do not overlap between peered VPCs.
Same-account peering is simplest. Cross-account peering needs the peer account to accept.
For more than 3-4 VPCs, prefer TGW over single peering links. Full-mesh peering grows as O(n^2) links and route entries.
VPC peering has no aggregate bandwidth limit and no per-GB processing charge. You pay only standard cross-AZ or cross-Region data transfer (same-AZ traffic over peering is free). That makes it cheaper than TGW for high-volume, simple topologies.
Security groups in a peer VPC can be referenced only within the same Region. NACLs do not cross the peering link.

When to Choose VPC Peering over TGW¶

Small number of VPCs (2-4) with simple, static connectivity.
High-volume data transfer where TGW per-GB processing charges would add up.
No need for central inspection or complex routing.

2c. AWS PrivateLink¶

Architecture Summary¶

AWS PrivateLink gives private connectivity between VPCs, AWS services, and on-premises applications without the public internet. Unlike peering, PrivateLink is one-way and service-oriented. A consumer reaches a specific service endpoint, not the whole producer VPC. The endpoint ENI has an IP from the consumer VPC, so the two sides need no CIDR coordination and may overlap.

The consumer side uses interface endpoints (ENIs) for PrivateLink services and gateway endpoints (route-table entries) for S3 and DynamoDB.

flowchart LR
    subgraph ConsumerVPC["Consumer VPC"]
        App["Application"]
        IEP["Interface endpoint<br/>ENI with private IP"]
        GEP["Gateway endpoint<br/>route table entry"]
        IEPaws["Interface endpoints<br/>SQS, KMS, SSM, ECR"]
    end
    subgraph ProducerVPC["Producer VPC (other account)"]
        ES["Endpoint service"] --> NLB["Network Load Balancer"] --> Svc["Managed service"]
    end
    App --> IEP -->|"AWS PrivateLink"| ES
    App --> GEP --> S3["Amazon S3 / DynamoDB"]
    App --> IEPaws --> AWSAPI["AWS service APIs"]

Key Services¶

Service	Role
Interface Endpoint	ENI in the consumer VPC with a private IP. Connects to AWS services or PrivateLink-powered services
Gateway Endpoint	Route table entry for S3 and DynamoDB (free, no ENI)
Endpoint Service	Producer side. An NLB (or GWLB) exposes a service through PrivateLink
Resource endpoint / resource configuration	Since 2024-12, a consumer can reach a single VPC resource (an RDS database, an IP, or a domain name) through PrivateLink or VPC Lattice without an NLB

Recommended Configurations¶

Use gateway endpoints for S3 and DynamoDB (free, route-table-based).
Use interface endpoints for other AWS services (SSM, KMS, SQS, ECR, and others). They avoid NAT gateway processing charges and keep traffic private.
Producers must use allowed principals to control which accounts can connect.
Combine PrivateLink with VPC endpoint policies for fine-grained access control.

2d. AWS Cloud WAN¶

Architecture Summary¶

AWS Cloud WAN is a managed global network. You describe it in one JSON core network policy. The policy lists Regions (each gets a core network edge), segments (isolated routing domains such as prod and dev), attachment policies that map VPC, VPN, Direct Connect, and SD-WAN attachments to segments by tag, and sharing rules between segments. Cloud WAN builds and routes the multi-Region mesh for you. Features added recently:

Service insertion (2024-06): steers traffic between segments or Regions through inspection VPCs, which are modeled as network function groups.
Routing policy (2025-11-20, policy version 2025.11): route filtering, summarization, and path preferences between Cloud WAN and external networks.

Here, one core network policy defines edges in three Regions, with attachments mapped to segments.

flowchart TB
    Policy["Core network policy (JSON)<br/>edges, segments, attachment policies, routing policy"] --> CN
    subgraph CN["Cloud WAN core network (global)"]
        CNE1["Core network edge<br/>us-east-1"] <--> CNE2["Core network edge<br/>eu-west-1"]
        CNE2 <--> CNE3["Core network edge<br/>ap-southeast-1"]
        CNE1 <--> CNE3
    end
    ProdUS["Prod VPC<br/>segment: prod"] --> CNE1
    DevUS["Dev VPC<br/>segment: dev"] --> CNE1
    ProdEU["Prod VPC<br/>segment: prod"] --> CNE2
    Insp["Inspection VPC<br/>network function group"] --> CNE2
    TGWap["Existing Transit Gateway<br/>peered, route table attachment"] --> CNE3
    DX["Direct Connect gateway<br/>or SD-WAN Connect"] --> CNE1

When to Choose Cloud WAN over TGW Peering¶

Three or more Regions, where TGW inter-Region peering means a static-route mesh that you maintain by hand.
You want segmentation across Regions as code (one policy, versioned, with change sets).
You are migrating gradually. Cloud WAN peers with existing TGWs, so a hybrid phase is supported.

TGW stays the simpler and cheaper choice for one or two Regions. Cloud WAN adds a $0.50 per hour charge for each core network edge (Reference).

2e. Amazon VPC Lattice¶

Architecture Summary¶

Amazon VPC Lattice is an application-layer service network. Instead of connecting networks, you register services (a listener and target groups of EC2, ECS, EKS pods, Lambda, or IPs) in a service network. You then associate consumer VPCs with that service network. Lattice handles service discovery, L7 routing, and IAM-based auth policies at the service and service-network level. It works across accounts through AWS RAM, even with overlapping CIDRs. Since 2024-12, resource configurations behind a resource gateway add TCP resources (for example RDS databases or on-premises IPs) to the same service network.

Here, a consumer account reaches two HTTP services and one TCP resource in a provider account through one service network.

flowchart LR
    subgraph Consumer["Consumer account"]
        C1["ECS task in VPC A"]
        C2["Lambda in VPC B"]
    end
    SN["VPC Lattice service network<br/>shared via AWS RAM, auth policy"]
    subgraph Provider["Provider account"]
        S1["Service: orders<br/>HTTPS listener, EKS pod targets"]
        S2["Service: payments<br/>Lambda target"]
        RG["Resource gateway"] --> RDS["RDS database<br/>resource configuration"]
    end
    C1 -->|"VPC association"| SN
    C2 -->|"VPC association"| SN
    SN --> S1
    SN --> S2
    SN -->|"TCP"| RG

Lattice is also one of the replacements AWS points to for AWS App Mesh, which reaches end of support on 2026-09-30 (Reference).

Connectivity Comparison Matrix¶

The side-by-side numbers (topology, scale, bandwidth, per-GB price) for all five options are in Reference. This flowchart walks through the choice.

flowchart TD
    Q1{"Connect whole networks<br/>or single services?"} -->|"Single services"| Q2{"HTTP/gRPC service-to-service<br/>with IAM auth?"}
    Q2 -->|Yes| Lattice["Amazon VPC Lattice"]
    Q2 -->|"No, one service or TCP endpoint"| PL["AWS PrivateLink"]
    Q1 -->|"Whole networks"| Q3{"How many VPCs?"}
    Q3 -->|"2-4, simple, high volume"| Peer["VPC peering"]
    Q3 -->|"Many"| Q4{"How many Regions?"}
    Q4 -->|"1-2"| TGW["Transit Gateway<br/>+ inter-Region peering"]
    Q4 -->|"3 or more, segments as code"| CWAN["AWS Cloud WAN"]

3. Multi-Account Strategy¶

Architecture Summary¶

AWS Organizations gives a tree of accounts: one root, organizational units (OUs, up to five levels deep), and member accounts. The account is the hardest isolation boundary on AWS. IAM, quotas, and billing are all per account, so blast radius stays small. AWS Control Tower, IAM Identity Center, and organization policies (SCPs, RCPs, declarative policies) add central governance, billing, and access control on top.

The OU layout below follows the AWS Organizing Your AWS Environment whitepaper: foundational OUs (Security, Infrastructure), a Workloads OU split by lifecycle, a Sandbox OU, and a Suspended OU for accounts being closed. Policies attached to an OU apply to every account below it.

flowchart TD
    Root["Organization root<br/>management account: billing, Organizations,<br/>Control Tower, IAM Identity Center"]
    Root --> SecOU["Security OU"]
    Root --> InfraOU["Infrastructure OU"]
    Root --> WlOU["Workloads OU"]
    Root --> SbxOU["Sandbox OU"]
    Root --> SusOU["Suspended OU<br/>deny-all SCP"]
    SecOU --> LogAcct["Log Archive account<br/>org CloudTrail + Config to S3"]
    SecOU --> AuditAcct["Audit / Security Tooling account<br/>delegated admin: GuardDuty, Security Hub, Inspector"]
    InfraOU --> NetAcct["Network account<br/>TGW or Cloud WAN, Direct Connect, Route 53 Resolver"]
    InfraOU --> SharedAcct["Shared Services account<br/>ECR, CI/CD, golden AMIs"]
    WlOU --> ProdOU["Prod OU"]
    WlOU --> SdlcOU["SDLC OU"]
    ProdOU --> AProd["team-a-prod"]
    ProdOU --> BProd["team-b-prod"]
    SdlcOU --> ADev["team-a-dev"]
    SdlcOU --> AStg["team-a-staging"]
    SbxOU --> Exp["Experiment accounts<br/>time-limited, budget-capped"]
    Pol["SCPs, RCPs, declarative policies"] -.->|"attached at OU, inherited"| WlOU

Key Services¶

Service	Role
AWS Organizations	Multi-account tree: root, OUs, member accounts. Consolidated billing. Policy attachment
AWS Control Tower	Landing zone setup, Account Factory, managed controls, drift detection
Service Control Policies (SCPs)	Cap what IAM principals in member accounts can do
Resource Control Policies (RCPs)	Cap what anyone, including external principals, can do to resources in member accounts
Declarative policies (EC2)	Enforce service configuration (VPC Block Public Access, IMDSv2, AMI and snapshot public sharing)
IAM Identity Center	Central workforce identity: users, groups, permission sets, external IdP federation (SAML 2.0 + SCIM)
CloudTrail	API audit logging for all accounts, sent to Log Archive
AWS Config	Compliance rules and configuration tracking across accounts
Security Hub CSPM / Security Hub	Posture checks (CSPM) and correlated, prioritized findings (the new Security Hub, GA 2025-12)
GuardDuty	Threat detection from CloudTrail, VPC Flow Logs, DNS logs, and runtime signals
CloudFormation StackSets	Deploy IaC across many accounts and Regions at once
AWS RAM	Share TGWs, subnets, Resolver rules, Lattice service networks, and IPAM pools across accounts

Recommended Configurations¶

Separate accounts by lifecycle stage: dev, staging, and prod in different accounts, not different VPCs in one account. This gives hard blast-radius isolation.
Central networking account: Owns the Transit Gateway or Cloud WAN, Direct Connect, and shared VPCs. Workload VPCs attach through RAM resource sharing.
Central logging: An organization CloudTrail trail and Config deliver to the Log Archive account's S3 buckets. Bucket policies (and ideally S3 Object Lock) prevent deletion.
Central security: Delegate Security Hub, GuardDuty, and Inspector administration to the Audit account. AWS Firewall Manager manages WAF and Network Firewall policies across accounts.
Account Factory: Use Control Tower Account Factory (or Account Factory for Terraform, AFT) to create new accounts with a baseline: IAM roles, controls, logging, networking, tags.
Workforce identity: Federate with an external IdP (Okta, Entra ID) through SAML 2.0 plus SCIM. Map IdP groups to permission sets in IAM Identity Center.
Root users: Turn on centralized root access (IAM, since 2024-11). It removes long-term root credentials from member accounts and allows short, task-scoped root sessions from the management or delegated admin account.
Cost management: Consolidated billing is automatic. Use cost allocation tags for cross-account attribution.

Control Types (Guardrails)¶

Type	Mechanism	Example
Preventive	SCP (blocks principal API calls)	Deny disabling CloudTrail, deny leaving the organization
Preventive	RCP (blocks access to resources)	Deny S3/KMS access from principals outside the organization
Preventive	Declarative policy (blocks configuration)	Enforce VPC Block Public Access, require IMDSv2
Detective	AWS Config rule	Detect S3 buckets without encryption, detect untagged resources
Proactive	CloudFormation Hook	Block non-compliant resources before deployment

Control Tower ships managed controls of every type. RCP-based managed controls arrived on 2024-11-15. Declarative policy-based controls followed.

Organizations Policy Model: SCPs, RCPs, and Declarative Policies¶

The three preventive policy types work at different points, which is why a mature landing zone uses all three:

SCPs filter the principal. They set the most that IAM users and roles in a member account can do, whatever their own policies say. They never grant anything. They do not apply to the management account or to service-linked roles. Since 2025-09-19, SCPs support the full IAM policy language (conditions, resource ARNs, NotResource, and NotAction with Allow).
RCPs (2024-11-13) filter the resource. They set the most that anyone can do to a resource in a member account, including principals from other accounts or outside AWS Organizations. That makes them the central tool for a data perimeter ("only my org's identities can touch my S3 buckets and KMS keys"). RCPs only support Deny statements, and they cover a growing list of services (see Reference).
Declarative policies (2024-12-01, the EC2 family) set the configuration instead of filtering API calls. When a declarative policy sets VPC Block Public Access, the account attribute is enforced by EC2 itself. It stays enforced when AWS later adds a new API that could change it. SCPs cannot promise that.

This flowchart shows how these policies combine with IAM policies when a principal in a member account calls an API on a resource in a member account. It is simplified. Session policies and some cross-account details are left out.

flowchart TD
    Req["API request"] --> Decl{"Declarative policy forbids<br/>the resulting configuration?"}
    Decl -->|Yes| DenyD["Denied by the service<br/>returns exception_message"]
    Decl -->|No| Explicit{"Explicit Deny in any SCP, RCP,<br/>identity, resource, or boundary policy?"}
    Explicit -->|Yes| Deny["Denied"]
    Explicit -->|No| SCPAllow{"SCP Allow at every level<br/>from root to the caller's account?"}
    SCPAllow -->|No| Deny
    SCPAllow -->|Yes| IdAllow{"Identity-based or resource-based<br/>policy allows?"}
    IdAllow -->|No| Deny
    IdAllow -->|Yes| Bound{"Permissions boundary<br/>allows (if set)?"}
    Bound -->|No| Deny
    Bound -->|Yes| Allow["Allowed"]

Real-World Example¶

A multinational enterprise organizes 80+ AWS accounts under Organizations. The Security OU holds the Log Archive and Audit accounts. The Infrastructure OU holds the Network account (Transit Gateway, Direct Connect) and Shared Services account (ECR, CI/CD). Each business unit has its own OU with dev/staging/prod accounts. Account Factory creates new accounts with baseline IAM roles, CloudTrail forwarding, Config rules, and a TGW attachment in under 30 minutes. SCPs enforce: no root user API calls, no leaving the organization, and approved Regions only. RCPs keep S3 and KMS resources reachable only from the organization's principals. A declarative policy turns on VPC Block Public Access in every production account.

4. Multi-Zone and Multi-Region Deployment Patterns¶

Multi-Zone (Intra-Region)¶

AWS Regions contain several Availability Zones (every Region has at least three). An AZ is one or more physically separate data centers with independent power and networking. AZs in a Region are linked with low-latency links (single-digit milliseconds). Spreading across at least two AZs protects against a single-data-center failure.

Key Services and Features¶

Service	Multi-AZ Feature
EC2	Instances across AZs. Auto Scaling group spanning several AZs
ALB / NLB	Distributes traffic across AZs. Health checks remove unhealthy targets
RDS	Multi-AZ DB instance with synchronous standby and automatic failover (typically 60-120 s). Multi-AZ DB cluster with two readable standbys fails over faster
Aurora	Up to 15 read replicas across AZs on shared storage. Failover typically under 35 s
S3	Standard storage classes keep data across at least 3 AZs (One Zone classes excepted)
ElastiCache	Multi-AZ with automatic failover for Valkey and Redis OSS
EKS	Multi-AZ node groups. Pod topology spread constraints

Recommended Configurations¶

Minimum two AZs for any production workload. Three AZs for critical workloads.
The ALB needs targets in every AZ where you deploy workloads.
RDS: enable Multi-AZ. Plan for a 1-2 minute failover window, and use RDS Proxy or short DNS TTLs in clients.
EC2 Auto Scaling group: spread instances evenly across AZs.

Multi-Region¶

Deploy across geographically separated Regions for disaster recovery, compliance, or latency.

Key Services and Features¶

Service	Multi-Region Feature
Transit Gateway	Inter-Region peering over the AWS backbone. Encrypted
Cloud WAN	Policy-defined global network with segments across Regions
Global Accelerator	Anycast IPs with automatic regional failover
Route 53	Latency, geolocation, weighted, and failover routing policies
Aurora Global Database	Storage-level replication, typically under 1 s lag. Cross-Region recovery in under 1 minute. Managed switchover and write forwarding
DynamoDB Global Tables	Multi-active, multi-Region replication. Eventual consistency by default. Multi-Region strong consistency (RPO 0) GA since 2025-06-30
S3 Cross-Region Replication	Asynchronous object replication between buckets in different Regions
ElastiCache Global Datastore	Cross-Region replication for Valkey and Redis OSS
CloudFront	Global CDN with edge caching and origin failover

Recommended Configurations¶

Use Transit Gateway inter-Region peering or Cloud WAN for private cross-Region connectivity.
Use Route 53 or Global Accelerator for DNS-based or anycast failover.
Use Aurora Global Database for relational data with about 1 s RPO and under 1 minute RTO.
Use DynamoDB Global Tables for NoSQL data that needs multi-Region active-active writes. Pick strong consistency mode where a zero RPO matters more than write latency.
Keep the application layers stateless to simplify failover. Move all state to managed services.

Real-World Example¶

An e-commerce platform runs in us-east-1 as primary and us-west-2 as secondary. Transit Gateway inter-Region peering connects the two Regions. Aurora Global Database replicates data with sub-second lag. S3 CRR replicates static assets. Route 53 failover routing with health checks shifts DNS to us-west-2 if the primary becomes unhealthy. The application tier is stateless (ECS Fargate + Auto Scaling), so us-west-2 can scale from warm standby to full capacity in minutes.

5. Disaster Recovery (DR)¶

DR Strategies¶

The four strategies from the AWS DR whitepaper trade cost against recovery time. Each step up keeps more of the stack running in the recovery Region.

Strategy	RPO	RTO	Cost	Pattern
Backup & Restore	Hours	24h+	$	S3 cross-Region backups, AMI copies, RDS snapshots, AWS Backup
Pilot Light	Minutes	Hours	$$	Core infra deployed (DB replicas). Compute off
Warm Standby	Seconds	Minutes	$$$	Scaled-down but working stack running
Active-Active	Near zero	Near zero	$$$$	Full capacity in both Regions. Multi-active writes

Pilot Light¶

In pilot light, data replicates continuously, but the DR Region runs no compute. The Auto Scaling group is sized at zero, or the stack exists only in IaC.

flowchart LR
    subgraph RA["Region A (primary)"]
        ALBa["ALB"] --> ASGa["Auto Scaling group<br/>desired 10"]
        ASGa --> AurP["Aurora primary cluster"]
    end
    subgraph RB["Region B (pilot light)"]
        ALBb["ALB (idle)"] --> ASGb["Auto Scaling group<br/>desired 0 or IaC only"]
        AurS["Aurora secondary cluster<br/>read-only"]
    end
    AurP -->|"Aurora Global Database<br/>storage replication"| AurS
    R53["Route 53 failover record<br/>+ health check"] --> ALBa
    R53 -.->|"on failure"| ALBb

Aurora Global Database replicates data continuously.
Compute is not running in the DR Region. It is defined in IaC (Terraform/CloudFormation) or sized to zero.
On failure, a Route 53 health check marks the primary unhealthy and shifts DNS. IaC deploys or scales compute in the DR Region. The Aurora secondary is promoted.

Warm Standby¶

Warm standby is the same layout with the DR Auto Scaling group running at reduced capacity (for example desired 2 instead of 0), and optionally an ElastiCache Global Datastore replica.

Region B runs the full stack at reduced capacity.
On failure, the Auto Scaling group scales to production capacity and the Aurora secondary is promoted. Failover is faster than pilot light because compute is already running.

Key Difference: Pilot Light vs. Warm Standby

Pilot light cannot serve requests without extra action (deploying compute, promoting the DB). Warm standby can serve traffic at once at reduced capacity. Recovery only needs scaling.

Active-Active (Multi-Region)¶

In active-active, both Regions take production traffic, and data is replicated in both directions.

flowchart LR
    GA["Global Accelerator or Route 53<br/>latency / geo routing"] --> ALBa
    GA --> ALBb
    subgraph RA["Region A (active)"]
        ALBa["ALB"] --> ASGa["Auto Scaling group<br/>full capacity"]
        ASGa --> DDBa["DynamoDB table replica"]
        ASGa --> ECa["ElastiCache Global Datastore"]
    end
    subgraph RB["Region B (active)"]
        ALBb["ALB"] --> ASGb["Auto Scaling group<br/>full capacity"]
        ASGb --> DDBb["DynamoDB table replica"]
        ASGb --> ECb["ElastiCache Global Datastore"]
    end
    DDBa <-->|"Global Tables replication"| DDBb
    ECa -->|"primary to secondary"| ECb

DynamoDB Global Tables give multi-active, multi-Region replication. The default mode is asynchronous with last-writer-wins conflict resolution. Multi-Region strong consistency gives RPO 0 at higher write latency.
Aurora Global Database can use write forwarding, so secondary Regions accept writes. The primary still applies them, so it is not true multi-writer.
Global Accelerator routes users to the nearest healthy Region with automatic failover.
The application must handle eventual consistency and conflict resolution for multi-active writes.
ElastiCache Global Datastore has one primary Region. Secondary Regions are read-only until promoted.

Recommended Configurations¶

Define RTO/RPO targets first. They decide the strategy and the cost.
Use Infrastructure as Code (Terraform or CloudFormation) to define the full stack. In pilot light and warm standby, IaC enables fast provisioning.
Test failover regularly (quarterly at minimum). Use Route 53 ARC zonal shift and Region switch, or Global Accelerator traffic dials.
Stateless app tier: Move all state to managed services (ElastiCache, DynamoDB, S3).
Separate DR automation from production: Use separate Terraform state files or CloudFormation stacks for the DR Region.

6. DMZ / Network Perimeter Patterns¶

Architecture Summary¶

AWS supports three deployment models for network inspection:

Distributed: AWS Network Firewall in each VPC.
Centralized: Network Firewall in a dedicated inspection VPC behind the TGW, or attached natively to the TGW (recommended for enterprises).
Combined: Centralized for east-west and egress. Distributed for internet ingress.

The centralized model is the most common in enterprises. North-south and east-west flows both pass the firewall before they reach a spoke.

flowchart TD
    Internet["Internet"] --> IGW["Internet gateway<br/>ingress/egress VPC"]
    IGW --> NFW["AWS Network Firewall<br/>inspection VPC or native TGW attachment"]
    NFW <--> TGW["Transit Gateway"]
    TGW <--> VPCA["Workload VPC A<br/>private subnets only"]
    TGW <--> VPCB["Workload VPC B<br/>private subnets only"]
    TGW <--> DX["Direct Connect<br/>to on-premises"]

Key Services¶

Service	Role in Perimeter
AWS Network Firewall	Managed stateful L3-L7 inspection. Suricata-compatible rules, domain (FQDN) filtering, IPS/IDS, TLS inspection. Deploy an endpoint in each AZ
AWS WAF	Application-layer (L7) filtering on ALB, CloudFront, API Gateway, AppSync, Cognito, App Runner, and Verified Access. AWS Managed Rules (Core rule set covering OWASP Top 10 categories, SQLi, Known Bad Inputs, Bot Control)
AWS Shield Standard	Free L3/L4 DDoS protection for all AWS customers
AWS Shield Advanced	Paid DDoS protection with the Shield Response Team, cost protection, and advanced metrics
AWS Firewall Manager	Central management of WAF, Network Firewall, security groups, DNS Firewall, and Shield Advanced across accounts
Route 53 Resolver DNS Firewall	Outbound DNS filtering against DNS exfiltration and malicious domains
Security Groups	Stateful per-ENI firewall. Reference SGs in rules for dynamic, IP-free policies
Network ACLs	Stateless subnet-level filter. Broad rules applied to every ENI in a subnet

Defense-in-Depth Layers¶

Layer	Control
Edge	CloudFront + AWS Shield (DDoS), Route 53 (DNS)
Perimeter	AWS WAF (managed rules, bot control, rate limiting)
Network	AWS Network Firewall (stateful IPS/IDS, FQDN filtering)
Subnet	Network ACLs (stateless, broad rules)
Instance	Security groups (stateful, per-ENI least privilege)
DNS	Route 53 Resolver DNS Firewall (exfiltration prevention)
Host	Amazon Inspector (vulnerability scanning), SSM Patch Manager
Application	Application-level auth (Cognito, IAM, OAuth)

Recommended Configurations¶

Central inspection: Put Network Firewall in a dedicated inspection VPC, or use the native TGW attachment (since 2025-06). Route all TGW traffic (north-south and east-west) through it.
Symmetric routing: Network Firewall does not support asymmetric routing. TGW and VPC routes must send return traffic through the same firewall endpoint. Use appliance mode on the inspection VPC attachment.
Firewall per AZ: Deploy a firewall endpoint in every AZ where workloads run.
Stream exception policy: Set it to "Continue" or "Reject" (not "Drop") to avoid silent blocking of mid-stream flows after a rule change.
WAF on all external ALBs and CloudFront distributions: Start with AWS Managed Rules (Core rule set, Known Bad Inputs, SQL database, IP reputation).
DNS Firewall: Block known malicious domains. For sensitive workloads, allow DNS resolution only for approved domains.
Firewall Manager: Use one Firewall Manager policy per scope. Several policies on the same VPC create several firewalls, which adds cost and complexity.

Real-World Example¶

A fintech company sends all internet traffic through an inspection VPC in us-east-1. The inspection VPC has Network Firewall endpoints in three AZs. Suricata rules block known threat signatures and allow outbound traffic only to an allow-list of FQDNs. All workload VPCs connect through TGW, with route tables that force traffic through the inspection VPC. AWS WAF on the external ALB gives OWASP-class protection. Shield Advanced protects against volumetric DDoS. Firewall Manager enforces WAF and Network Firewall policies across all 40 accounts in the organization.

7. Landing Zone Best Practices¶

Architecture Summary¶

An AWS landing zone is a well-architected, multi-account environment, usually built with AWS Control Tower. It gives controls, account provisioning, central logging, and security baselines for all workloads. The alternatives are the open-source Landing Zone Accelerator on AWS (LZA), which deploys on top of Control Tower, or a custom build with Terraform (often AFT).

Landing zone 4.0 (2025-11-17) changed what Control Tower requires

Before 4.0, Control Tower required a Security OU with Log Archive and Audit accounts and turned on its own Config and CloudTrail setup. Since 4.0, Config, CloudTrail, SecurityRoles, and Backup integrations are each optional. Config and CloudTrail get dedicated resources. The OU layout is yours to define. You can even run Control Tower "controls-only" on an existing organization. Landing zones on 3.1 or later can upgrade during an Update or Reset. Details are in Reference.

Core Landing Zone Components¶

This diagram shows how Control Tower in the management account applies controls, creates accounts, and routes logs and findings to the Security OU accounts.

flowchart TB
    subgraph Mgmt["Management account"]
        CT["AWS Control Tower<br/>landing zone 4.0"]
        ORG["AWS Organizations"]
        IDC["IAM Identity Center"]
        AF["Account Factory / AFT"]
    end
    CT -->|"preventive controls:<br/>SCP, RCP, declarative"| ORG
    ORG -->|"policy inheritance"| Accts["Enrolled member accounts"]
    CT -->|"detective controls:<br/>Config rules"| Accts
    CT -->|"proactive controls:<br/>CloudFormation Hooks"| Accts
    AF -->|"create account + baseline"| Accts
    IDC -->|"permission sets become roles"| Accts
    Accts -->|"org CloudTrail, Config"| Log["Log Archive account<br/>S3, versioned, Object Lock"]
    Accts -->|"findings"| Audit["Audit account<br/>Security Hub CSPM, GuardDuty, Inspector"]
    CT -.->|"drift detection"| Accts

Key Services¶

Service	Role in Landing Zone
AWS Control Tower	Landing zone setup, Account Factory, managed controls, drift detection
AWS Organizations	Account tree: root, OUs, member accounts. SCP, RCP, and declarative policy enforcement
IAM Identity Center	Central SSO with permission sets. External IdP federation (SAML 2.0 + SCIM). Multi-Region replication since 2026-02
CloudTrail	Org-wide API audit logging to the Log Archive account
AWS Config	Continuous compliance evaluation with managed and custom rules
Security Hub CSPM	Standards-based posture checks (CIS, AWS FSBP, PCI DSS) across accounts
GuardDuty	Threat detection across accounts
AWS Firewall Manager	Central WAF, Network Firewall, SG, and DNS Firewall policies
Service Catalog	Self-service product provisioning with governance. Account Factory uses it
Terraform / CloudFormation / LZA	IaC for a repeatable landing zone deployment

Recommended Configurations¶

Start with Control Tower: Use the built-in landing zone to set up logging, security accounts, and baseline controls. It is faster and less error-prone than a manual setup. On 4.0, decide on purpose which integrations (Config, CloudTrail, Backup, SecurityRoles) Control Tower should own.
Account Factory: Use Control Tower Account Factory or Account Factory for Terraform (AFT) to create new accounts with:
IAM Identity Center assignments for admin and operator access
CloudTrail forwarding to the Log Archive account
Config rules (baseline compliance)
TGW or Cloud WAN attachment to the central network
Resource tags (owner, environment, cost-center)
Essential SCPs (preventive controls):
Deny disabling or deleting CloudTrail and Config in all accounts
Deny root user actions in member accounts (SCPs never apply to the management account, so protect its root user with MFA and keep it unused)
Deny creating resources outside approved Regions (exempt global services such as IAM, Organizations, Route 53, CloudFront)
Deny leaving the AWS organization
Deny public S3 bucket policies in production OUs (or enforce it with an S3 policy for account-level Block Public Access)
RCPs and declarative policies:
RCP data perimeter: deny access to S3, KMS, SQS, STS, and Secrets Manager resources for principals outside the organization (aws:PrincipalOrgID), with exceptions for AWS service principals
EC2 declarative policy: VPC Block Public Access, AMI and snapshot block public access, IMDSv2 by default
Central networking:
The Network account owns the Transit Gateway (or Cloud WAN) and Direct Connect
RAM shares the TGW with workload accounts or whole OUs
An inspection VPC or native TGW attachment with Network Firewall inspects traffic centrally
Cloud WAN or TGW inter-Region peering for multi-Region connectivity
Central logging and monitoring:
An organization CloudTrail trail delivers to the Log Archive S3 bucket (versioned, with Object Lock or MFA delete)
Config aggregation in the Audit account
Security Hub CSPM cross-account findings aggregation
GuardDuty delegated admin in the Audit account
Identity and access:
Federate with an external IdP through SAML 2.0, and provision users and groups with SCIM
Map IdP groups to permission sets in IAM Identity Center
Enforce MFA for all human users
Use IAM roles (not long-lived access keys) for cross-account access and CI/CD (OIDC federation)
Block IAM user and access key creation with an SCP (iam:CreateUser, iam:CreateAccessKey) outside break-glass roles
Enable centralized root access and remove member-account root credentials
IaC for the landing zone itself:
Define the landing zone in Terraform, or use Landing Zone Accelerator (LZA)
Keep all configuration in version control
Run changes through a CI/CD pipeline (plan, then apply)
AWS offers Landing Zone Accelerator on AWS as an open-source reference implementation
Regular drift detection:
Control Tower detects drift in controls, OUs, and accounts
Config rules evaluate continuously
Alert on non-compliant resources
Review SCPs and RCPs regularly for relevance

Real-World Example¶

A large retail enterprise builds its landing zone with AWS Control Tower and Account Factory for Terraform. The management account holds Organizations with four top-level OUs: Security, Infrastructure, Workloads, and Sandbox. The Security OU contains the Log Archive and Audit accounts. The Infrastructure OU contains the Network account (Transit Gateway, Direct Connect, Route 53 private hosted zones) and the Shared Services account (ECR, CodePipeline). Each business unit (Online, Stores, Supply Chain) has a sub-OU under Workloads with dev/staging/prod accounts. Account Factory creates new accounts with baseline IAM roles, CloudTrail forwarding, Config rules, and a TGW attachment in under 30 minutes. SCPs enforce: no root user API calls and resources only in approved Regions (us-east-1, us-west-2, eu-west-1). An RCP keeps S3 buckets private to the organization. Firewall Manager enforces WAF policies on all ALBs across accounts.

8. Service Naming Quick Reference¶

The service-name and abbreviation table moved to Reference: Service Naming Quick Reference.

9. Security Model¶

This section covers identity and access management, network security, data protection, and compliance on AWS. Setup commands are in How-to Guides. Lookup tables (IAM Identity Center features, KMS key types, S3 encryption modes, compliance programs) are in Reference.

Identity & Access¶

IAM Users, Roles & Policies¶

AWS IAM gives fine-grained access control for all AWS services.

Concept	Description
IAM User	Long-lived identity with a console password and/or access keys. Use rarely. Prefer roles for workloads and Identity Center for people
IAM Group	Collection of IAM users. Policies attached to a group apply to all members
IAM Role	Identity assumed by trusted entities (AWS services, federated users, other accounts). Uses temporary STS credentials
IAM Policy	JSON document with Effect (Allow/Deny), Action, Resource, and Condition. Identity-based or resource-based
Permission Boundary	IAM policy that sets the most permissions a role or user can get, whatever its identity-based policies say

Avoid long-lived access keys

IAM access keys are the largest single source of credential leaks. Use IAM roles with temporary STS credentials for EC2 (instance profiles), Lambda (execution roles), EKS (IRSA or EKS Pod Identity), and CI/CD pipelines (OIDC federation with GitHub Actions, GitLab, and others).

Organizations & Service Control Policies (SCPs)¶

SCPs are the principal-side guardrail in AWS Organizations. They define the most permissions available to all principals in an account or OU. SCPs do not grant permissions. They only limit what identity-based policies can grant. RCPs are the resource-side counterpart. How the two combine is explained in Organizations Policy Model.

Common SCP patterns:

Deny disabling CloudTrail: Stops any principal from stopping or deleting trails
Deny root user API calls: Blocks root user actions in member accounts. With centralized root access, member accounts have no root password at all, and privileged root tasks run as short root sessions
Region restriction: Denies API calls outside approved Regions (for example only us-east-1, us-west-2, eu-west-1), with exemptions for global services
Deny public S3: Blocks s3:PutBucketPolicy and s3:PutBucketPublicAccessBlock changes that would allow public access

IAM Identity Center (SSO)¶

IAM Identity Center (formerly AWS Single Sign-On) is the central workforce identity service for all accounts in the organization. Users come from the built-in directory, Active Directory, or an external IdP. You assign them to permission sets per account. Each assignment becomes an AWSReservedSSO_* IAM role in the target account. Since 2026-02-03, an organization instance connected to an external IdP can replicate to more Regions. The access portal then keeps working if the primary Region has an outage.

This sequence shows an engineer signing in through an external IdP and landing in a member account.

sequenceDiagram
    participant IdP as External IdP (Entra ID or Okta)
    participant U as Engineer
    participant IDC as IAM Identity Center (primary Region)
    participant Acct as Member account
    IdP->>IDC: SCIM 2.0 sync of users and groups
    U->>IDC: Open the AWS access portal
    IDC->>IdP: SAML 2.0 authentication request
    IdP-->>IDC: SAML assertion (MFA enforced at the IdP)
    IDC-->>U: Portal lists account and permission set assignments
    U->>IDC: Choose account and permission set
    IDC->>Acct: Federate into the AWSReservedSSO role
    Acct-->>U: Temporary credentials for the permission set session (1-12 h)
    U->>Acct: API calls, filtered by SCPs, RCPs, and role policies

Network Security¶

Security Groups¶

Security groups are stateful firewalls on each ENI. All inbound traffic is denied by default. Outbound is allowed by default. Rules are additive (no explicit deny). Reference other security groups in rules for dynamic, IP-free policies.

Network ACLs (NACLs)¶

NACLs are stateless, subnet-level filters. They support both allow and deny rules, evaluated in numeric order. Use NACLs as a broad second layer. Rely on security groups for primary access control.

VPC Endpoints & PrivateLink¶

Keep traffic to AWS services off the public internet:

Gateway endpoints: Free, route-table-based access to S3 and DynamoDB
Interface endpoints: ENI-based private access to 100+ AWS services (KMS, SQS, ECR, SSM, and others)
VPC endpoint policies: JSON policies that limit which principals and resources the endpoint can reach. They are the network half of a data perimeter. RCPs are the resource half

AWS Network Firewall¶

Managed stateful L3-L7 firewall in inspection VPCs or attached natively to a Transit Gateway. It supports Suricata-compatible IPS/IDS rules, FQDN filtering, and TLS inspection. Deploy it behind Transit Gateway for central inspection of all traffic.

AWS Firewall Manager¶

Central management of WAF rules, Network Firewall policies, security groups, DNS Firewall rules, and Shield Advanced across all accounts. Apply policies from a single administrator account.

Data Protection¶

KMS (Key Management Service)¶

KMS gives central key management for encryption at rest. More than 100 AWS services integrate with it. You choose between AWS managed keys (no fee, rotated yearly) and customer managed keys (key policy, grants, configurable rotation, $1/month). You can also back keys with CloudHSM or an external key store. Multi-Region keys share key material across Regions. IAM Identity Center multi-Region replication needs one. The full comparison is in Reference.

S3 Encryption¶

Since 2023-01-05, S3 encrypts all new objects with SSE-S3 by default. Use a bucket policy or default-encryption setting to enforce SSE-KMS when you need key-use audit trails or cross-account key control. The mode comparison is in Reference.

Secrets Manager¶

Secrets Manager stores and rotates secrets (database credentials, API keys, tokens). Automatic rotation runs a Lambda rotation function on a schedule. Secrets that another service manages for you (for example an RDS master user password managed by RDS) use managed rotation instead. Commands are in How-to Guides.

ACM (AWS Certificate Manager)¶

ACM issues free public TLS certificates, and AWS Private CA provides private certificates. ACM certificates on ALB, CloudFront, and API Gateway renew automatically.

Compliance¶

Shared Responsibility Model¶

AWS works under a shared responsibility model:

Responsibility	AWS	Customer
Physical infrastructure	Data centers, hardware, global network	N/A
Hypervisor & managed services	Patching, HA of managed services (RDS, S3, Lambda)	N/A
Guest OS & runtime	N/A	Patching EC2 OS, container images, Lambda runtimes
Network configuration	N/A	Security groups, NACLs, TLS, VPN setup
Data encryption	Provide KMS, S3 encryption, ACM	Enable and configure encryption for each service
Identity & access	Provide IAM, STS, Identity Center	Configure policies, MFA, role trust, least privilege

AWS Artifact¶

AWS Artifact gives on-demand access to AWS compliance reports (SOC 1/2/3, PCI DSS, ISO 27001, FedRAMP) and agreements (for example the HIPAA BAA). Download reports from the Artifact console. The certification list is in Reference.

Compliance is not inherited

An AWS certification means the infrastructure is compliant. You must still configure your workloads correctly (encryption, access control, logging, patching) to meet your own compliance obligations. Use AWS Config conformance packs and Security Hub CSPM standards to validate your posture continuously.