Day 1 - AWS Infrastructure Through an Operator's Eyes: Regions, AZs, and the Boundary of Responsibility

3:12 AM, your phone vibrates. A PagerDuty alert: "us-east-1 API Gateway 5xx rate above 30%, duration 4m." You log in to the console and open the Region selector. Only us-east-1 is red, and ap-northeast-2 is fine. But 99% of our company's users are in Korea. Why did a US Region failure set off our alarm? To find the answer, you need to know which component of our infrastructure is tied to which Region, and where IAM, Route 53, and CloudFront, which say "Global" at the top right of the console, actually run.

SOA-C02, the exam for the operator, asks less "which service is what" and more "where do you look when a failure happens," "how do you roll back when a change goes wrong," and "where do you start digging when costs spike." The starting point is the map of AWS infrastructure and the shared responsibility model. Only when these two pictures are firmly lodged in your head do you get a feel for in what order to search CloudWatch, CloudTrail, Config, and the Health Dashboard. Over the 12 weeks we will repeat the same line of thinking. Today is the first picture.

Regions: The Unit Where Data Sovereignty, Price, and Service Launch Schedules Diverge

A Region is not simply "a city with data centers." Data sovereignty, hourly price, service availability timing, compliance certifications, and control plane dependencies all diverge at the Region level. As of 2025, AWS operates 34 commercial Regions worldwide (separately, 2 GovCloud, 2 China, and 1 Secret), and each Region has at least 3 Availability Zones (AZs). A new Region launch is planned over a long horizon, often called "a capital decision similar to building one nuclear reactor" (2 to 3 years on average).

From an operator's standpoint, there are five dimensions to look at when choosing a Region.

The us-east-1 outage of December 7, 2021. As an AWS internal network auto-scaling system ran away, the us-east-1 control plane (EC2 API, STS, the IAM console, Cognito, Connect) was paralyzed for nearly 9 hours. The interesting point is that Netflix, Disney+, Slack, Robinhood, and Ring (an Amazon-owned IoT subsidiary) all went down together even though EC2 instances in other Regions were running fine. There are three reasons. First, the STS global endpoint (sts.amazonaws.com) was actually an alias that called us-east-1 (today you can force Regional endpoints, but the SDK default is still the global one). Second, the IAM console and the Route 53 control plane are in us-east-1, so even operators in other Regions experienced "cannot log in to the console." Third, many companies' CI/CD pipelines were calling us-east-1 ECR without caching. AWS official post-incident summary. Lesson for operators: even a service labeled global can be tied to a specific Region internally. If you do not know this and assume "it is global, so it must be safe," you get an incident.

IAM, Route 53 (public hosted zones), CloudFront, WAF (the part attached to CloudFront), Organizations, and the AWS Account itself are shown as "Global," but internally their control planes are in us-east-1, and the edge or Region-level data planes cache and replicate that data. That is, when us-east-1 dies, write operations such as creating new IAM users, changing policies, and changing Route 53 records are blocked. On the other hand, data plane operations that call EC2 in other Regions with already-issued IAM credentials, DNS responses for already-deployed Route 53 records, and cached responses from CloudFront edges survive. This is called "control plane/data plane separation," a core architectural principle that Werner Vogels (AWS CTO) emphasizes in the re:Invent keynote every year. In SOA-C02 scenarios, a question such as "how do you keep operating even during a us-east-1 outage?" often tests this separation.

Isolation between Regions is the largest-scale implementation of the bulkhead pattern (Michael Nygard, "Release It!", 2007). Like a ship design that places bulkheads so that the whole ship does not sink when one compartment floods, bulkheads are placed explicitly so that a control plane failure in one Region does not propagate to other Regions. Also, Chapter 22 of the Google SRE Book (Beyer et al., 2016), "Addressing Cascading Failures," covers the same principle: "define failure domains clearly, and design fault tolerance on top of them." AWS's Region isolation is the result of raising that failure domain to the geographic level.

Availability Zones (AZs): The Operator's First Isolation Tool

An AZ is a group of one or more physically and logically independent data centers within the same Region. AZs are connected by low-latency fiber within 1 to 2 ms, so synchronous replication is possible, yet they are separated enough that a power, cooling, or network failure in one AZ does not spread to another (usually several km to tens of km, outside the radius of impact of tornadoes and floods). Even data centers within the same AZ use separate power and cooling, and each data center has N+1 redundancy with diesel generators + UPS + dual power grids.

Three principles for handling AZs from the operator's perspective:

1. Spread all stateful resources across at least 2 AZs: RDS Multi-AZ, Aurora cluster (automatically spread across 3 AZs), ElastiCache replication group, MSK brokers, OpenSearch domain
2. Spread all stateless workloads evenly across AZs with an ASG: specify 3 or more in the ASG's AvailabilityZones parameter + enable AZRebalance
3. Do not tie operations themselves to an AZ: bastions, jump hosts, NAT GW, ALB target groups, and ECS services are all placed per AZ

[Region: ap-northeast-2 (Seoul)]
   │
   ├─ AZ-a (apne2-az1)  ┐
   ├─ AZ-b (apne2-az2)  ├─ Synchronous replication possible (RTT 1-2ms)
   ├─ AZ-c (apne2-az3)  │  Multi-AZ RDS / ASG spread / NLB Cross-Zone
   └─ AZ-d (apne2-az4)  ┘  Aurora cluster automatic 6-way replication

⚠️ Pitfall: A NAT Gateway is an AZ-level resource. If the NAT GW in AZ-a dies, the private subnets in AZ-a lose internet access. If you create a NAT GW in only 1 AZ in the name of saving cost, it becomes the single point of failure operators meet most often. One NAT GW per AZ is the standard, and that way, when one AZ fails, the private subnets in the other AZs stay healthy. For the same reason, in the era of NAT Instances (EC2-based NAT) you had to build self-healing yourself with an ASG. The NAT GW is a managed service where AWS does that for you. Another trap: if you do not create a VPC Endpoint, even S3 and DynamoDB traffic goes through the NAT GW and incurs a $0.045/GB data processing charge. A Gateway Endpoint (S3/DynamoDB) is free, so turning it on is the standard.

Traffic between AZs is automatically encrypted on the AWS backbone (since 2022, all new EC2 instance types are Nitro-based, so they use hardware-accelerated AEAD encryption). The same applies within the same AZ. Therefore, even if the operator does not apply TLS at the application level, plaintext does not flow on the wire. However, compliance audits (PCI-DSS, HIPAA) often require application-layer encryption separately, so applying both is the standard.

The AZ isolation design is an implementation of the distributed-systems principle called failure domain isolation. The same concept appears in Google's "Borg" paper (Verma et al., 2015 EuroSys) and Microsoft's "Service Fabric" white paper. The key is to "clearly define the smallest unit across which failures propagate, and design replication and failover on top of it." AWS's AZ is the result of raising that smallest unit to the physical data center level. From the viewpoint of the CAP theorem (Brewer 2000, Gilbert & Lynch 2002), Multi-AZ within the same Region is a trade-off that chooses CP (Consistency + Partition tolerance), and Cross-Region asynchronous replication chooses AP. From the viewpoint of PACELC (Abadi 2012), AWS's Multi-AZ is closer to a system that "gives up some consistency for latency when there is no Partition (PA/EL)."

The Tokyo Region AZ outage of August 23, 2019. In one AZ of ap-northeast-1, a bug in the cooling system control software overheated some servers, and EC2 and EBS were affected. At that time, workloads that had been spread multi-AZ with an ASG survived, and everything tied to a single AZ went down. Companies that ran RDS Single-AZ had the DB die along with it and took hours to recover. After this incident, AWS began announcing "AZ-level maintenance events" more actively through PHD.

ZoneId vs ZoneName: A Trap Only Operators Know

When you call describe-availability-zones, two identifiers come out.

aws ec2 describe-availability-zones --region ap-northeast-2 \
  --query 'AvailabilityZones[*].[ZoneName,ZoneId]' --output table

+-------------------+-----------+
| ap-northeast-2a   | apne2-az1 |
| ap-northeast-2b   | apne2-az2 |
| ap-northeast-2c   | apne2-az3 |
| ap-northeast-2d   | apne2-az4 |
+-------------------+-----------+

ZoneName is shuffled per account. That is, ap-northeast-2a in our account and ap-northeast-2a in a partner's account can be different physical AZs. On the other hand, ZoneId (apne2-az1) is the same in every account. Why shuffle? To keep all traffic from piling into zone a alone when AWS tells every account "create in zone a first." It is a clever trick that forces traffic distribution.

Why does this matter to an operator? When connecting with another account via VPC Peering or PrivateLink, if you want to "place them in the same AZ to save cross-AZ cost and latency," you must match by ZoneId. If you match by ZoneName only, they actually attach to different physical AZs, latency grows by 1 ms, and data transfer cost is incurred. In SOA-C02 scenario questions, a question such as "how do you reduce cross-AZ cost between two accounts?" tests this ZoneId matching.

Edge and Special Infrastructure: 4 Things Operators Should Know

In the operator exam, edge infrastructure usually appears in the form "how do you reduce latency in this scenario?" or "where should you apply the WAF rules?"

During the COVID traffic surge of 2020, thanks to the Open Connect Appliances (OCAs) installed directly inside ISP networks, Netflix's traffic barely rode the ISP backbone. AWS has a similar concept: CloudFront edges peer directly with ISP networks (in Seoul, directly connected to KT, LG U+, and SKB alike). That is why simply turning on CloudFront makes user ↔ origin traffic bypass the ISP backbone. At the same time, origin shield (GA in 2020) funnels all edge cache misses into a single Regional Edge Cache, reducing origin load another step.

CloudFront Functions and Lambda@Edge both run at the edge but in different locations. CloudFront Functions run directly at the 600+ edge PoPs and respond with a cold start under 100 μs, but have the constraints of 2 MB memory, 1 ms execution time, and JavaScript ES5 only. Lambda@Edge runs at the 13 Regional Edge Caches and can use the full Node.js and Python runtimes, but has cold starts on the order of tens of ms. In SOA-C02, answering "URL rewrite, header manipulation?" → CloudFront Functions and "image resize, token verification?" → Lambda@Edge is almost always right.

The Shared Responsibility Model: Redrawn from the Operator's Viewpoint

AWS = Security OF the Cloud / Customer = Security IN the Cloud. Everyone memorizes this one line, but when you list what an operator actually has to do every day in "my area of responsibility," your feel for solving exam scenarios changes.

What an operator actually has to do daily, weekly, and quarterly:

The Capital One incident of July 2019. Card application data of 106 million people was leaked. The cause was not the AWS infrastructure but an SSRF vulnerability in the customer's WAF + exposure of IAM credentials via EC2 metadata v1 (IMDSv1) + an overly broad IAM role permission. The attacker (Paige Thompson, a former AWS employee) accessed http://169.254.169.254/latest/meta-data/iam/security-credentials/ through SSRF, stole temporary credentials, and used that authority to pull data out of S3 buckets. The key point is that there was no problem in AWS's area of responsibility, but the incident occurred in the customer's area of responsibility (WAF configuration, IAM permission scope, use of IMDSv1). DOJ indictment. Right after this incident (November 2019), AWS released IMDSv2 (session-token based), and enforcing HttpTokens=required starting with new EC2 instances became the standard for operators. Afterward, Capital One was fined 80 million dollars in civil penalties by the US Office of the Comptroller of the Currency (OCC) in 2020, and in 2022 agreed to pay a separate 190 million dollars in a class-action settlement.

IMDSv2 is enforced with the SSM Document AWS-EnforceEC2InstanceMetadataServiceV2 or MetadataOptions.HttpTokens=required in a Launch Template. More strongly, use an SCP to enforce the aws:RequestTag/MetadataV2=required condition on RunInstances, or detect non-compliant instances with the Config rule ec2-imdsv2-check. And if you also set hop limit 1, metadata traffic cannot leave outside the container (it cannot cross the docker0 interface of Docker's default bridge network). It is a three-layer defense pattern that prevents an operator from accidentally launching an instance with IMDSv1.

⚠️ Pitfall: The trap of "it is a managed service, so AWS is responsible for security too." Even if you use Lambda or RDS, data classification, IAM permissions, encryption key policies, network access control, and backup policies are always the customer's responsibility. AWS patches the OS and DB engine of RDS, but deciding the Maintenance Window in which to apply that patch, planning how to handle traffic during that time, and confirming that the client connection pool reconnects even when failing over to the Standby are the operator's job. Also, the default retention of RDS Snapshots is 1 to 35 days, so keeping them longer requires exporting them separately, which is often overlooked.

The shared responsibility model fits exactly with the cloud service model (IaaS / PaaS / SaaS) classification of NIST SP 800-145. Of the 5 functions of the NIST CSF (Cybersecurity Framework) (Identify, Protect, Detect, Respond, Recover), Identify and Protect almost entirely remain in the customer's domain. ISO 27017 (cloud security) and ISO 27018 (cloud privacy) also codify areas of responsibility on top of this model. In Korea, KISA's "Cloud Security Guide" (2023 revised edition) follows the same split, and this responsibility split table must be submitted during K-ISMS-P certification review.

The Operator's First Tool: AWS Health Dashboard

How do you find out fastest whether us-east-1 is down? A Twitter search? Downdetector? A colleague's Slack? All are fast but low in reliability. The operator's standard answer is the AWS Health Dashboard and the AWS Health API.

Health is divided into two layers.

• Service Health Dashboard (health.aws.amazon.com/health/status): Region and service-level announcements shown identically to all users. Usually a 1-30 minute delay. It is updated when AWS judges that "customers are affected"
• Personal Health Dashboard (PHD) / AWS Health API: filters only events that affect your account's resources. Scheduled EC2 instance restarts, EBS volume status problems, RDS maintenance notices, and Certificate Manager expirations appear here. It generally appears earlier than the SHD

Operators receive PHD events through EventBridge and connect them to automation.

# Query ongoing events with the Health API
aws health describe-events \
  --filter "eventStatusCodes=open,upcoming" \
  --region us-east-1
 
# Organization-wide events (from the management account)
aws health describe-events-for-organization \
  --filter "eventStatusCodes=open"

The AWS Health API is hosted in only two places, us-east-1 and us-west-2, and fails over automatically. If us-east-1 dies, the SDK automatically retries against the us-west-2 endpoint (built into the SDK since 2023). To receive Health events in EventBridge, you must create an aws.health source rule in both us-east-1 and us-west-2 to receive them without omission. To see things at the Organization level, you must turn on AWS Health Organizational View, and this requires the management account's service-linked role (AWSServiceRoleForHealth_Organizations). Sending Health events to ServiceNow or PagerDuty also follows the standard EventBridge → SNS → external webhook pattern.

Operator Scenario Patterns on the Exam

SOA-C02 is less about abstract concepts and more the pattern of situation → which tool and how to respond? So we will repeat the same line of thinking throughout this book.

[Symptom]                       [1st check]            [2nd check]
─────────────────────────────────────────────────────────────────
EC2 not responding           → CloudWatch metric  → EC2 status check
RDS write failures           → RDS events         → CloudWatch RDS logs
S3 403                       → CloudTrail        → Bucket Policy / IAM
Lambda timeout               → CloudWatch Logs   → X-Ray
Cost spike                   → Cost Explorer     → CloudTrail (writes)
Failure after deployment     → Deploy history    → Config Timeline
Suspected security incident  → GuardDuty         → CloudTrail Lake
Scale-out not occurring      → ASG activity      → Scaling policy + metric

This table is the basic skeleton of the operator's line of thinking. From Week 2 onward, as we dig deep into each service, this pattern gains flesh. When a question asks "which tool should you look at first?", this table is the answer.

Summary

There are two pictures we saw today. First, AWS infrastructure is built on a 3-layer isolation of Region > AZ > Edge, and an operator decides every day which resource to place in which layer. Second, security and operations responsibility is divided by a clear boundary: AWS is responsible from the hardware up to the hypervisor, and everything above that belongs to the customer, and the operator's daily life happens in that "above" area. As the Capital One incident shows, even when AWS is doing its job well, if we misconfigure the WAF, IAM, and IMDSv1, the data of 106 million people leaks, and that is the reality of cloud operations.

Tomorrow we get into IAM, the part of that upper area that breaks most often and causes incidents most often. Just as the Capital One incident began with a WAF misconfiguration (SSRF) and grew into a major leak because of IMDSv1 and an overly broad IAM permission scope, this is the number one place where incidents happen while operators are not looking.