> ## Documentation Index > Fetch the complete documentation index at: https://resources.devweekends.com/llms.txt > Use this file to discover all available pages before exploring further. # Core Concepts > AWS global infrastructure, regions, pricing, and fundamental concepts every cloud professional must know 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. Everything else in this course builds on these ideas. A senior engineer who truly understands regions, availability zones, and pricing models will make better architecture decisions than someone who memorizes every service name but does not understand the underlying infrastructure. 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 Choose the region closest to your users for lowest latency Data residency laws may require specific regions (GDPR, HIPAA) Not all services are available in all regions—check first Prices vary by region (us-east-1 is often cheapest) ```python theme={null} # 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. The biggest savings come not from clever discounting but from turning off resources you are not using and right-sizing instances that are over-provisioned. A senior engineer would say: "The cheapest instance is the one you don't run." ### Pricing Model Comparison | Model | Discount | Commitment | Best For | | ------------------ | -------- | ------------------------- | ---------------------------------- | | **On-Demand** | 0% | None | Unpredictable workloads, dev/test | | **Reserved (1yr)** | 30-40% | 1 year | Steady-state production | | **Reserved (3yr)** | 60-72% | 3 years | Long-term stable workloads | | **Spot** | 60-90% | None (can be interrupted) | Batch processing, fault-tolerant | | **Savings Plans** | 30-72% | \$/hour commitment | Flexible across EC2/Lambda/Fargate | ### On-Demand Pricing Pay by the second (minimum 60 seconds) with no commitments. ```python theme={null} # 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 Use unused EC2 capacity for up to 90% off. Instances can be reclaimed with a 2-minute warning. The mental model: spot instances are like standby airline tickets -- you get a massive discount because you are willing to be bumped if the flight fills up. The key to using spot successfully is designing for interruption: run stateless workloads, spread across multiple instance types and AZs, and save checkpoints frequently. ```python theme={null} # 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 Type | Flexibility | Discount | | ---------------- | ---------------------------------- | --------- | | **Compute** | Any EC2, Lambda, Fargate | Up to 66% | | **EC2 Instance** | Specific instance family in region | Up to 72% | | **SageMaker** | ML instances | Up to 64% | *** ## Shared Responsibility Model AWS security is a shared responsibility between AWS and the customer. This is the single most important security concept in cloud computing -- misunderstanding it is behind the majority of cloud security breaches. The analogy: AWS provides a secure building (locks on the doors, security guards, fire suppression), but if you leave your apartment door wide open, that is your problem, not the building's. AWS secures the infrastructure; you secure what you put on it. ``` ┌────────────────────────────────────────────────────────────────────────┐ │ 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 Type | Example | Customer Manages | AWS Manages | | -------------- | ------- | ------------------------ | ---------------------- | | **IaaS** | EC2 | OS, apps, data, firewall | Hardware, hypervisor | | **Container** | ECS | Apps, data | Cluster, OS patching | | **Serverless** | Lambda | Code, data | Everything else | | **Managed** | RDS | Data, users | DB 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. ```python theme={null} # 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 | Abbreviation | Full Form | Description | | ------------ | ------------------------------ | -------------------------- | | **EC2** | Elastic Compute Cloud | Virtual servers | | **S3** | Simple Storage Service | Object storage | | **RDS** | Relational Database Service | Managed SQL databases | | **VPC** | Virtual Private Cloud | Isolated network | | **IAM** | Identity and Access Management | User/role management | | **ELB** | Elastic Load Balancer | Load balancing | | **ALB** | Application Load Balancer | Layer 7 load balancer | | **NLB** | Network Load Balancer | Layer 4 load balancer | | **EBS** | Elastic Block Store | Block storage | | **EFS** | Elastic File System | Managed NFS | | **SNS** | Simple Notification Service | Pub/sub messaging | | **SQS** | Simple Queue Service | Message queuing | | **ECS** | Elastic Container Service | Container orchestration | | **EKS** | Elastic Kubernetes Service | Managed Kubernetes | | **AZ** | Availability Zone | Data center cluster | | **ARN** | Amazon Resource Name | Unique 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. Sign in as root user 2. Go to IAM → Security credentials 3. Enable virtual MFA or hardware MFA 1. Create IAM user with `AdministratorAccess` policy 2. Enable MFA for this user 3. Use this user for all future operations 1. Go to Billing → Budgets 2. Create a budget for \$10 (or your limit) 3. Set email alerts at 50%, 80%, 100% 1. Go to CloudTrail 2. Create a trail in all regions 3. Store logs in S3 with encryption 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 Learn about EC2, Lambda, ECS, EKS, and Auto Scaling