Lesson 1.2: Understanding AWS Global Infrastructure
Every workload deployed on AWS runs within a specific geographical and architectural boundary. That boundary determines where data lives, how failures are isolated, and how traffic is routed. Many application-level design decisions, including database configuration, scaling strategy, session handling, replication, and caching, depend on understanding this infrastructure model. For a developer preparing for DVA-C02, infrastructure awareness is essential. It directly affects how we design for high availability, interpret failover behavior, and reason about cross-region replication and global traffic routing.
Regions as primary architectural boundaries
An AWS region is a geographically isolated area containing multiple availability zones. Each region operates independently, with its own control plane, service endpoints, and resource scope. When creating resources such as EC2 instances, RDS databases, or DynamoDB tables, the region must be explicitly selected. Regions define fault isolation at the highest level: a disruption in one region does not automatically affect others. Resources inside the same region share dependencies such as regional endpoints and internal service infrastructure. Region selection also determines data residency and compliance.
From a development perspective, region awareness influences:
- Latency between users and infrastructure
- Cross-region replication strategies
- Disaster recovery planning
Choosing a region close to the primary user base reduces latency and improves performance, while globally distributed applications require additional considerations such as traffic routing and replication. A common mistake is relying on default region configuration rather than specifying it explicitly.
aws ec2 run-instances \
--image-id ami-123456 \
--instance-type t3.micro \
--region us-east-1
This command launches an EC2 instance in a specific region, demonstrating how region selection affects where your workload is deployed.
Availability zones as high-availability primitives
Each AWS region contains multiple availability zones, made up of physically separate data centers with independent power, cooling, and networking. While connected by high-bandwidth, low-latency links, each AZ operates independently to ensure that a failure in one zone does not impact others. Deploying workloads across multiple AZs reduces the risk of service disruption.
High availability in AWS can be achieved by following several key patterns that ensure workloads continue running even when failures occur in a single Availability Zone:
- EC2 instances deployed across AZs using Auto Scaling groups
- An Application Load Balancer distributes traffic across multiple AZs and routes requests only to healthy instances, ensuring high availability even if instances in one zone fail.
- RDS Multi-AZ deployments replicate data synchronously to a standby instance
- DynamoDB automatically replicates data across multiple AZs within a region
The following command creates an Auto Scaling group across multiple AZs to ensure compute availability even if one AZ fails.
aws autoscaling create-auto-scaling-group \
--auto-scaling-group-name my-asg \
--min-size 2 \
--max-size 4 \
--desired-capacity 2 \
--vpc-zone-identifier subnet-az1,subnet-az2
How edge locations extend global performance
Edge locations are part of AWS’s global edge network and are used by CloudFront, WAF, and Route 53. They are optimized for caching content and routing requests rather than running core applications. When CloudFront sits in front of an S3 bucket or an Application Load Balancer:
- Content is cached at edge locations near users, reducing latency
- Load on origin services is reduced as repeated requests are served from cache
- Static assets and APIs are delivered with improved performance globally
Multi-region architecture and disaster recovery
Multi-region architectures replicate infrastructure and data across separate AWS regions to provide disaster recovery and improve global performance. Key patterns include:
- DynamoDB global tables enable active-active replication, allowing applications to read and write data from multiple regions simultaneously.
- Amazon Route 53 routes user traffic based on health checks, directing requests to healthy endpoints in alternative regions to maintain availability and minimize downtime.
- Amazon S3 cross-region replication automatically duplicates objects to a bucket in another region, ensuring data durability and continuity during regional outages.
Cross-region replication is typically asynchronous, introducing replication lag and eventual consistency.
Developers must also account for regional scope when building and deploying applications, including:
- SDK configuration for region selection
- Endpoint selection for service requests
- Correct resource ARN construction
- Environment-specific deployment pipelines
Failing to account for regional scope can lead to issues such as AccessDenied errors in the wrong region or inconsistent replication behavior.
The following command sets up a DynamoDB global table across two regions, illustrating cross-region replication for disaster recovery.
aws dynamodb create-global-table \
--global-table-name myTable \
--replication-group RegionName=us-east-1 RegionName=eu-west-1
This command demonstrates explicitly replicating data between regions for disaster recovery:
aws s3 cp s3://mybucket/ s3://mybucket-eu/ --recursive --source-region us-west-2 --region eu-west-1
This S3 cross-region copy illustrates how data must be explicitly replicated between regions to support disaster recovery strategies.
Multi-AZ vs. multi-region considerations
Multi-AZ improves availability within a region with low-latency synchronous replication. Multi-region architectures handle regional outages and global distribution but introduce higher latency and operational complexity. For DVA-C02, it is essential to distinguish between these patterns:
- Intra-region resilience: achieved with Multi-AZ
- Cross-region disaster recovery: requires multi-region design
Understanding AWS global infrastructure directly informs how we design resilient and performant systems. Regions define the outer boundary of failure isolation, availability zones provide resilience within that boundary, and edge locations extend performance closer to users. Combining these layers achieves high availability, fault tolerance, and low latency across both local and global scales.
My name is Naeem ul Haq. I’ve been working with AWS since its early days and have deep expertise across its evolving ecosystem.
