Core Concepts - Dev Weekends

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

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

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

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

# 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

Q1: What's the difference between a Region and an Availability Zone?

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

Q2: When would you use Spot Instances vs Reserved Instances?

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.

Q3: Explain the Shared Responsibility Model

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

Q4: How would you design a highly available application on AWS?

Answer:

Multi-AZ Deployment: Run instances in at least 2-3 AZs
Load Balancing: Use ALB/NLB to distribute traffic
Auto Scaling: Automatically add/remove instances based on demand
Database HA: RDS Multi-AZ or Aurora with read replicas
Stateless Design: Store session data in ElastiCache, not on instances
Health Checks: Route 53 health checks for DNS failover
Data Replication: S3 cross-region replication for DR

This achieves 99.99% availability (52 minutes downtime/year).

Q5: What is an ARN and why is it important?

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.

Enable MFA on Root Account

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

Create IAM Admin User

Create IAM user with AdministratorAccess policy
Enable MFA for this user
Use this user for all future operations

Set Up Billing Alerts

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

Enable CloudTrail

Go to CloudTrail
Create a trail in all regions
Store logs in S3 with encryption

Create Account Alias

Go to IAM → Dashboard
Create a custom alias for easier sign-in
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

​Module Overview

​AWS Global Infrastructure

​Regions

​How to Choose a Region

Latency

Compliance

Service Availability

Pricing

​Availability Zones (AZs)

​Designing for High Availability

​Edge Locations

​AWS Pricing Models

​Pricing Model Comparison

​On-Demand Pricing

​Reserved Instances

​Spot Instances

​Savings Plans

​Shared Responsibility Model

​Responsibility by Service Type

​AWS Account Structure

​Root Account Security

​AWS Organizations

​Common Abbreviations Reference

​🎯 Interview Questions

​🧪 Hands-On Lab: Secure Account Setup

​Next Module

Compute Services

Module Overview

AWS Global Infrastructure

Regions

How to Choose a Region

Availability Zones (AZs)

Designing for High Availability

Edge Locations

AWS Pricing Models

Pricing Model Comparison

On-Demand Pricing

Reserved Instances

Spot Instances

Savings Plans

Shared Responsibility Model

Responsibility by Service Type

AWS Account Structure

Root Account Security

AWS Organizations

Common Abbreviations Reference

🎯 Interview Questions

🧪 Hands-On Lab: Secure Account Setup

Next Module