Skip to main content
AWS Global Infrastructure

Module Overview

Estimated Time: 2-3 hours | Difficulty: Beginner | Prerequisites: None
This module covers the foundational concepts that underpin all AWS services. Understanding these concepts is essential for designing reliable, cost-effective architectures. What You’ll Learn:
  • AWS global infrastructure and how to choose regions
  • Availability Zones and designing for high availability
  • AWS pricing models and cost optimization strategies
  • The shared responsibility model for security
  • Account structure and AWS Organizations

AWS Global Infrastructure

AWS operates the world’s largest cloud infrastructure, designed for high availability, fault tolerance, and low latency.

Regions

A Region is a geographical area containing multiple data centers. Each region is completely independent and isolated from other regions.
┌─────────────────────────────────────────────────────────────────────────┐
│                       AWS Global Infrastructure (2025)                   │
├─────────────────────────────────────────────────────────────────────────┤
│                                                                          │
│   🌎 Americas (10 Regions)                                               │
│   ─────────────────────────                                              │
│   us-east-1      N. Virginia    ⭐ Largest, most services               │
│   us-east-2      Ohio           💰 Lower cost alternative                │
│   us-west-1      N. California  🌉 West coast presence                   │
│   us-west-2      Oregon         💰 Cost-effective, green energy         │
│   ca-central-1   Canada         🍁 Canadian data residency               │
│   sa-east-1      São Paulo      🇧🇷 South America                        │
│                                                                          │
│   🌍 Europe, Middle East, Africa (10 Regions)                            │
│   ──────────────────────────────────────────                             │
│   eu-west-1      Ireland        ⭐ Largest EU region                     │
│   eu-west-2      London         🇬🇧 UK data residency                    │
│   eu-central-1   Frankfurt      🇩🇪 GDPR compliance hub                  │
│   eu-north-1     Stockholm      🌱 100% renewable energy                 │
│   me-south-1     Bahrain        🏜️ Middle East                          │
│   af-south-1     Cape Town      🌍 Africa                                │
│                                                                          │
│   🌏 Asia Pacific (12 Regions)                                           │
│   ────────────────────────────                                           │
│   ap-northeast-1 Tokyo          ⭐ Largest APAC region                   │
│   ap-northeast-2 Seoul          🇰🇷 South Korea                          │
│   ap-southeast-1 Singapore      🌏 Southeast Asia hub                    │
│   ap-southeast-2 Sydney         🦘 Australia/NZ                          │
│   ap-south-1     Mumbai         🇮🇳 India                                │
│   cn-north-1     Beijing        🇨🇳 China (separate partition)           │
│                                                                          │
└─────────────────────────────────────────────────────────────────────────┘

How to Choose a Region

Latency

Choose the region closest to your users for lowest latency

Compliance

Data residency laws may require specific regions (GDPR, HIPAA)

Service Availability

Not all services are available in all regions—check first

Pricing

Prices vary by region (us-east-1 is often cheapest)
# Decision matrix for region selection
def choose_region(requirements):
    """
    Priority order for choosing AWS region:
    1. Compliance requirements (legal/regulatory)
    2. Latency to primary users
    3. Service availability
    4. Pricing considerations
    """
    
    # Example: E-commerce app for European customers
    if requirements.get('gdpr_required'):
        return 'eu-west-1'  # Ireland - GDPR compliant
    
    if requirements.get('primary_users') == 'asia':
        return 'ap-southeast-1'  # Singapore - APAC hub
    
    if requirements.get('cost_sensitive'):
        return 'us-east-1'  # Usually cheapest
    
    return 'us-east-1'  # Default - most services, largest
Pro Tip: us-east-1 (N. Virginia) is the oldest and largest AWS region. New services launch here first, but it’s also the most crowded. Consider us-east-2 (Ohio) for similar pricing with less congestion.

Availability Zones (AZs)

Each region has multiple Availability Zones (typically 3-6). Each AZ is one or more discrete data centers with redundant power, networking, and connectivity.
┌──────────────────────────────────────────────────────────────────────────┐
│                        Region: us-east-1                                  │
├──────────────────────────────────────────────────────────────────────────┤
│                                                                           │
│   ┌─────────────────┐  ┌─────────────────┐  ┌─────────────────┐          │
│   │   AZ: us-east-1a │  │   AZ: us-east-1b │  │   AZ: us-east-1c │        │
│   │                  │  │                  │  │                  │        │
│   │  ┌────────────┐  │  │  ┌────────────┐  │  │  ┌────────────┐  │        │
│   │  │ Data       │  │  │  │ Data       │  │  │  │ Data       │  │        │
│   │  │ Center 1   │  │  │  │ Center 3   │  │  │  │ Center 5   │  │        │
│   │  └────────────┘  │  │  └────────────┘  │  │  └────────────┘  │        │
│   │  ┌────────────┐  │  │  ┌────────────┐  │  │  ┌────────────┐  │        │
│   │  │ Data       │  │  │  │ Data       │  │  │  │ Data       │  │        │
│   │  │ Center 2   │  │  │  │ Center 4   │  │  │  │ Center 6   │  │        │
│   │  └────────────┘  │  │  └────────────┘  │  │  └────────────┘  │        │
│   │                  │  │                  │  │                  │        │
│   └────────┬─────────┘  └────────┬─────────┘  └────────┬─────────┘        │
│            │                     │                     │                  │
│            └─────────────────────┼─────────────────────┘                  │
│                                  │                                        │
│                    High-bandwidth, low-latency                            │
│                    private fiber connections                              │
│                    (< 2ms latency between AZs)                            │
│                                                                           │
│   Key Characteristics:                                                    │
│   • Physically separated by miles (distinct facilities)                   │
│   • Independent power, cooling, and networking                            │
│   • Connected via redundant, dedicated metro fiber                        │
│   • Designed for fault isolation                                          │
│                                                                           │
└──────────────────────────────────────────────────────────────────────────┘

Designing for High Availability

┌────────────────────────────────────────────────────────────────────┐
│              Multi-AZ Architecture Pattern                          │
├────────────────────────────────────────────────────────────────────┤
│                                                                     │
│                    ┌─────────────────┐                             │
│                    │  Route 53 (DNS) │                             │
│                    │  Health Checks  │                             │
│                    └────────┬────────┘                             │
│                             │                                       │
│                    ┌────────▼────────┐                             │
│                    │ Load Balancer   │                             │
│                    │ (spans all AZs) │                             │
│                    └────────┬────────┘                             │
│           ┌─────────────────┼─────────────────┐                    │
│           │                 │                 │                    │
│           ▼                 ▼                 ▼                    │
│   ┌──────────────┐  ┌──────────────┐  ┌──────────────┐            │
│   │     AZ-1a    │  │     AZ-1b    │  │     AZ-1c    │            │
│   │  ┌────────┐  │  │  ┌────────┐  │  │  ┌────────┐  │            │
│   │  │ EC2 x2 │  │  │  │ EC2 x2 │  │  │  │ EC2 x2 │  │            │
│   │  └────────┘  │  │  └────────┘  │  │  └────────┘  │            │
│   │  ┌────────┐  │  │  ┌────────┐  │  │  ┌────────┐  │            │
│   │  │RDS     │  │  │  │RDS     │  │  │  │(unused)│  │            │
│   │  │Primary │◄─┼──┼─►│Standby │  │  │  │        │  │            │
│   │  └────────┘  │  │  └────────┘  │  │  └────────┘  │            │
│   └──────────────┘  └──────────────┘  └──────────────┘            │
│                                                                     │
│   Availability = 99.99% (4 nines)                                  │
│   If one AZ fails, traffic routes to remaining AZs                 │
│                                                                     │
└────────────────────────────────────────────────────────────────────┘
Critical Design Principle: Always deploy production workloads across at least 2 AZs. A single AZ has ~99.9% availability; Multi-AZ achieves ~99.99%.

Edge Locations

Edge Locations are AWS data centers designed to deliver content to end users with low latency. There are 400+ edge locations worldwide. Services using Edge Locations:
  • CloudFront (CDN) - Cache static and dynamic content
  • Route 53 (DNS) - Low-latency DNS resolution
  • AWS Global Accelerator - Optimized routing
  • Lambda@Edge - Run code at edge locations
┌────────────────────────────────────────────────────────────────────┐
│                    Edge Location Architecture                       │
├────────────────────────────────────────────────────────────────────┤
│                                                                     │
│   User in Paris                     User in Tokyo                   │
│        │                                  │                         │
│        ▼                                  ▼                         │
│   ┌──────────────┐                  ┌──────────────┐               │
│   │ Edge: Paris  │                  │ Edge: Tokyo  │               │
│   │ (< 10ms)     │                  │ (< 10ms)     │               │
│   └──────┬───────┘                  └──────┬───────┘               │
│          │                                 │                        │
│          │      Cache HIT? Serve locally   │                        │
│          │      Cache MISS? Fetch origin   │                        │
│          │                                 │                        │
│          └────────────────┬────────────────┘                        │
│                           │                                         │
│                           ▼                                         │
│                  ┌─────────────────┐                               │
│                  │   Origin Server  │                               │
│                  │   (us-east-1)    │                               │
│                  └─────────────────┘                               │
│                                                                     │
│   Result: Users worldwide get < 50ms latency instead of 200ms+     │
│                                                                     │
└────────────────────────────────────────────────────────────────────┘

AWS Pricing Models

Understanding pricing is crucial for cost optimization—often 40-70% of cloud spend can be optimized.

Pricing Model Comparison

ModelDiscountCommitmentBest For
On-Demand0%NoneUnpredictable workloads, dev/test
Reserved (1yr)30-40%1 yearSteady-state production
Reserved (3yr)60-72%3 yearsLong-term stable workloads
Spot60-90%None (can be interrupted)Batch processing, fault-tolerant
Savings Plans30-72%$/hour commitmentFlexible across EC2/Lambda/Fargate

On-Demand Pricing

Pay by the second (minimum 60 seconds) with no commitments.
# EC2 On-Demand Pricing Examples (us-east-1, 2025)
on_demand_pricing = {
    't3.micro':   {'hourly': 0.0104, 'monthly':  7.49},   # 1 vCPU, 1 GB
    't3.medium':  {'hourly': 0.0416, 'monthly': 29.95},   # 2 vCPU, 4 GB
    'm5.large':   {'hourly': 0.096,  'monthly': 69.12},   # 2 vCPU, 8 GB
    'm5.xlarge':  {'hourly': 0.192,  'monthly': 138.24},  # 4 vCPU, 16 GB
    'c5.2xlarge': {'hourly': 0.34,   'monthly': 244.80},  # 8 vCPU, 16 GB
}

def calculate_monthly_cost(instance_type, hours_per_day=24, days=30):
    """Calculate monthly cost for an instance type."""
    hourly_rate = on_demand_pricing[instance_type]['hourly']
    return hourly_rate * hours_per_day * days

Reserved Instances

Commit to 1 or 3 years for significant discounts.
┌────────────────────────────────────────────────────────────────────┐
│                 Reserved Instance Pricing                           │
├────────────────────────────────────────────────────────────────────┤
│                                                                     │
│   m5.large in us-east-1                                            │
│                                                                     │
│   On-Demand:        $0.096/hour    = $69.12/month   (baseline)     │
│                                                                     │
│   ┌─────────────────────────────────────────────────────────────┐  │
│   │ 1-Year Reserved                                              │  │
│   │ ───────────────                                              │  │
│   │ No Upfront:     $0.060/hour    = $43.20/month   (37% off)   │  │
│   │ Partial Upfront: $0.056/hour   = $40.32/month   (42% off)   │  │
│   │ All Upfront:    $0.053/hour    = $38.16/month   (45% off)   │  │
│   └─────────────────────────────────────────────────────────────┘  │
│                                                                     │
│   ┌─────────────────────────────────────────────────────────────┐  │
│   │ 3-Year Reserved                                              │  │
│   │ ───────────────                                              │  │
│   │ No Upfront:     $0.043/hour    = $30.96/month   (55% off)   │  │
│   │ Partial Upfront: $0.038/hour   = $27.36/month   (60% off)   │  │
│   │ All Upfront:    $0.033/hour    = $23.76/month   (66% off)   │  │
│   └─────────────────────────────────────────────────────────────┘  │
│                                                                     │
│   Annual Savings (3yr All Upfront): $544/instance/year             │
│                                                                     │
└────────────────────────────────────────────────────────────────────┘

Spot Instances

Bid on unused EC2 capacity for up to 90% off. Instances can be terminated with 2-minute warning.
# Spot Instance Strategy
class SpotStrategy:
    """
    When to use Spot Instances:
    ✅ Batch processing jobs
    ✅ CI/CD build workers
    ✅ Data analysis workloads
    ✅ Containerized microservices
    ✅ Distributed computing (Hadoop, Spark)
    
    When NOT to use Spot:
    ❌ Databases
    ❌ Stateful applications
    ❌ Single points of failure
    ❌ Applications that can't handle interruption
    """
    
    def calculate_savings(self, on_demand_rate, spot_rate, hours):
        savings = (on_demand_rate - spot_rate) * hours
        percent_saved = ((on_demand_rate - spot_rate) / on_demand_rate) * 100
        return {
            'savings': savings,
            'percent_saved': f"{percent_saved:.1f}%"
        }

# Example: c5.xlarge
# On-Demand: $0.17/hour
# Spot: $0.051/hour (70% off!)
# Monthly savings: ($0.17 - $0.051) * 720 = $85.68/instance
Spot Best Practice: Use Spot Fleet with multiple instance types and AZs to maximize availability and minimize interruptions.

Savings Plans

Flexible alternative to Reserved Instances. Commit to a consistent amount of usage ($/hour) for 1 or 3 years.
Plan TypeFlexibilityDiscount
ComputeAny EC2, Lambda, FargateUp to 66%
EC2 InstanceSpecific instance family in regionUp to 72%
SageMakerML instancesUp to 64%

Shared Responsibility Model

AWS security is a shared responsibility between AWS and the customer.
┌────────────────────────────────────────────────────────────────────────┐
│                    SHARED RESPONSIBILITY MODEL                          │
├────────────────────────────────────────────────────────────────────────┤
│                                                                         │
│  ╔═══════════════════════════════════════════════════════════════════╗ │
│  ║                    CUSTOMER RESPONSIBILITY                         ║ │
│  ║                    "Security IN the Cloud"                         ║ │
│  ╠═══════════════════════════════════════════════════════════════════╣ │
│  ║                                                                    ║ │
│  ║   ┌─────────────────────────────────────────────────────────────┐ ║ │
│  ║   │                    Customer Data                             │ ║ │
│  ║   │            (Your applications, user data)                    │ ║ │
│  ║   └─────────────────────────────────────────────────────────────┘ ║ │
│  ║   ┌─────────────────────────────────────────────────────────────┐ ║ │
│  ║   │     Platform, Applications, Identity & Access Management    │ ║ │
│  ║   │              (IAM, Security Groups, NACLs)                  │ ║ │
│  ║   └─────────────────────────────────────────────────────────────┘ ║ │
│  ║   ┌─────────────────────────────────────────────────────────────┐ ║ │
│  ║   │   Operating System, Network & Firewall Configuration        │ ║ │
│  ║   │            (EC2 patches, custom AMIs)                       │ ║ │
│  ║   └─────────────────────────────────────────────────────────────┘ ║ │
│  ║   ┌─────────────────────────────────────────────────────────────┐ ║ │
│  ║   │        Client-Side Data Encryption & Integrity              │ ║ │
│  ║   │    Server-Side Encryption | Network Traffic Protection      │ ║ │
│  ║   └─────────────────────────────────────────────────────────────┘ ║ │
│  ║                                                                    ║ │
│  ╚═══════════════════════════════════════════════════════════════════╝ │
│                                                                         │
│  ╔═══════════════════════════════════════════════════════════════════╗ │
│  ║                      AWS RESPONSIBILITY                            ║ │
│  ║                    "Security OF the Cloud"                         ║ │
│  ╠═══════════════════════════════════════════════════════════════════╣ │
│  ║                                                                    ║ │
│  ║   ┌─────────────────────────────────────────────────────────────┐ ║ │
│  ║   │              Software: Compute, Storage, Database            │ ║ │
│  ║   │                      Networking                              │ ║ │
│  ║   └─────────────────────────────────────────────────────────────┘ ║ │
│  ║   ┌─────────────────────────────────────────────────────────────┐ ║ │
│  ║   │                 Hardware / AWS Global Infrastructure         │ ║ │
│  ║   │           Regions | Availability Zones | Edge Locations      │ ║ │
│  ║   └─────────────────────────────────────────────────────────────┘ ║ │
│  ║                                                                    ║ │
│  ╚═══════════════════════════════════════════════════════════════════╝ │
│                                                                         │
└────────────────────────────────────────────────────────────────────────┘

Responsibility by Service Type

Service TypeExampleCustomer ManagesAWS Manages
IaaSEC2OS, apps, data, firewallHardware, hypervisor
ContainerECSApps, dataCluster, OS patching
ServerlessLambdaCode, dataEverything else
ManagedRDSData, usersDB engine, OS, backups

AWS Account Structure

Root Account Security

Never use the root account for daily operations! The root account has unrestricted access to everything.
# Root Account Security Checklist
root_account_checklist = {
    "enable_mfa": True,           # Hardware MFA preferred
    "delete_access_keys": True,   # No programmatic access for root
    "create_admin_iam_user": True,# Use IAM for all operations
    "enable_billing_alerts": True,# Catch unexpected charges
    "enable_cloudtrail": True,    # Audit all API calls
}

# Tasks that REQUIRE root account:
root_required_tasks = [
    "Change account email or name",
    "Close AWS account",
    "Change AWS support plan",
    "Enable MFA delete on S3",
    "Restore IAM permissions",
    "View certain tax invoices",
]

AWS Organizations

Manage multiple AWS accounts centrally with consolidated billing and policy governance.
┌────────────────────────────────────────────────────────────────────┐
│                     AWS Organizations Structure                     │
├────────────────────────────────────────────────────────────────────┤
│                                                                     │
│   Management Account (Root)                                         │
│   └── Consolidated Billing                                          │
│   └── Service Control Policies (SCPs)                               │
│           │                                                         │
│           ├── OU: Production                                        │
│           │   └── SCP: Deny delete VPC Flow Logs                   │
│           │   └── SCP: Require encryption                          │
│           │       ├── Account: Prod-Web (111111111111)             │
│           │       ├── Account: Prod-API (222222222222)             │
│           │       └── Account: Prod-Data (333333333333)            │
│           │                                                         │
│           ├── OU: Development                                       │
│           │   └── SCP: Limit to t3.medium max                      │
│           │       ├── Account: Dev (444444444444)                  │
│           │       └── Account: Staging (555555555555)              │
│           │                                                         │
│           ├── OU: Security                                          │
│           │   └── SCP: Full access (for auditing)                  │
│           │       ├── Account: Audit (666666666666)                │
│           │       └── Account: Log-Archive (777777777777)          │
│           │                                                         │
│           └── OU: Sandbox                                           │
│               └── SCP: No production access                         │
│                   └── Account: Experiments (888888888888)           │
│                                                                     │
│   Benefits:                                                         │
│   • Consolidated billing across all accounts                        │
│   • Volume discounts applied automatically                          │
│   • Centralized security policies                                   │
│   • Isolation between environments                                  │
│                                                                     │
└────────────────────────────────────────────────────────────────────┘

Common Abbreviations Reference

AbbreviationFull FormDescription
EC2Elastic Compute CloudVirtual servers
S3Simple Storage ServiceObject storage
RDSRelational Database ServiceManaged SQL databases
VPCVirtual Private CloudIsolated network
IAMIdentity and Access ManagementUser/role management
ELBElastic Load BalancerLoad balancing
ALBApplication Load BalancerLayer 7 load balancer
NLBNetwork Load BalancerLayer 4 load balancer
EBSElastic Block StoreBlock storage
EFSElastic File SystemManaged NFS
SNSSimple Notification ServicePub/sub messaging
SQSSimple Queue ServiceMessage queuing
ECSElastic Container ServiceContainer orchestration
EKSElastic Kubernetes ServiceManaged Kubernetes
AZAvailability ZoneData center cluster
ARNAmazon Resource NameUnique resource identifier

🎯 Interview Questions

Answer: A Region is a geographical area (e.g., us-east-1) containing multiple isolated data center clusters called Availability Zones. AZs are physically separated but connected by low-latency fiber. Regions are completely isolated from each other.Key Points:
  • Region = Geographic area (e.g., N. Virginia, Ireland)
  • AZ = One or more data centers within a region
  • AZs are connected via private fiber (< 2ms latency)
  • Regions are isolated for fault tolerance
Answer:Spot Instances (up to 90% off):
  • Fault-tolerant, stateless workloads
  • Batch processing, CI/CD, data analysis
  • Can be interrupted with 2-minute notice
Reserved Instances (up to 72% off):
  • Steady-state, predictable workloads
  • Production databases, core application servers
  • Commitment of 1 or 3 years
Decision Framework: If your workload can handle interruption, use Spot. If it needs guaranteed capacity, use Reserved.
Answer: AWS is responsible for security of the cloud (hardware, facilities, managed services infrastructure). Customers are responsible for security in the cloud (data, applications, IAM, network configuration).Example for EC2:
  • AWS: Hypervisor, physical security, network infrastructure
  • Customer: OS patching, firewall rules, IAM, encryption, application security
Example for Lambda:
  • AWS: Runtime, OS, scaling, infrastructure
  • Customer: Code security, IAM permissions, data encryption
Answer:
  1. Multi-AZ Deployment: Run instances in at least 2-3 AZs
  2. Load Balancing: Use ALB/NLB to distribute traffic
  3. Auto Scaling: Automatically add/remove instances based on demand
  4. Database HA: RDS Multi-AZ or Aurora with read replicas
  5. Stateless Design: Store session data in ElastiCache, not on instances
  6. Health Checks: Route 53 health checks for DNS failover
  7. Data Replication: S3 cross-region replication for DR
This achieves 99.99% availability (52 minutes downtime/year).
Answer: ARN (Amazon Resource Name) is a unique identifier for any AWS resource. Format:
arn:aws:service:region:account-id:resource-type/resource-id
Examples:
  • arn:aws:s3:::my-bucket (S3 bucket)
  • arn:aws:ec2:us-east-1:123456789012:instance/i-1234567890abcdef0
Importance:
  • Required in IAM policies to specify resources
  • Used in CloudFormation/Terraform for cross-references
  • Essential for resource-level permissions

🧪 Hands-On Lab: Secure Account Setup

Objective: Set up your AWS account following security best practices.
1

Enable MFA on Root Account

  1. Sign in as root user
  2. Go to IAM → Security credentials
  3. Enable virtual MFA or hardware MFA
2

Create IAM Admin User

  1. Create IAM user with AdministratorAccess policy
  2. Enable MFA for this user
  3. Use this user for all future operations
3

Set Up Billing Alerts

  1. Go to Billing → Budgets
  2. Create a budget for $10 (or your limit)
  3. Set email alerts at 50%, 80%, 100%
4

Enable CloudTrail

  1. Go to CloudTrail
  2. Create a trail in all regions
  3. Store logs in S3 with encryption
5

Create Account Alias

  1. Go to IAM → Dashboard
  2. Create a custom alias for easier sign-in
  3. Bookmark the new sign-in URL
Checkpoint: You should now have a secure AWS account with MFA, CloudTrail logging, and billing alerts. Never use the root account again except for the few tasks that require it.

Next Module

Compute Services

Learn about EC2, Lambda, ECS, EKS, and Auto Scaling