Global Infrastructure + IAM Practical + CloudFront & CDN

📌 Session Overview

🔑 ESSENTIAL AWS TECHNICAL TERMS (Quick Reference)

Before diving in — here are the key terms you'll hear constantly in any AWS/DevOps role:

🌍 SECTION 1 — AWS Regions

What is a Region?

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.

Key facts:

• 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 users in India + data stays in India for compliance.

Region Isolation — How It Works

Region A (Mumbai)          Region B (Singapore)
┌──────────────────┐       ┌──────────────────┐
│   Your App Data  │       │   (Empty)         │
│   AZ-a, AZ-b    │  ✗ NOT automatically │  AZ-a, AZ-b  │
│                  │ ─────replicated──▶ │                  │
└──────────────────┘       └──────────────────┘

Critical rules:

• A failure in one Region does NOT impact other Regions
• Data stays in a Region unless you explicitly move it
• YOU are responsible for cross-Region replication if needed

Default vs Opt-In Regions

Special Restricted Regions

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

• Require a separate AWS China account entirely
• Standard AWS accounts cannot access these

GovCloud (US)

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

💡 Interview Tip: If asked "Can I access the China region with my regular AWS account?" — Answer is NO. You need a separate AWS China account operated by local partners.

🏢 SECTION 2 — Availability Zones (AZs)

What is an AZ?

An Availability Zone is one or more discrete data centers within a Region — each with its own independent:

• Power supply
• Cooling systems
• Physical security
• Networking

Think of AZs as separate buildings in the same city — close enough to communicate instantly, but isolated enough that a fire in one doesn't affect another.

AZ Structure Inside a Region

Region: ap-south-1 (Mumbai)
│
├── AZ: ap-south-1a
│     ├── Data Center 1 (thousands of servers)
│     ├── Data Center 2
│     └── Data Center 3
│
├── AZ: ap-south-1b
│     ├── Data Center 1
│     ├── Data Center 2
│     └── Data Center 3
│
└── AZ: ap-south-1c
      ├── Data Center 1
      ├── Data Center 2
      └── Data Center 3

All AZs ←──── High-bandwidth, low-latency fiber-optic links ────→ All AZs

Key AZ Facts

• Each AZ is physically separated by many kilometers (but within 100 km of each other in the Region)
• Connected via high-speed fiber-optic links for near-synchronous replication
• Designed to survive: lightning, tornadoes, earthquakes, flooding
• AWS recommends: always deploy across at least 2 AZs

Why Does This Matter for DevOps?

❌ Single AZ Deployment:
   App Server → AZ-a only
   If AZ-a fails → App goes down → Users affected ❌

✅ Multi-AZ Deployment:
   App Server → AZ-a + AZ-b (Load Balanced)
   If AZ-a fails → Traffic automatically routes to AZ-b → App stays up ✅

This is High Availability (HA) — one of the most important concepts in Cloud/DevOps/SRE roles.

🏭 SECTION 3 — Data Centers (The Physical Foundation)

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

AWS Data Center Design Principles

💡 AWS never publicly discloses the exact location of its data centers — this is a security measure.

📡 SECTION 4 — Edge Locations & Points of Presence (PoPs)

The Problem Without Edge Locations

Imagine your server is in Mumbai (ap-south-1) but a user in London wants to download a 50MB video from your website.

User (London) ──── long internet journey ──── Server (Mumbai)
                      ~200-300ms latency

Every time they want that video, it travels halfway around the world. Slow and expensive.

The Solution — Edge Locations / PoPs

AWS has 400+ Edge Locations scattered across major cities worldwide. These act as cache servers — storing copies of popular content close to users.

User (London) ──── Edge Location (London) ──── Server (Mumbai)
                      ~10-30ms latency           (Only first request)

After the first request, the video is cached at the London edge location. Every subsequent user in London gets it from the edge — fast!

Edge Locations vs Regions vs AZs

Regional Edge Caches

A middle layer between origin and edge locations:

Origin Server (Mumbai) 
      ↕ (infrequent)
Regional Edge Cache (e.g., Singapore)
      ↕ (occasional)
Edge Location (Mumbai city, Bangalore, Chennai)
      ↕ (constant, fast)
End Users

• Larger cache than individual edge locations
• Stores content that's popular regionally but not hot enough for every edge location
• Reduces load on origin servers significantly

Services That Use Edge Locations

• Amazon CloudFront — CDN (content delivery)
• Amazon Route 53 — DNS resolution
• AWS Shield — DDoS protection
• AWS WAF — Web application firewall

⚡ SECTION 5 — Latency & Fault Tolerance

Latency

Definition: The time (in milliseconds) for data to travel from source to destination.

Low Latency  = Fast response = Happy users
High Latency = Slow response = Users leave your site

How AWS reduces latency:

• Choose the Region closest to your users
• Use Edge Locations for static content (CloudFront)
• Use CloudPing (cloudping.info) to measure real latency to each Region before deciding

Latency comparison (rough):

Mumbai → Mumbai Edge Location:    ~5-20ms   (CDN cache hit)
Mumbai → Mumbai Region:           ~20-50ms  (same country)
Mumbai → Singapore Region:        ~60-100ms (nearby)
Mumbai → N. Virginia Region:      ~180-220ms (far)

Fault Tolerance

Definition: The ability of a system to keep running correctly even when one or more components fail.

Think of a car with a spare tyre — if one tyre punctures, you can still drive. Fault tolerance is the spare tyre for your infrastructure.

How AWS Achieves Fault Tolerance

Multi-AZ Deployment:

• Deploy across 2+ AZs in one Region
• If AZ-a fails → AZ-b keeps serving traffic
• Synchronous replication via dedicated fiber links

Multi-Region Deployment:

• Run services across 2+ Regions
• Protects against entire regional disasters
• Also reduces global latency by serving from nearest Region

Elastic Load Balancing (ELB):

• Distributes incoming traffic across healthy instances
• Instantly reroutes away from failed nodes/AZs
• No manual intervention needed

Automated Failover:

• AWS detects failure automatically
• Traffic moves to healthy infrastructure instantly
• Minimal or zero downtime

🗺️ SECTION 6 — Region Selection Strategy (4 Factors)

Choosing the wrong Region can cause compliance violations, high costs, and slow performance. Always evaluate all 4 factors:

Factor 1 — Data Governance & Legal Requirements (MOST IMPORTANT)

Check this FIRST before anything else.

• Some countries/industries legally require data to stay within borders
• EU's GDPR restricts where EU citizen data can be stored
• Indian financial data regulations may require data in India

Example: A company serving EU customers must store their data in an EU Region (like Frankfurt eu-central-1 or Ireland eu-west-1) — NOT in US East.

Action: Always validate regulatory requirements with your legal/compliance team before choosing a Region.

Factor 2 — Proximity to End Users (Latency)

• Deploy in the Region closest to your users
• Use cloudping.info to measure actual latency from your location to each Region

Example: Your app has 90% Indian users → ap-south-1 (Mumbai) is the right choice.

Factor 3 — Service & Feature Availability

• Not every AWS service exists in every Region
• New services typically launch in us-east-1 first, then expand
• Always verify the services you need are available in your chosen Region

Example: Bedrock (AWS's AI service) launched in limited Regions first. If you needed it, you had to use those specific Regions.

Check: AWS Regional Services List

Factor 4 — Pricing Variation

The same service costs differently per Region. AWS pricing example:

Also consider: Data transfer costs between Regions can add up significantly for high-traffic applications.

Region Selection Decision Flow

1. Is there a legal/compliance requirement for data location?
   YES → That Region is mandatory, no choice
   NO  → Continue ↓

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

3. Do your required AWS services exist in that Region?
   YES → Continue ↓
   NO  → Pick alternative Region where services exist

4. Compare pricing between shortlisted Regions
   → Pick the most cost-effective option

✅ SECTION 7 — Benefits of AWS Global Infrastructure

The 3 pillars that make AWS infrastructure fundamentally different from on-premise:

1. Elastic and Scalable

• Resources adjust dynamically to demand
• Scale up for Black Friday, scale back down in January
• No need to buy hardware for peak capacity

2. Fault Tolerant

• Built-in redundancy across AZs and Regions
• Critical components backed up automatically
• Traffic reroutes away from failures without human intervention

3. Highly Available

• Designed for continuous uptime
• Minimal to zero human intervention for maintenance
• Multiple AZs provide redundant paths and instant failover

Traditional On-Premise:
  Single server → Server fails → Everything down → Engineers scramble → Hours of downtime

AWS Multi-AZ:
  AZ-a fails → AZ-b auto-serves → Users notice nothing → 0 downtime

🌐 SECTION 8 — CloudFront & CDN (Practical Demo)

What is a CDN?

CDN = Content Delivery Network

A global network of servers that store cached copies of your content and serve them from locations close to your users.

Without CDN: Every user fetches from your origin server (slow if far away)

With CDN: Users fetch from the nearest cache server (fast, always)

What is AWS CloudFront?

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

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

Request Flow Comparison

Without CloudFront:

User (Mumbai) ──── Internet ──── Origin Server (US East)
                                    ↑
                          500ms - 2000ms latency
                          Every request hits this server
                          No caching, no protection

With CloudFront:

User (Mumbai) ──── Edge Location (Mumbai PoP) ──── Origin (US East)
                         ↑                              ↑
                   CACHE HIT: 20-100ms           Only first request
                   Subsequent: served from edge   Cache TTL controls refresh

Cache Hit vs Cache Miss

First Request (Cache MISS):
  User → Edge → "Not cached here" → Origin → Content fetched → Stored at Edge → Sent to User

All Subsequent Requests (Cache HIT):
  User → Edge → "Found in cache!" → Instantly served to User
  (Origin server never contacted — saves cost and reduces load)

Response headers tell you which happened:

CloudFront Lab Setup (Step-by-Step)

Step 1: Create S3 Bucket as Origin

AWS Console → S3 → Create Bucket
Name: cloudfront-demo-lab-2026
Region: us-east-1 (N. Virginia)
Uncheck "Block all public access" → Acknowledge
Upload: index.html (or any image)
Set object permissions: Make Public via ACL
Properties tab → Enable Static Website Hosting

Step 2: Test Direct S3 Access (Baseline)

URL: http://bucket.s3-website-us-east-1.amazonaws.com/index.html
Open DevTools → Network tab → Reload
Note: Response time ~500ms-2000ms (from India)
Note: No x-cache header (no CloudFront)
Note: HTTP only, no HTTPS

Step 3: Create CloudFront Distribution

AWS Console → CloudFront → Create Distribution

Setting                  Value
─────────────────────────────────────────────
Origin Domain            [your S3 bucket]
Origin Access            OAC (Origin Access Control)
Viewer Protocol          Redirect HTTP → HTTPS
Allowed Methods          GET, HEAD
Cache Policy             CachingOptimized (AWS Managed)
Price Class              All Edge Locations
Default Root Object      index.html
WAF                      Enable (optional)

⏱ Wait 5-15 minutes for global deployment

Step 4: Test CloudFront Access

URL: https://d1xxxx.cloudfront.net/index.html
First request → x-cache: Miss from cloudfront (fetches from origin)
Reload → x-cache: Hit from cloudfront (served from edge!)
Response time → 20-100ms (vs 500-2000ms without CDN)

Step 5: Restrict Direct S3 Access (OAC)

OAC = Origin Access Control
Forces all requests through CloudFront only
Direct S3 URL becomes blocked → users must use CloudFront URL
This adds security + ensures all requests get CDN benefits

Normal S3 vs CloudFront Comparison

💡 DevOps Use Case: When deploying a static website, React app, or serving images/videos at scale — always put CloudFront in front of your S3. It's almost always cheaper and significantly faster for global users.

👤 SECTION 9 — IAM Practical Recap

What Was Done in This Session

During this session, the IAM setup from Class 1 was completed practically. Here's the complete picture of what a secure IAM setup looks like:

The IAM Hierarchy

AWS Root Account (your email)
│   ├── ⚠️ LOCK THIS DOWN — MFA enabled, used ONLY for billing/account emergencies
│
├── IAM Groups
│     ├── AdminGroup → AdministratorAccess policy
│     ├── DevOpsGroup → PowerUserAccess policy
│     └── ReadOnlyGroup → ReadOnlyAccess policy
│
├── IAM Users
│     ├── tejas-admin → member of AdminGroup
│     ├── dev-user → member of DevOpsGroup
│     └── auditor → member of ReadOnlyGroup
│
└── IAM Roles (for services, not humans)
      ├── EC2-S3-Role → EC2 can access S3
      └── Lambda-DynamoDB-Role → Lambda can write to DynamoDB

IAM Policy Types

AdministratorAccess — Full control over everything

{
  "Effect": "Allow",
  "Action": "*",
  "Resource": "*"
}

Use for: Learning, your personal admin user

PowerUserAccess — Everything except IAM management

Use for: Developers who deploy but shouldn't manage access

ReadOnlyAccess — View everything, change nothing

Use for: Auditors, monitoring dashboards

Principle of Least Privilege (Always Apply This)

Give users the minimum permissions needed to do their job — nothing more.

❌ Wrong: Give all developers AdministratorAccess "just in case"

✅ Right: 
   Developer needs to deploy EC2 + S3? → Give only EC2 + S3 permissions
   Developer needs to read logs? → Give CloudWatch ReadOnly only
   Developer needs billing info? → Give Billing ReadOnly only

IAM Best Practices Checklist

✅ Root account MFA enabled
✅ IAM user created for all daily tasks (never use Root)
✅ MFA enabled on IAM user too
✅ Strong password policy set
✅ Access keys rotated regularly (if used)
✅ Never commit access keys to GitHub
✅ Use IAM Roles for EC2/Lambda/services (not access keys)
✅ Audit IAM users periodically — remove unused accounts
✅ Use Groups to manage permissions (not individual user policies)
✅ Download and securely store credentials CSV

💰 SECTION 10 — Cost Prevention Checklist (IMPORTANT!)

Accidental AWS charges are the #1 beginner mistake. Here's how to stay safe:

Set Up Billing Alerts (Do This Now!)

AWS Console → Billing → Budgets → Create Budget
→ Set monthly limit (e.g., $5 or $10)
→ Alert email when 80% of budget reached
→ Alert email when 100% reached

Free Tier Monitoring

AWS Console → Billing → Free Tier
→ See what you've used vs what's free
→ Check regularly — especially EC2 hours and S3 storage

After Every Lab Session — Cleanup Checklist

EC2 Instances:
  ✅ STOP instances when not learning (saves compute cost)
  ✅ TERMINATE when done with lab permanently

S3 Buckets:
  ✅ Delete test files and buckets after labs
  ✅ S3 costs per GB stored — don't leave large files

CloudFront:
  ✅ Disable distribution when not in use
  ✅ Delete after lab complete

RDS / Databases:
  ✅ STOP or DELETE RDS instances after labs
  ✅ RDS costs even when idle

IAM Access Keys:
  ✅ Delete unused access keys
  ✅ Never leave programmatic keys lying around

Billing Check (Weekly Habit):
  ✅ AWS Console → Billing → Check current month's charges
  ✅ Any unexpected charge → investigate immediately

Free Tier Limits (12 months)

🧠 INTERVIEW QUESTIONS

Easy

Q1: What is the difference between a Region, AZ, and Edge Location?

A: A Region is a geographic area (e.g., Mumbai). An AZ is one or more isolated data centers within a Region with independent power and networking. An Edge Location is a cache server in a major city used by CloudFront/Route 53 for low-latency content delivery — not for compute.

Q2: How many AZs does a Region typically have?

A: A minimum of 2, typically 3. For example, Mumbai (ap-south-1) has 3 AZs: a, b, c.

Q3: What is CloudFront and what problem does it solve?

A: CloudFront is AWS's CDN (Content Delivery Network). It solves the problem of high latency for users far from your origin server by caching content at 400+ edge locations worldwide, serving users from the nearest one.

Q4: What is the difference between a Cache Hit and Cache Miss in CloudFront?

A: A Cache Hit means the content was found at the edge location and served instantly without contacting the origin. A Cache Miss means the edge location didn't have the content yet and had to fetch it from the origin server.

Q5: What are the 4 factors for choosing an AWS Region?

A: 1) Data Governance/Legal compliance, 2) Proximity to end users (latency), 3) Service/feature availability in that Region, 4) Pricing variation between Regions.

Intermediate

Q6: What is Fault Tolerance and how does AWS achieve it?

A: Fault Tolerance is the ability to keep operating when components fail. AWS achieves it through Multi-AZ deployments (data replicated across AZs), Elastic Load Balancing (routes traffic away from failed nodes), and Automated Failover (systems detect failure and reroute traffic automatically).

Q7: Why is us-east-1 special compared to other Regions?

A: us-east-1 (N. Virginia) is AWS's oldest and largest Region. New services and features always launch there first before expanding to other Regions. It also has the broadest service availability and some of the lowest prices.

Q8: What is OAC in CloudFront and why is it used?

A: OAC (Origin Access Control) restricts access to your S3 bucket so that only CloudFront can access it — users cannot bypass CloudFront and access the S3 URL directly. This enforces security, ensures all traffic benefits from CDN caching, and prevents direct origin exposure.

DevOps-Focused

Q9: A company's web app has users in India, Europe, and USA. The origin server is in Mumbai. How would you design the architecture for optimal performance?

A: Use CloudFront with the Mumbai S3/EC2 origin. CloudFront's 400+ edge locations would automatically serve European and US users from their nearest edge, dramatically reducing latency. Static assets (images, CSS, JS) would be cached at edges. For dynamic content, consider Multi-Region Active-Active deployment if budget allows. Also enable AWS WAF and Shield on CloudFront for security.

Q10: What is the difference between High Availability and Fault Tolerance?

A: Fault Tolerance means the system continues operating with zero interruption when components fail (like a plane with multiple engines). High Availability means the system has minimal downtime and can recover quickly from failure (like RAID storage — brief interruption but quick recovery). In practice, AWS Multi-AZ gives High Availability, while Multi-Region active-active gives Fault Tolerance.

⚡ QUICK REVISION CARD

AWS GLOBAL NUMBERS
├── 33+ Regions globally
├── 100+ Availability Zones
├── 400+ Edge Locations / PoPs
└── 245+ countries served

REGION SELECTION (4 Factors)
├── 1. Legal/Compliance (check FIRST)
├── 2. Proximity to users (latency)
├── 3. Service availability in Region
└── 4. Pricing (varies by Region)

AZ KEY FACTS
├── Min 2 per Region (usually 3)
├── Independent power + networking
├── Within 100km of each other
└── Connected via low-latency fiber

CLOUDFRONT
├── CDN = cache content near users
├── 400+ edge locations
├── Cache Hit → served from edge (fast, ~20ms)
├── Cache Miss → fetched from origin (slow, first time only)
└── OAC = blocks direct S3 access, forces CloudFront

IAM BEST PRACTICES
├── Root → Lock away, MFA, never for daily use
├── IAM User → All daily tasks
├── Least Privilege → Minimum required permissions
└── Groups → Manage permissions at group level

COST PREVENTION
├── Set billing alerts (do this NOW)
├── Stop EC2 when not in use
├── Delete CloudFront/S3 after labs
├── Check Free Tier usage regularly
└── Never leave RDS running idle

📚 KEY TERMS GLOSSARY (Session 2)

🔬 PRACTICE QUESTIONS

1. A startup in Bangalore is building an app for Indian users. Which Region should they choose and why?
2. Your app is deployed in only one AZ. What is the risk, and how would you fix it?
3. You access a CloudFront URL and see x-cache: Miss from cloudfront. What does this mean? What will you see on the second request?
4. A client says "our hospital patient data cannot leave India." What AWS concept does this relate to, and which Region would you recommend?
5. What is the difference between an Edge Location and an Availability Zone?
6. You check your AWS bill and see unexpected S3 charges. List 3 things you would check first.
7. Why does AWS recommend enabling MFA on both Root AND IAM users?

AWS Regions — More Than Just Geography

An AWS Region isn't just a dot on a map. It's a fully isolated infrastructure cluster — a failure in Mumbai has zero impact on Singapore. And critically: data doesn't move between Regions unless you make it happen.

For India specifically, ap-south-1 (Mumbai) is the obvious choice — lowest latency for Indian users, and data stays within India for compliance.

How to choose a Region? 4 factors:

1. Legal/compliance requirements (check this FIRST — GDPR, RBI, etc.)
2. Proximity to your users (use cloudping.info to measure actual latency)
3. Service availability (not all services exist in every Region)
4. Pricing (same service, different price per Region)

AZs — Your App's Safety Net

Within each Region, AWS has multiple Availability Zones — isolated data centers with independent power and networking. They're close enough to communicate instantly but isolated enough that one failing doesn't affect the others.

Deploying across 2 AZs = High Availability. If AZ-a goes down, AZ-b serves your users with zero interruption. This is one of the most fundamental DevOps architecture decisions.

CloudFront — CDN Finally Makes Sense

Here's what I understood from the demo:

Without CloudFront: Every user, regardless of location, hits your origin server. A user in London accessing your Mumbai server waits 200-300ms. Every. Single. Time.

With CloudFront: Their first request goes to the nearest edge location (say, London). CloudFront fetches from your Mumbai origin and caches it at the London edge. Every user after that in London gets it in 20-30ms.

The response header x-cache: Hit from cloudfront tells you you're getting the cached version. First request = Miss, every request after = Hit. That's CDN in action.

Key Takeaways

• AWS has 33+ Regions, 100+ AZs, and 400+ Edge Locations
• Always evaluate 4 factors before choosing a Region: legal, latency, service availability, pricing
• Multi-AZ = High Availability. Never deploy production in a single AZ
• CloudFront = CDN. It caches content near users, reduces origin load, enforces HTTPS, and adds DDoS protection
• OAC ensures users can only access your content through CloudFront — not directly from S3
• Set billing alerts before anything else — accidental charges are a real beginner trap