Global Infrastructure + IAM Practical + CloudFront & CDN

Part of my AWS learning journey — transitioning from Systems Engineer to Cloud/DevOps. This session goes deep into how AWS is physically organized around the world and how CloudFront delivers content at low latency to users anywhere.

---

📋 Topics Covered

---

Key Terms — Quick Reference

---

AWS Regions

An AWS Region is a physical geographic location in the world where AWS has built clusters of data centers. Think of it as a city where AWS has its infrastructure — fully self-contained, with its own power, networking, and services.

Global numbers:

• 33+ Regions launched globally
• 100+ Availability Zones worldwide
• 400+ Edge Locations and Points of Presence
• Serves 245+ countries and territories

Important Region codes to know:

🇮🇳 For Indian DevOps work: Always use ap-south-1 (Mumbai) — lowest latency for Indian users, and data stays in India for compliance.

Region Isolation

Every Region is fully independent. A failure, power outage, or natural disaster in one Region has zero impact on any other Region. More importantly — data never moves between Regions unless you explicitly make it happen. AWS does not automatically replicate your data across Regions.

Region A (Mumbai) and Region B (Singapore) are completely isolated. Your data in Mumbai stays in Mumbai unless you set up Cross-Region Replication yourself. This is both a safety feature (your data doesn't accidentally leave a country) and your responsibility (you must plan DR across Regions if you need it).

Default vs Opt-In Regions

Special Restricted Regions

China Regions (cn-north-1 Beijing, cn-northwest-1 Ningxia)

• Require a completely separate AWS China account
• Standard AWS accounts have no access — operated by local Chinese partners
• Different service availability, different pricing structure

GovCloud (US)

• Isolated Regions for US government agencies
• For workloads under FedRAMP, ITAR, CJIS, and other US federal regulations
• Not accessible to regular commercial accounts

🎯 Interview tip: "Can you access the China Region with a regular AWS account?" → No. You need a separate AWS China account. This is a common gotcha question.

---

Availability Zones (AZs)

An Availability Zone is one or more discrete data centers within a Region — each with its own independent power supply, cooling systems, physical security, and networking.

Think of AZs as separate buildings in the same city. Close enough to communicate near-instantly over fiber. Far enough apart that a flood, fire, or power failure in one building doesn't affect the others.

Key facts:

• Each Region has a minimum of 2 AZs, typically 3 (some Regions have 6)
• AZs within a Region are physically separated by meaningful distance — typically many kilometers apart
• Connected via high-speed, low-latency fiber-optic links that enable near-synchronous replication
• Designed to survive: lightning, tornadoes, earthquakes, flooding — each AZ independently

AZ structure inside Mumbai Region:

Region: ap-south-1 (Mumbai)

AZ: ap-south-1a → contains multiple data centers

AZ: ap-south-1b → contains multiple data centers

AZ: ap-south-1c → contains multiple data centers

All three AZs connected via high-bandwidth, low-latency fiber-optic links

Why AZs Matter for DevOps

Single AZ deployment: App Server in AZ-a only. If AZ-a has an outage → app goes down → users affected. No automatic recovery.

Multi-AZ deployment: App Server in AZ-a + AZ-b, behind a Load Balancer. If AZ-a fails → traffic automatically routes to AZ-b → app stays up → users notice nothing.

This is High Availability (HA) — one of the most fundamental concepts in Cloud/DevOps/SRE roles. AWS recommends always deploying across at least 2 AZs in production.

---

Data Centers — AWS Physical Design Principles

Data centers are the actual physical buildings containing the servers, storage, and networking equipment that power everything on AWS.

---

Edge Locations & Regional Edge Caches

Edge Locations (Points of Presence)

Edge Locations are cache servers placed in major cities worldwide — much closer to end users than any AWS Region. They don't run EC2, S3, or databases — they exist purely for low-latency content delivery.

Used by: Amazon CloudFront (CDN) and Amazon Route 53 (DNS)

AWS has 400+ Edge Locations across 245+ cities worldwide — far more than the 33+ Regions. A city doesn't need a full AWS Region to have an Edge Location.

Regional Edge Caches

A middle layer between your origin and edge locations:

Origin Server (Mumbai Region) — infrequently contacted

↓

Regional Edge Cache (e.g., Singapore) — larger cache, holds less-popular content regionally

↓

Edge Location (Mumbai city, Bangalore, Chennai, Hyderabad) — serves end users directly

Regional Edge Caches store content that's popular at a regional level but not popular enough to be in every city's edge location. They significantly reduce the number of times the origin server needs to be contacted.

---

Latency & Fault Tolerance

Latency

Latency is the time (in milliseconds) for data to travel from source to destination. It is a physical constraint — data moves at the speed of light through fiber, and distance matters.

Mumbai → Mumbai Edge Location: ~5–20ms (CDN cache hit, same city)
Mumbai → Mumbai Region: ~20–50ms (same country, no CDN)
Mumbai → Singapore Region: ~60–100ms (neighboring country)
Mumbai → N. Virginia Region: ~180–220ms (other side of the planet)

How AWS reduces latency for your users:

• Choose the Region closest to your users
• Use CloudFront Edge Locations to cache static content in the user's city
• Use Route 53 latency-based routing to send users to the fastest available endpoint

🛠 Practical tool: Use cloudping.info to measure your actual latency to each AWS Region from your location. Use real data to choose your Region — don't guess.

Fault Tolerance

Fault Tolerance is the ability of a system to continue operating correctly even when one or more components fail.

How AWS achieves it:

Multi-AZ deployment → if one AZ fails, others keep serving → zero downtime (High Availability)

Multi-Region deployment → if an entire Region fails, another Region takes over → geographic redundancy

Elastic Load Balancing → detects unhealthy instances and stops routing traffic to them → automatic

Auto Scaling Groups → replaces failed instances automatically → self-healing infrastructure

The distinction between HA and Fault Tolerance:

---

Region Selection Strategy — 4 Factors

Choosing the wrong Region causes compliance violations, high costs, and slow user experience. Always evaluate these four factors, in this order:

Factor 1 — Data Governance & Legal Requirements (Check This First)

Some industries and countries legally mandate where data must be stored. Getting this wrong means regulatory penalties that no amount of performance optimization can offset.

EU citizens' data under GDPR must stay in EU Regions (Frankfurt eu-central-1, Ireland eu-west-1).

Indian financial data under RBI regulations may need to remain in India (ap-south-1).

Healthcare data under HIPAA has specific requirements.

Always validate regulatory requirements with your legal or compliance team before choosing a Region. This isn't a technical decision — it's a legal one.

Factor 2 — Proximity to End Users (Latency)

Deploy in the Region closest to where your users are. Use cloudping.info to measure actual latency — don't rely on map distance.

90% Indian users → ap-south-1 (Mumbai). Done.
Global audience with heaviest traffic from USA → us-east-1 as primary, CloudFront for global distribution.

Factor 3 — Service & Feature Availability

Not every AWS service exists in every Region. New services always launch in us-east-1 first, then expand to other Regions over months.

Before choosing a Region, verify every service your application needs is available there.
Check: aws.amazon.com/about-aws/global-infrastructure/regional-product-services

Factor 4 — Pricing

The same EC2 instance type costs differently per Region. US East is typically cheapest. Tokyo is typically among the most expensive. Data transfer costs between Regions add up significantly for high-traffic applications.

Decision flow:

Is there a legal/compliance requirement? → YES: that Region is mandatory, no choice.

Where are most of your users? → Choose the nearest Region for low latency.

Are all required services available there? → YES: continue. NO: find a Region where they are.

Compare pricing between shortlisted Regions → choose the most cost-effective.

---

Benefits of AWS Global Infrastructure

Three pillars that make AWS global infrastructure fundamentally different from building your own:

Elastic and Scalable
Resources adjust dynamically to demand. Scale up for Black Friday traffic, scale back down in January. No hardware to buy for peak capacity — you pay only when you need it.

Fault Tolerant
Built-in redundancy across AZs and Regions. Critical components backed up automatically. Traffic reroutes away from failures without human intervention. Your app self-heals.

Highly Available
Designed for continuous uptime. Multiple AZs provide redundant paths and instant failover. Maintenance happens without downtime. Managed services have SLAs up to 99.99%.

---

CloudFront & CDN

What is a CDN?

A CDN (Content Delivery Network) is a global network of servers that caches copies of your content and serves them from locations physically close to your users — instead of making every user reach your origin server.

Without CDN: every user, regardless of location, fetches content from your origin server. A London user hitting a Mumbai origin waits 200–300ms. Every. Single. Request.

With CDN: the London user's first request goes to the nearest Edge Location (London). CloudFront fetches from Mumbai origin and caches it at the London edge. Every London user after that gets it from the London cache in 20–30ms.

What is AWS CloudFront?

CloudFront is AWS's managed CDN service. It sits in front of your origin (S3 bucket, EC2 server, ALB) and:

• Caches your content at 400+ Edge Locations worldwide
• Serves users from the nearest edge location automatically
• Enforces HTTPS by default
• Provides DDoS protection via AWS Shield integration
• Filters malicious traffic via AWS WAF integration

Request Flow Comparison

Without CloudFront:

User (Mumbai) → Internet → Origin Server (N. Virginia) → 500ms–2000ms latency on every request. No caching. Every user hits the origin every time.

With CloudFront:

First request: User (Mumbai) → Edge Location (Mumbai PoP) → "Not cached" → fetches from Origin → caches at edge → returns to user.

All subsequent requests: User (Mumbai) → Edge Location (Mumbai PoP) → "Found in cache!" → instantly served → 20–100ms.

Cache Hit vs Cache Miss

Cache Miss (first request):

User → Edge → not cached → Edge fetches from Origin → stores at edge → sends to user. Slower, but only happens once (or until TTL expires).

Cache Hit (all subsequent requests):

User → Edge → found in cache → instantly served to user. Origin server never contacted. Faster and cheaper — you're not paying for origin compute or data transfer.

Response headers that tell you which happened:

CloudFront vs Normal S3 Access

OAC — Origin Access Control

OAC restricts your S3 bucket so that only CloudFront can access it. Direct S3 URL access is blocked — users must go through CloudFront.

Without OAC: users can access s3.amazonaws.com/your-bucket/file.jpg directly, bypassing CloudFront security and caching.

With OAC: direct S3 access returns 403 Forbidden. Users must go through d1xxxx.cloudfront.net which has HTTPS, WAF, and caching enforced.

---

IAM Practical Recap & Best Practices

In this session, IAM setup from Session 1 was completed practically. The full secure account setup:

Root account → MFA enabled, locked away for emergencies only

IAM Group (AdminGroup) → AdministratorAccess policy attached

IAM User (your daily user) → added to AdminGroup → inherits permissions

IAM User → MFA enabled → credentials CSV downloaded and stored securely

The IAM hierarchy done right:

Root Account (locked) → IAM Admin Group (policy attached) → IAM Users (members of group)

Why groups over direct policy attachment: When you add a new team member, you add them to the group — they inherit all the right permissions instantly. When someone leaves, remove them from the group. No policy juggling per user.

Precautions after every lab session:

• Log out of Root immediately after account-level tasks
• Never leave Root signed in on a shared computer
• Check Billing → Free Tier usage after labs to catch unexpected charges

---

Cost Prevention Checklist

Accidental charges are the #1 beginner trap. Build this habit immediately.

Set up billing alerts (do this now, before anything else):

AWS Console → Billing → Budgets → Create Budget → set monthly limit ($5 or $10) → alert at 80% and 100% threshold → confirm email address

After every lab session:

• EC2 instances → STOP when done for the day (TERMINATE only when fully done)
• CloudFront distributions → Disable after labs, delete when done
• S3 buckets → Delete test files, delete empty buckets
• RDS instances → STOP or DELETE — RDS charges even when idle
• Elastic IPs → Release when not attached to a running instance (charged idle)
• NAT Gateways → Delete when not needed — hourly charge

Weekly habit: AWS Console → Billing → Check current month's charges. Any unexpected charge → investigate immediately before it compounds.

---

💼 Interview Questions

Q1: What is the difference between a Region, an Availability Zone, and an Edge Location?
A Region is a geographic cluster of AWS infrastructure — fully isolated, 33+ worldwide. An AZ is one or more isolated data centers within a Region, each with independent power and networking — minimum 2 per Region. An Edge Location is a CDN cache server placed in major cities, used by CloudFront and Route 53 for low-latency delivery — not for compute or storage.

Q2: What are the four factors for choosing an AWS Region?

1. Legal/Compliance requirements — always check first, non-negotiable. 2. Proximity to end users — choose the nearest Region for lowest latency. 3. Service availability — verify your required services exist in that Region. 4. Pricing — varies per Region, compare after the first three are resolved.

Q3: What is the difference between High Availability and Fault Tolerance?
High Availability minimizes downtime with quick recovery — a Multi-AZ deployment where failover takes ~1 minute. Fault Tolerance means zero interruption even during component failure — like a Multi-Region Active-Active deployment where users notice nothing. HA is more common and cost-effective; Fault Tolerance requires significantly more infrastructure investment.

Q4: What is CloudFront and what problem does it solve?
CloudFront is AWS's CDN service. It solves the problem of high latency for users far from your origin server — by caching content at 400+ edge locations worldwide and serving users from the nearest one. A London user hitting a Mumbai origin at 250ms can instead get content from the London edge at 20ms after the first cache.

Q5: What is the difference between a Cache Hit and a Cache Miss in CloudFront?
A Cache Hit means the content was found at the edge location and served instantly without contacting the origin. A Cache Miss means the content wasn't cached yet — CloudFront fetched it from the origin, cached it at the edge, and returned it to the user. All subsequent requests for the same content are Cache Hits until the TTL expires.

Q7: Can you access the China AWS Region with a regular AWS account?
No. China Regions (cn-north-1, cn-northwest-1) require a completely separate AWS China account operated by local Chinese partners. Standard AWS accounts have no access to China Regions at all.

Q8: A company's web app has users in India, EU, and USA. The origin is in Mumbai. How do you design for optimal performance globally?
Use CloudFront with the Mumbai origin. CloudFront automatically serves EU and US users from their nearest edge locations, reducing their latency from 200–300ms to 20–50ms. Enable OAC to restrict direct S3 access. Enable AWS WAF and Shield on the CloudFront distribution for security. For dynamic content that can't be cached, consider a Multi-Region Active-Active architecture with Route 53 latency-based routing.

---

🔬 Practice Tasks

1. Sign into AWS Console and navigate to the Region selector (top-right). Switch between Mumbai (ap-south-1) and N. Virginia (us-east-1) and observe how the service lists change. Note which services are available in both.

---

AWS Session 2 — Global Infrastructure & CloudFront | Cloud + DevOps learning journey — Systems Engineer → Cloud/DevOps Engineer