Source: Dev.to

📌 Session Overview

Topic

1 AWS Regions — What they are & how isolation works

2 Availability Zones (AZs) — Deep dive

3 Data Centers — The physical foundation

4 Edge Locations & Points of Presence (PoPs)

5 Latency & Fault Tolerance

6 Region Selection Strategy

7 Benefits of AWS Global Infrastructure

8 CloudFront & CDN — Concepts + Demo

9 IAM — Practical Recap & Best Practices

10 Cost Prevention Checklist

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

Term Simple Meaning

Region A geographic location with AWS data centers (e.g., Mumbai)

AZ (Availability Zone) Isolated data center cluster within a Region

Edge Location / PoP Cache server in a city near end users (for CDN)

CDN Content Delivery Network — serves content from nearby servers

Latency Delay in data travel (lower = faster)

Fault Tolerance System keeps running even when parts fail

High Availability (HA) System has minimal downtime, always accessible

Failover Automatically switching to backup when primary fails

Replication Copying data to multiple locations for safety

OAC Origin Access Control — restricts S3 access to CloudFront only

TTL Time To Live — how long cached content stays before refresh

WAF Web Application Firewall — filters malicious traffic

DDoS Distributed Denial of Service attack — floods server with traffic

GDPR EU law requiring data to stay within specific geographic boundaries

Cache Hit Content served from edge (fast) — no origin server call

Cache Miss Content not at edge yet — must fetch from origin (slower)

Data Residency Legal requirement that data must stay within a country/region

CapEx Capital Expenditure — upfront hardware costs (on-prem)

OpEx Operational Expenditure — ongoing usage costs (cloud)

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

Region Code Location

us-east-1 N. Virginia (USA) — Default, most services launch here first

us-west-2 Oregon (USA)

eu-west-1 Ireland

ap-south-1

Mumbai 🇮🇳 — Use this for India

ap-southeast-1 Singapore

me-south-1 Bahrain

🇮🇳 For Indian DevOps work: Always use ap-south-1 (Mumbai) — lowest latency for users in India + data stays in India for compliance. 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

Type Which Regions How to Use

Default-enabled All Regions before March 20, 2019 Ready to use immediately

Opt-in required Hong Kong, Bahrain, newer Regions Must manually enable in Console

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. 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. 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

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 ❌ 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. Data centers are the actual physical buildings containing the servers, storage, and networking equipment that power everything you do on AWS.

Principle What It Means

Site Selection Locations chosen to minimize flood, earthquake, lightning risk

Redundant Design Systems anticipate failure and keep running

Critical Backups Key components backed up across multiple AZs

Capacity Monitoring Continuous monitoring to deploy infrastructure proactively

Location Secrecy Exact addresses never disclosed publicly

Automated Failover Traffic moves away from failed areas instantly — no human needed

Custom Equipment AWS uses custom-built network hardware from multiple manufacturers

💡 AWS never publicly discloses the exact location of its data centers — this is a security measure. 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. 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!

Infrastructure Purpose Examples

Region Full compute, storage, all services Mumbai, N. Virginia

AZ Isolated data centers within Region ap-south-1a, ap-south-1b

Edge Location / PoP CDN caching only, no compute 400+ cities worldwide

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 Amazon CloudFront — CDN (content delivery) Amazon Route 53 — DNS resolution AWS Shield — DDoS protection AWS WAF — Web application firewall 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)

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. 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 Choosing the wrong Region can cause compliance violations, high costs, and slow performance. Always evaluate all 4 factors: 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. 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. 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 The same service costs differently per Region. AWS pricing example:

Region t3.medium Linux On-Demand

US East (Ohio) $0.0416/hr

Asia Pacific (Tokyo) $0.0544/hr

Asia Pacific (Mumbai) varies

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

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

The 3 pillars that make AWS infrastructure fundamentally different from on-premise: Resources adjust dynamically to demand Scale up for Black Friday, scale back down in January No need to buy hardware for peak capacity Built-in redundancy across AZs and Regions Critical components backed up automatically Traffic reroutes away from failures without human intervention 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

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) 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) 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

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:

Header Value Meaning

x-cache Hit from cloudfront Served from edge cache ✅

x-cache Miss from cloudfront Fetched from origin ⏳

x-amz-cf-pop BOM78-P1 Mumbai edge location served you

age 3421 Content cached for 3421 seconds

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

Factor Normal S3 Access CloudFront

Latency 500ms–2000ms+ 20ms–100ms

Caching None Edge cache (TTL configurable)

HTTPS Not default Enforced by default

Origin Load Every request hits origin Cache hits skip origin

DDoS Protection None AWS Shield + WAF

Geographic Opt. Fixed region Nearest edge served

Cost (repeat req.) Charged per request Lower with edge caching

Security Bucket policy only OAC + WAF + Signed URLs

💡 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. 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: 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

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 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

✅ 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

Accidental AWS charges are the #1 beginner mistake. Here’s how to stay safe: 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

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

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

Service Free Tier Limit Watch Out For

EC2 750 hrs/month (t2.micro) Running 2+ instances = double hours

S3 5 GB storage + 20K GET requests Large uploads, frequent requests

Lambda 1M requests/month Usually safe for learning

RDS 750 hrs/month (db.t2.micro) Easy to forget and leave running

CloudFront 1 TB data transfer/month Usually safe for labs

Data Transfer OUT 100 GB/month Serving large files to internet

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. 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. 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. 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

Term Definition

Region Geographic AWS infrastructure cluster (e.g., Mumbai)

AZ Isolated data center(s) within a Region with independent power/network

Edge Location CDN cache server in major cities, used by CloudFront/Route53

Regional Edge Cache Mid-tier cache between origin and edge, for less popular content

PoP Point of Presence — AWS nodes in major cities for low-latency delivery

CloudFront AWS’s Content Delivery Network service

CDN Content Delivery Network — global cache network

Cache Hit Content found at edge — served instantly, no origin call

Cache Miss Content not at edge yet — must fetch from origin

TTL Time To Live — how long content stays cached before refresh

OAC Origin Access Control — only CloudFront can access S3

Latency Time for data to travel from source to destination

Fault Tolerance System continues operating despite component failures

High Availability System maintains uptime with minimal downtime

Failover Automatic switch to backup when primary fails

GDPR EU data privacy law requiring data to stay within EU

GovCloud Isolated AWS Regions for US government workloads

Data Residency Legal requirement for data to stay in a specific country

WAF Web Application Firewall — filters malicious web traffic

DDoS Distributed Denial of Service — flood attack on servers

A startup in Bangalore is building an app for Indian users. Which Region should they choose and why? Your app is deployed in only one AZ. What is the risk, and how would you fix it? You access a CloudFront URL and see x-cache: Miss from cloudfront. What does this mean? What will you see on the second request? A client says “our hospital patient data cannot leave India.” What AWS concept does this relate to, and which Region would you recommend? What is the difference between an Edge Location and an Availability Zone? You check your AWS bill and see unexpected S3 charges. List 3 things you would check first. Why does AWS recommend enabling MFA on both Root AND IAM users? 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: Legal/compliance requirements (check this FIRST — GDPR, RBI, etc.) Proximity to your users (use cloudping.info to measure actual latency) Service availability (not all services exist in every Region) Pricing (same service, different price per Region) 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. 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. 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