1.4.1. Regions, Availability Zones, and Data Residency
First Principle: AWS Regions provide complete geographic and jurisdictional isolation, while Availability Zones provide fault isolation within a Region — together they enable both compliance (data stays where you put it) and resilience (failures are contained to the smallest possible blast radius).
Regions are completely independent deployments of the full AWS platform. Key security implications:
- Data stored in a Region stays in that Region unless you explicitly enable cross-Region replication
- Each Region has independent IAM endpoints, but IAM itself is a global service
- Some compliance frameworks require data to remain in specific Regions (GDPR → EU Regions)
- Not all services are available in all Regions — verify service availability for your security tools
Availability Zones (AZs) are physically separate data centers within a Region:
- Each AZ has independent power, cooling, and networking
- AZs within a Region are connected by low-latency, high-bandwidth links
- A failure in one AZ doesn't affect others — design multi-AZ for resilience
- Security: deploy across AZs for availability, but remember that VPC spans all AZs in a Region
Data Residency Architecture:
In this pattern, customer data stays in the EU Region (compliance), while CloudFront caches static assets globally (performance). No customer data crosses the Region boundary.
⚠️ Exam Trap: IAM is a global service — IAM users, roles, and policies are not Region-specific. But data services (S3, RDS, DynamoDB) are Regional. Don't confuse global services with Regional data storage.
Scenario: A healthcare company needs to ensure patient records stay in a specific Region for HIPAA compliance. They're designing a disaster recovery strategy that requires cross-Region backups. How do you balance data residency with DR requirements?
Reflection Question: When does cross-Region replication create a compliance risk, and how do you mitigate it while maintaining disaster recovery capability?
