☁ Cloud Concepts & AWS Services

The Core Idea

Cloud computing means renting computing resources over the internet instead of buying and managing your own hardware. Think of it like electricity — you don't build your own power plant; you plug into the grid and pay for what you use.

Before cloud, a startup wanting to launch an app needed to: buy servers, rent datacenter space, hire a sysadmin, buy networking hardware, wait weeks for delivery — all before writing a single line of code. Cloud made that a 5-minute signup.

NIST 5 Essential Characteristics

The official NIST definition says cloud computing must have all 5 of these:

CAPEX vs OPEX

The "Pizza as a Service" Analogy

These models define how much of the stack the cloud provider manages vs how much you manage.

IaaS — Infrastructure as a Service

You get raw compute, storage, and networking. You manage the OS up. Most control, most responsibility.

Real example: You rent an EC2 instance, install Ubuntu, install Nginx, deploy your app. If the OS crashes, that's on you to fix.

PaaS — Platform as a Service

You just deploy your application code/container. The provider handles OS patching, scaling infrastructure, runtime. Less control, less ops work.

Real example: You push a Python Flask app to Elastic Beanstalk. AWS auto-provisions EC2, load balancer, and auto-scaling. You never SSH into a server.

SaaS — Software as a Service

You're just a user of a complete application. No infrastructure, no app management. Just login and use it.

Real example: Gmail, Slack, Salesforce. AWS WorkMail is also SaaS.

The Most Important Concept in Cloud Security

AWS (and all cloud providers) operate under a shared responsibility model. In simple terms: AWS is responsible for security OF the cloud. YOU are responsible for security IN the cloud.

  ┌──────────────────────────────────────────────────────────────────┐
  │                      CUSTOMER RESPONSIBILITY                     │
  │  (Security IN the cloud)                                         │
  │                                                                  │
  │  ┌─────────────┐  ┌─────────────┐  ┌──────────────────────────┐ │
  │  │  Customer   │  │  Platform,  │  │  Identity & Access Mgmt  │ │
  │  │    Data     │  │  App, OS    │  │  (IAM users, policies)   │ │
  │  └─────────────┘  └─────────────┘  └──────────────────────────┘ │
  │  ┌─────────────┐  ┌─────────────┐  ┌──────────────────────────┐ │
  │  │  Firewall / │  │  Network    │  │  Client-side & Server-   │ │
  │  │  Sec Groups │  │  Config     │  │  side Encryption         │ │
  │  └─────────────┘  └─────────────┘  └──────────────────────────┘ │
  └──────────────────────────────────────────────────────────────────┘
  ┌──────────────────────────────────────────────────────────────────┐
  │                       AWS RESPONSIBILITY                         │
  │  (Security OF the cloud)                                         │
  │                                                                  │
  │  ┌────────────────────────────────────────────────────────────┐  │
  │  │  Compute | Storage | Networking | Database (managed infra) │  │
  │  └────────────────────────────────────────────────────────────┘  │
  │  ┌────────────────────────────────────────────────────────────┐  │
  │  │  Physical Security of Datacenters, Hardware, Network Infra │  │
  │  └────────────────────────────────────────────────────────────┘  │
  └──────────────────────────────────────────────────────────────────┘

Responsibility Shifts Based on Service Model

Why Geography Matters in Cloud

Your users are physically distributed. A server in the US takes ~150ms to respond to a user in India. Cloud providers build datacenters globally to solve this. But geography also matters for compliance (EU GDPR requires EU data stay in EU), disaster recovery (separate physical locations), and cost (prices vary by region).

Regions

A Region is a geographically separate area of the world with a cluster of datacenters. Each region has a unique name like us-east-1 (N. Virginia), ap-south-1 (Mumbai), eu-west-1 (Ireland).

• AWS has 33+ regions worldwide (2024)
• Regions are completely independent — a region-wide failure doesn't affect other regions
• Not all services are available in all regions (e.g., some AI services only in US regions initially)
• Data does NOT automatically replicate across regions — you must explicitly configure cross-region replication

Availability Zones (AZs)

Each region has 2-6 AZs (usually 3). An AZ is one or more discrete datacenters with:

• Independent power supply (UPS + diesel generators)
• Independent networking (separate internet uplinks)
• Physical separation (miles apart, so one fire/flood doesn't take both)
• But connected with high-speed, low-latency private fiber within the region (<1ms)

Edge Locations & CloudFront PoPs

For CDN (CloudFront), AWS has 600+ edge locations worldwide — far more than regions. These are smaller cache servers placed close to end users. Content cached here gets served with ultra-low latency. Edge locations are also used by Route 53 (DNS) and AWS Shield (DDoS protection).

Other AWS Infrastructure Types

Three Related But Different Concepts

These terms are often confused. Think of a hospital as an analogy:

Nines of Availability

RPO and RTO — The Two DR Metrics

  Normal ──────────────────┐ DISASTER ┌──────────────── Recovered
  Operation                │ event    │                 state
                           │          │
  [Last backup] ◄──────────┤          ├──────────────► [Back online]
                   RPO     │          │      RTO
                (data gap) │          │  (recovery time)

  Example: RPO=1hr, RTO=4hr
  → You can lose max 1 hour of data
  → You must be back online within 4 hours of the disaster

4 AWS DR Strategies — Cost vs Speed Tradeoff

                        Faster recovery (lower RTO/RPO)
                        ─────────────────────────────►

  CHEAPEST    Backup &    Pilot     Warm      Active-Active    MOST
  (cold)      Restore     Light     Standby   (Multi-site)     EXPENSIVE
              │           │         │         │
              ▼           ▼         ▼         ▼
  RTO:        Hours      Minutes   Minutes   Seconds
  RPO:        Hours      Minutes   Seconds   Near-zero
  Cost:       $           $$        $$$       $$$$
              │           │         │         │
              │           │         │         └─ Full copy in 2nd region
              │           │         └─── Scaled-down running copy
              │           └──── Minimal services always running
              └──── Just backups, nothing running

Strategy 1: Backup & Restore

Regularly back up data and snapshots to S3. When disaster hits, spin up new infrastructure from those backups. Simplest, cheapest, but slowest.

Example: EC2 AMI snapshots every 6 hours to S3. RDS automated backups to another region. If primary region fails, launch new EC2 from AMI, restore RDS from backup. Takes hours.

Strategy 2: Pilot Light

A minimal version of your app is always running in DR region — just the core data-syncing layer (e.g., a database replicating from primary). Application servers are OFF but AMIs/configs are ready. Scale up when needed.

Example: RDS read replica in DR region (always syncing). EC2 AMIs ready. When disaster: promote read replica to master, launch app servers from AMIs. Takes 15-30 minutes.

Strategy 3: Warm Standby

A scaled-down but fully running copy of your system in DR region. It receives traffic in normal times or just sits ready. During disaster, scale it up to full production capacity.

Example: 2 t3.small EC2s in DR region vs 10 m5.xlarge in production. During disaster, scale DR to full size and redirect DNS.

Strategy 4: Active-Active (Multi-Site)

Full production deployment in 2+ regions, ALL serving live traffic. Route 53 routes users to nearest healthy region. If one region fails, all traffic goes to the other with no perceivable downtime.

Example: Netflix runs in multiple AWS regions. If us-east-1 has issues, traffic goes to us-west-2. Users might see a brief slowdown, but no outage.

Scalability = Can It Grow? Elasticity = Does It Grow Automatically?

Scalability means your architecture can handle increased load. Elasticity means it automatically scales up AND back down as load changes — so you're not paying for idle capacity at 3 AM.

Vertical Scaling (Scale Up)

Give the existing server more power. Upgrade from t3.medium (2 vCPU, 4GB) to m5.4xlarge (16 vCPU, 64GB). Simple but has limits (biggest instance size), requires downtime, and creates a single point of failure.

  VERTICAL (Scale Up)                 HORIZONTAL (Scale Out)

  Before: [Server 2GB RAM]            Before: [Server] [Server]
              │                                   │
              ▼                                   ▼
  After:  [Server 16GB RAM]           After:  [Server] [Server] [Server] [Server]
                                                         │
          One server, bigger                      Load Balancer distributes traffic
          Single point of failure                 No SPOF — much more resilient

Horizontal Scaling (Scale Out)

Add more instances of the same server. 1 server → 5 servers behind a load balancer. No single point of failure. Nearly unlimited scale. Requires your app to be stateless (session data stored in Redis/DB, not locally).

Auto Scaling

AWS Auto Scaling automatically adjusts the number of instances based on rules you define. You define a minimum (always have at least 2), maximum (never exceed 20), and desired (target 4 normally).

Scaling can be triggered by: CPU usage > 70%, request count, memory, schedule, or custom CloudWatch metrics.

What is a VPC?

A VPC is a logically isolated private network in the cloud. Think of it as your own private section of AWS that no one else can access. By default, nothing inside your VPC can reach the internet, and the internet can't reach your VPC — you must explicitly configure that.

Analogy: AWS is a massive apartment building. Your VPC is your apartment — you can furnish it however you like inside, but outsiders can't get in unless you let them.

  ┌─────────────────────── AWS Region (ap-south-1) ─────────────────────────┐
  │                                                                          │
  │  ┌──────────────────────── VPC (10.0.0.0/16) ────────────────────────┐  │
  │  │                                                                    │  │
  │  │  ┌── AZ-1a ─────────────────────┐  ┌── AZ-1b ──────────────────┐ │  │
  │  │  │                              │  │                            │ │  │
  │  │  │ [Public Subnet 10.0.1.0/24]  │  │ [Public Subnet 10.0.2.0/24]│ │  │
  │  │  │  ┌──────────┐               │  │  ┌──────────┐             │ │  │
  │  │  │  │ EC2 (web)│               │  │  │ EC2 (web)│             │ │  │
  │  │  │  │  Public  │ NAT GW        │  │  │  Public  │             │ │  │
  │  │  │  │  IP: ✓   │──┐            │  │  │  IP: ✓   │             │ │  │
  │  │  │  └──────────┘  │            │  │  └──────────┘             │ │  │
  │  │  │                │            │  │                            │ │  │
  │  │  │ [Private Sub 10.0.3.0/24]  │  │ [Private Sub 10.0.4.0/24] │ │  │
  │  │  │  ┌──────────┐  │            │  │  ┌──────────┐             │ │  │
  │  │  │  │ EC2 (app)│◄─┘ (outbound)│  │  │ RDS (DB) │             │ │  │
  │  │  │  │ No pub IP│               │  │  │ No pub IP│             │ │  │
  │  │  │  └──────────┘               │  │  └──────────┘             │ │  │
  │  │  └──────────────────────────────┘  └────────────────────────── ┘ │  │
  │  │                       │                                           │  │
  │  │              Internet Gateway (IGW)                               │  │
  │  └───────────────────────┼───────────────────────────────────────────┘  │
  │                          │                                              │
  └──────────────────────────┼──────────────────────────────────────────────┘
                             │
                         INTERNET

Key Networking Components

CIDR Block

When you create a VPC, you assign it a CIDR block like 10.0.0.0/16. This defines the IP range for your entire VPC (65,536 IPs). You then carve subnets from this range.

Subnets

Subnets divide the VPC into smaller networks, and they're tied to a specific AZ. A public subnet has a route to the internet via an Internet Gateway. A private subnet has no direct internet route — instances here can't be reached from the internet.

Internet Gateway (IGW)

A horizontally-scaled, redundant, HA component attached to your VPC that enables communication between your VPC and the internet. Free. Without an IGW, your VPC has no internet connectivity at all. Only one IGW per VPC.

NAT Gateway

Allows instances in private subnets to initiate outbound connections to the internet (for software updates, API calls, etc.) but prevents the internet from initiating connections TO those instances. Deployed in a public subnet, charges per hour + data processed.

Route Tables

Every subnet has a route table that defines where traffic goes. A public subnet's route table has an entry: 0.0.0.0/0 → igw-xxxxx (default route to internet via IGW). A private subnet's route table: 0.0.0.0/0 → nat-xxxxx (outbound only via NAT).

Security Groups

Virtual firewalls at the instance (EC2) level. Stateful: if you allow inbound on port 80, the response automatically comes back out without needing an outbound rule. Default: deny all inbound, allow all outbound.

Network ACLs (NACLs)

Firewall at the subnet level. Stateless: you must define both inbound AND outbound rules explicitly. Rules evaluated in number order (lowest first). An explicit DENY stops evaluation. Less commonly tweaked than Security Groups.

What is a Load Balancer?

A load balancer distributes incoming traffic across multiple backend servers. It's the entry point users hit — they don't talk to individual servers directly. This enables high availability (if one server dies, traffic goes elsewhere), horizontal scaling, and no single point of failure.

Layer 4 vs Layer 7 Load Balancing

Load Balancing Algorithms

Health Checks

Load balancers continuously ping backend servers (e.g., HTTP GET /health every 30s). If a server fails health check 3 times, the LB removes it from rotation. When it recovers and passes, it's added back. This is how HA works in practice.

The Problem CDNs Solve

Your origin server is in us-east-1. A user in Mumbai requests your 5MB homepage image. The packet travels ~14,000 km. High latency. With a CDN, that image is cached in an edge server in Mumbai — user gets it from there. Fast.

  WITHOUT CDN:                          WITH CDN (cache HIT):
  User (Mumbai) ─────────────────►     User (Mumbai) ──► Edge (Mumbai) ──► User
   14,000km to us-east-1                                  [cached!] ◄──┘
   Response: ~300ms latency                               Response: ~5ms latency

  FIRST REQUEST (cache MISS):
  User (Mumbai) ──► Edge (Mumbai) ──► Origin (us-east-1) ──► Edge caches it
                                       Response: ~300ms (one time)

  SUBSEQUENT REQUESTS (cache HIT, within TTL):
  User (Mumbai) ──► Edge (Mumbai) ──► Serve from cache → ~5ms ✓

Key CDN Concepts

• Origin: The source of truth — your actual server (S3 bucket, EC2, ALB).
• Edge Location: CDN's cache servers distributed globally.
• TTL (Time To Live): How long content is cached before being re-fetched from origin. Too long = stale content. Too short = defeats the purpose.
• Cache Invalidation: Manually expire cached content when you deploy new files. In CloudFront, you create an invalidation request.
• Origin Shield: Extra caching layer between edge locations and origin, reducing origin load. One central cache instead of 100s of edges hitting origin.

What to cache: Static assets (images, CSS, JS, videos). What NOT to cache: User-specific pages, API responses with sensitive data, frequently changing data (unless you manage TTL carefully).

Identity & Access Management (IAM) — Core Concepts

IAM answers: Who are you? What can you do? To what resources?

• Authentication: Proving who you are (password, MFA, API key)
• Authorization: What you're allowed to do once authenticated (policies)
• Principal: An entity that can make requests (user, role, service)
• Principle of Least Privilege: Grant only the permissions needed for the specific task. Not "give admin and let them figure it out."

Encryption

MFA — Multi-Factor Authentication

Something you know (password) + something you have (phone/hardware key). Even if your AWS root password is stolen, attacker can't login without your MFA device. Always enable MFA on root account and all IAM users with console access.

Zero Trust Model

Traditional model: "Trust everything inside the network perimeter." Zero Trust: "Trust nothing, verify everything." Even requests from inside the VPC are not automatically trusted — authenticate and authorize every request. Implemented via mutual TLS (mTLS), service meshes (Istio), and strict IAM policies.

What is IaC and Why Does It Matter?

IaC means defining your cloud infrastructure in code files (YAML, JSON, HCL) instead of clicking through the console. You check these files into Git, review them in PRs, run them through CI/CD. Infrastructure becomes reproducible, auditable, and versionable.

Key IaC Tools

Serverless

You write functions, the cloud runs them. No servers to provision, patch, or manage. You pay only when code runs (per invocation + per ms of execution). Serverless ≠ no servers — there ARE servers, you just don't manage them.

Key characteristics: Event-driven (triggered by HTTP, S3 upload, queue message, schedule). Scales to zero (no traffic = no cost). Scales to millions (auto-scale). Stateless (function runs fresh each time).

Containers

Containers package your app + all dependencies (libraries, config, runtime) into a portable unit. Unlike VMs, containers share the host OS kernel — much more lightweight. Docker is the de-facto container standard.

  Virtual Machines                    Containers
  ┌──────────────────────────┐        ┌──────────────────────────┐
  │ App A  │ App B  │ App C  │        │ App A  │ App B  │ App C  │
  │ Libs   │ Libs   │ Libs   │        │ Libs   │ Libs   │ Libs   │
  │ OS     │ OS     │ OS     │        ├────────────────────────── ┤
  ├────────┼────────┼────────┤        │     Container Runtime     │
  │      Hypervisor          │        │     (Docker/containerd)   │
  ├──────────────────────────┤        ├──────────────────────────┤
  │     Host OS              │        │     Host OS (ONE)        │
  ├──────────────────────────┤        ├──────────────────────────┤
  │     Hardware             │        │     Hardware             │
  └──────────────────────────┘        └──────────────────────────┘
  Each VM: 1-2GB RAM overhead         Each Container: ~50MB overhead
  Slow to start (minutes)             Starts in seconds

Container Orchestration

When you run 100s of containers, you need something to manage them: scheduling, health checks, service discovery, rolling updates, secret management. Kubernetes is the industry standard.

What is CI/CD?

Continuous Integration (CI): Every code commit is automatically built, tested, and validated. You catch bugs immediately — not 3 months later during a manual deployment.

Continuous Delivery (CD): After CI passes, the artifact (container, zip, AMI) is automatically deployed to staging. Deployment to production requires manual approval.

Continuous Deployment: Like CD but no manual approval — changes go straight to production automatically after tests pass. Used by companies doing 100s of deploys per day.

graph LR
    A[Developer Push] --> B[Source Repo]
    B --> C[CI: Build & Test]
    C --> D{Tests Pass?}
    D -- No --> E[Notify Dev, Stop]
    D -- Yes --> F[Create Artifact]
    F --> G[Deploy to Staging]
    G --> H[Integration Tests]
    H --> I{Approved?}
    I -- Manual Approve --> J[Deploy to Prod]
    I -- Auto Deploy --> J
    J --> K[Monitor & Alert]

Deployment Strategies

What is EC2?

EC2 is AWS's virtual machine service (IaaS). You rent a virtual server that runs on AWS hardware, choose the OS, configure storage and networking. You have full root/admin access. It's the foundation of most AWS architectures.

Key EC2 Components

Instance Types

EC2 instances come in families optimized for different workloads. The naming convention: [Family][Generation][Size] → e.g., m5.xlarge = General purpose, 5th gen, xlarge.

AMI — Amazon Machine Image

An AMI is a pre-configured template (OS + optional installed software) used to launch EC2 instances. Like a VM snapshot you can clone. AWS provides Amazon Linux, Ubuntu, RHEL, Windows images. You can create custom AMIs (e.g., "Amazon Linux + Nginx + your app pre-installed") for faster launches — called a "Golden AMI".

User Data

A bash script that runs once on first boot. Used to install packages, download code, configure services without baking them into an AMI. Passed at launch time:

#!/bin/bash
yum update -y
yum install -y nginx
systemctl start nginx
systemctl enable nginx

Key Pairs

RSA key pair for SSH access. AWS stores the public key; you keep the private key (.pem file). ssh -i my-key.pem ec2-user@<public-ip>. If you lose the private key, you can't SSH in anymore — AWS has no backup. Best practice: use SSM Session Manager instead of SSH (no key pair, no open port 22 needed, auditable).

Instance Metadata Service (IMDS)

From inside an EC2 instance, you can query http://169.254.169.254/latest/meta-data/ to get instance info: instance ID, public IP, IAM role credentials, AZ, etc. Critical for automation scripts running on EC2. IMDSv2 (more secure, requires token) is now required.

# Get instance ID from inside the instance
TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/instance-id

# Get IAM role temporary credentials
curl -H "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/meta-data/iam/security-credentials/MyRole

EC2 Pricing Models

Placement Groups

Controls how AWS places EC2 instances on physical hardware:

• Cluster: Pack instances close together in same AZ. Ultra-low latency network (~25Gbps). Use for: HPC, big data jobs needing fast node-to-node comms. Risk: AZ failure takes all down.
• Spread: Instances on different hardware. Reduces correlated hardware failure. Max 7 instances per AZ per group. Use for: small critical clusters of distinct VMs.
• Partition: Groups of instances in different partitions (separate racks). Good for large distributed systems (Kafka, Hadoop, Cassandra) where partial failures are tolerable.

Elastic IP (EIP)

A static public IPv4 address you can allocate and associate with an EC2 instance. When an EC2 stops/starts, its public IP changes — an EIP stays fixed. But: AWS charges for EIPs that are not attached to a running instance (to discourage hoarding). Best practice: use a load balancer with a stable DNS name instead of EIPs for production.

What is Lambda?

AWS Lambda lets you run code without provisioning any servers. You upload a function (zip or container), define what triggers it, and Lambda runs it on-demand. You're billed per invocation + per GB-second of memory used. No code running = zero cost.

Key Lambda Concepts

Triggers (Event Sources)

Lambda is event-driven. Something must trigger it:

Execution Environment

Lambda runs your code inside a micro-container (Firecracker VM). Your function gets:

• Memory: 128MB to 10GB. CPU scales proportionally with memory.
• Timeout: Max 15 minutes per invocation.
• /tmp storage: 512MB to 10GB ephemeral disk (lost after function ends).
• Ephemeral by design: Don't rely on state persisting between invocations.

Cold Start

When Lambda hasn't run recently, AWS needs to initialize the execution environment (download code, start runtime, run initialization code). This adds 200ms-2s latency. Subsequent "warm" invocations reuse the same container (~1ms overhead).

# Lambda handler (Python example)
import boto3

# Code HERE runs on every COLD start (container init)
s3_client = boto3.client('s3')  # Initialize once, reused on warm invocations

def handler(event, context):
    # Code HERE runs on EVERY invocation (warm or cold)
    bucket = event['bucket']
    key = event['key']
    response = s3_client.get_object(Bucket=bucket, Key=key)
    return {'statusCode': 200, 'body': response['Body'].read().decode()}

Layers

Lambda Layers are zip archives containing dependencies (libraries) that can be shared across multiple functions. Instead of bundling numpy in every ML Lambda, put it in a layer and reference it. Max 5 layers per function. Reduces deployment package size and enables sharing.

Concurrency

Lambda scales horizontally automatically. If 1000 events arrive simultaneously, Lambda spins up 1000 instances of your function. Default account limit: 1000 concurrent executions (soft limit, can increase). You can set Reserved Concurrency (cap a function to protect others) or Provisioned Concurrency (keep containers warm, eliminate cold starts, extra cost).

IAM Execution Role

Each Lambda function has an execution role — an IAM role Lambda assumes to make API calls. If your function needs to read from S3, the execution role must have s3:GetObject permission. Never put AWS credentials inside Lambda code — use the execution role.

AWS Container Ecosystem Overview

  Need containers on AWS?
          │
          ▼
  Kubernetes or AWS-native orchestration?
  ┌──────────────────┬──────────────────┐
  │  AWS-native      │  Kubernetes      │
  │  (ECS)          │  (EKS)           │
  └────────┬─────────┴────────┬─────────┘
           │                  │
  Where to run containers?    │
  ┌─────────────────────────────────────┐
  │                                     │
  EC2 (you manage nodes)    Fargate (serverless nodes)
  More control, cheaper     No node management, slightly pricier
  for stable workloads      great for variable/small workloads

ECS — Elastic Container Service

AWS's own container orchestration service. Not Kubernetes — AWS's proprietary system. Simpler to operate than EKS for pure AWS workloads.

• Task Definition: JSON/YAML file defining your container(s): image URI, CPU/memory, port mappings, env vars, logging, IAM role. Think of it like a Pod spec in Kubernetes.
• Task: A running instance of a Task Definition. Like a Pod.
• Service: Ensures a desired number of tasks are running. Handles health checks, restarts, load balancer integration, rolling deploys. Like a Deployment + Service in K8s.
• Cluster: Logical group of resources (EC2 instances or Fargate capacity) where tasks run.

# Example Task Definition (simplified JSON)
{
  "family": "my-web-app",
  "networkMode": "awsvpc",
  "containerDefinitions": [{
    "name": "web",
    "image": "123456789.dkr.ecr.ap-south-1.amazonaws.com/my-app:v1.2",
    "cpu": 256,
    "memory": 512,
    "portMappings": [{"containerPort": 8080, "protocol": "tcp"}],
    "environment": [{"name": "ENV", "value": "production"}],
    "logConfiguration": {
      "logDriver": "awslogs",
      "options": {"awslogs-group": "/ecs/my-web-app", "awslogs-region": "ap-south-1"}
    }
  }],
  "requiresCompatibilities": ["FARGATE"],
  "cpu": "256",
  "memory": "512"
}

EKS — Elastic Kubernetes Service

Managed Kubernetes. AWS runs and manages the Kubernetes control plane (API server, etcd). You manage the worker nodes (EC2 node groups) or use Fargate. Best when you need Kubernetes compatibility (standard K8s manifests, Helm charts, existing K8s tooling).

• Managed Node Groups: AWS creates/updates EC2 instances as worker nodes. You pick instance type, scaling policy.
• Fargate Profiles: Pods matching certain selectors run on Fargate (serverless).
• Add-ons: Managed plugins like CoreDNS, kube-proxy, VPC CNI, AWS Load Balancer Controller.

Fargate — Serverless Containers

Fargate is a compute engine for ECS and EKS where AWS manages the underlying EC2 instances. You just specify CPU/memory for your container — no node groups to manage, no EC2 to patch.

ECR — Elastic Container Registry

AWS's private Docker image registry. Like Docker Hub but private and integrated with IAM. Push images here, pull from ECS/EKS. ECR also scans images for security vulnerabilities. Free private repos (storage charged separately). You authenticate with: aws ecr get-login-password | docker login ...

What is S3?

S3 is AWS's object storage service — the most fundamental AWS service. Store any file (object) up to 5TB in size. Highly durable (99.999999999% — eleven 9s), highly available, globally accessible. Used for: static file hosting, backup, data lake, ML training data, CloudFront origin, application logs, artifacts.

Key S3 Concepts

Buckets & Objects

A bucket is a container (globally unique name). An object is the file + metadata stored in a bucket. Objects are addressed by a key (the "path"): s3://my-bucket/images/profile/user123.jpg. Despite looking like folders, S3 is flat — the "/" is just part of the key name. The "folders" you see in console are just a UI fiction (prefix grouping).

S3 Storage Classes

  FREQUENTLY ACCESSED ◄──────────────────────────────► RARELY ACCESSED
  HIGHEST COST                                           LOWEST COST

  S3 Standard     │ S3 Intelligent │ S3 Standard-IA │ S3 Glacier    │ S3 Glacier
                  │ Tiering        │                │ Instant       │ Deep Archive
                  │                │                │ Retrieval     │
  ----------------│----------------│----------------│---------------│-----------
  Any data        │ Unknown or     │ Backups,       │ Long-term     │ Long-term
  accessed        │ changing       │ disaster       │ backups, RA   │ archive, 7-10yr
  frequently      │ access pattern │ recovery       │ 1/quarter     │ retention
                  │ Auto-moves     │                │               │
  Retrieval: ms   │ between tiers  │ Retrieval: ms  │ Retrieval: ms │ Retrieval: 12hr
                  │                │ Min 30 days    │ Min 90 days   │ Min 180 days

Versioning

Enable versioning on a bucket to keep multiple versions of every object. Protects against accidental deletes and overwrites. When you delete an object, S3 adds a "delete marker" — the old version still exists. You can restore it. Once enabled, versioning can be suspended but NOT fully disabled. Versions accumulate cost — use Lifecycle rules to clean old versions.

Lifecycle Policies

Automate object transitions between storage classes or expiration:

# Example: Move to IA after 30 days, Glacier after 90 days, delete after 365 days
{
  "Rules": [{
    "Status": "Enabled",
    "Filter": {"Prefix": "logs/"},
    "Transitions": [
      {"Days": 30, "StorageClass": "STANDARD_IA"},
      {"Days": 90, "StorageClass": "GLACIER"}
    ],
    "Expiration": {"Days": 365}
  }]
}

Bucket Policies vs ACLs vs IAM

# Bucket policy: enforce HTTPS only
{
  "Statement": [{
    "Effect": "Deny",
    "Principal": "*",
    "Action": "s3:*",
    "Resource": ["arn:aws:s3:::my-bucket", "arn:aws:s3:::my-bucket/*"],
    "Condition": {"Bool": {"aws:SecureTransport": "false"}}
  }]
}

Pre-signed URLs

Temporarily grant access to a private object without making it public. A pre-signed URL is signed with your credentials and has an expiry. Your backend generates it and sends to a user — they can download the private file for the next 15 minutes. Used for: file downloads in apps, direct-to-S3 uploads from browser (bypasses your server).

# Generate pre-signed URL (Python boto3)
url = s3_client.generate_presigned_url(
    'get_object',
    Params={'Bucket': 'my-bucket', 'Key': 'report.pdf'},
    ExpiresIn=900  # 15 minutes
)
# Now share this URL — expires in 15 minutes automatically

S3 Replication

• Cross-Region Replication (CRR): Replicate objects to a bucket in another region. For DR, compliance (EU data must also be in EU-West), lower latency for users in different regions.
• Same-Region Replication (SRR): Replicate within same region to another bucket. For log aggregation, test-prod separation, compliance copies.

Both require versioning enabled. Replication is asynchronous (not instant). Does NOT replicate existing objects — only new uploads after replication is configured.

What is EBS?

EBS provides block storage volumes for EC2 instances — like a virtual hard drive. Unlike S3 (object storage accessible over HTTP), EBS appears as a raw block device to the OS (like /dev/xvda). You format it with a filesystem (ext4, xfs) and mount it. EBS volumes persist independently of EC2 instance lifecycle — you can stop/terminate an instance and the volume remains.

EBS Volume Types

EBS Snapshots

Point-in-time backup of an EBS volume to S3 (you don't see this S3 bucket — it's AWS-managed). Snapshots are incremental: first snapshot copies everything, subsequent snapshots only store changed blocks. You can create volumes from snapshots in any AZ (cross-AZ copy). You can copy snapshots across regions (for DR). Cost: per GB-month of data stored in snapshot.

# Create snapshot via AWS CLI
aws ec2 create-snapshot --volume-id vol-0abc123 --description "Pre-deploy backup"

# Create volume from snapshot in different AZ (useful for migrating data)
aws ec2 create-volume --snapshot-id snap-0xyz789 --availability-zone ap-south-1b --volume-type gp3

EBS vs Instance Store

What is EFS?

EFS is a managed NFS (Network File System) that can be mounted by multiple EC2 instances simultaneously across multiple AZs. Unlike EBS (one instance at a time), EFS is shared storage. Grows and shrinks automatically — pay only for what you use. No capacity planning needed.

Key EFS Features

• Multi-AZ by default: Data stored redundantly across multiple AZs. Highly durable and available.
• Shared mount: 100s or 1000s of EC2 instances can mount the same EFS simultaneously. Read AND write from multiple instances.
• Performance modes: General Purpose (low latency) | Max I/O (high throughput, slightly higher latency for massively parallel workloads).
• Throughput modes: Elastic (auto-scales throughput with load), Bursting (throughput proportional to size), Provisioned (fix throughput independently).
• Storage tiers: Standard (active) → Infrequent Access (EFS IA, cheaper) via lifecycle policies.

# Mount EFS on EC2 (Amazon Linux)
sudo yum install -y amazon-efs-utils
sudo mkdir /mnt/efs
sudo mount -t efs fs-0abc12345:/ /mnt/efs
# Or add to /etc/fstab for persistent mount:
echo "fs-0abc12345:/ /mnt/efs efs defaults,_netdev 0 0" | sudo tee -a /etc/fstab

VPC Advanced Concepts

VPC Peering

Connect two VPCs so resources can communicate using private IPs, as if they were in the same network. Can peer across accounts and regions. Non-transitive: if VPC-A peers with VPC-B and VPC-B peers with VPC-C, VPC-A cannot talk to VPC-C through VPC-B. You'd need a direct peering or Transit Gateway.

VPC-A ←──peering──► VPC-B ←──peering──► VPC-C
EC2 in VPC-A → VPC-B: ✓ (direct peering)
EC2 in VPC-A → VPC-C: ✗ (non-transitive — no direct peering)

Transit Gateway (TGW)

A central hub that connects multiple VPCs and on-prem networks. Solves the peering mesh problem: instead of N×(N-1)/2 peering connections for N VPCs, you connect each VPC to one TGW. TGW is transitive. Think of it as a cloud router. Supports: inter-VPC, VPC-to-on-prem (via VPN/Direct Connect), inter-region peering via TGW.

  WITHOUT TGW (5 VPCs, 10 peerings needed):     WITH TGW (5 VPCs, 5 attachments):
  VPC-A ──── VPC-B                               VPC-A ──┐
  VPC-A ──── VPC-C                               VPC-B ──┤
  VPC-A ──── VPC-D                               VPC-C ──┼── Transit Gateway ── On-Prem
  VPC-A ──── VPC-E                               VPC-D ──┤
  VPC-B ──── VPC-C ... etc.                      VPC-E ──┘
  Non-transitive, complex route tables.          Central hub, transitive, one TGW.

VPC Endpoints

Access AWS services (S3, DynamoDB, SSM, etc.) from within your VPC without traffic leaving through the internet. Traffic stays on AWS's private network. More secure and often faster.

VPC Flow Logs

Capture information about IP traffic going to/from network interfaces in your VPC. Sent to CloudWatch Logs or S3. Not real-time packet capture (use Traffic Mirroring for that) — just metadata: source/dest IP, ports, protocol, bytes, action (ACCEPT/REJECT).

# Example flow log entry:
# version account-id interface-id srcaddr dstaddr srcport dstport protocol packets bytes start end action log-status
2 123456789 eni-0abc 10.0.1.10 10.0.2.20 45678 443 6 20 4000 1620000000 1620000060 ACCEPT OK
2 123456789 eni-0abc 1.2.3.4   10.0.1.10 12345 22  6  5  300  1620000010 1620000070 REJECT OK
# → Blocked SSH attempt from 1.2.3.4 to our server (Security Group or NACL blocked it)

NAT Gateway Details

• Deployed in a public subnet with an Elastic IP
• Private instances route 0.0.0.0/0 to the NAT GW → it translates their private IP to its public EIP → sends to internet
• Cost: ~$0.045/hour + $0.045/GB data processed. In high-traffic envs, this adds up.
• For high-availability: deploy a NAT Gateway in EACH AZ. Don't share one NAT GW across AZs (AZ failure kills outbound internet for other AZs).
• NAT Instance vs NAT Gateway: NAT Instance is a self-managed EC2 instance doing NAT. Cheaper, more configurable, but you manage patching, HA. NAT Gateway is managed, scales automatically, no maintenance. Use NAT Gateway unless you have a specific reason for NAT Instance.

What is Route 53?

AWS's managed DNS service. Also handles domain registration, health checks, and sophisticated traffic routing policies. Named after port 53 (DNS port). Has a 100% availability SLA — the only AWS service with this guarantee.

Hosted Zones

A hosted zone is a container for DNS records for a domain. Public hosted zone: records accessible over the internet (your website). Private hosted zone: records for resources within your VPC (internal service discovery — db.internal → 10.0.3.5).

Record Types

Routing Policies

Health Checks

Route 53 health checkers (globally distributed) ping your endpoint every 10/30 seconds. If 18%+ of checkers fail → endpoint marked unhealthy → Failover routing activates. You can health-check: HTTP/HTTPS/TCP endpoints, CloudWatch alarms, or calculated health checks (composite of multiple checks).

What is CloudFront?

AWS's global CDN with 600+ edge locations. Accelerates delivery of static and dynamic content by caching at the edge. Also provides: DDoS protection (Shield Standard free), HTTPS termination, compression, WAF integration, Lambda@Edge for programmable edge logic.

Key CloudFront Concepts

Distribution

A CloudFront configuration object. You create one distribution per app/site. A distribution has a CloudFront domain (d1abc23efg.cloudfront.net) which you CNAME your domain to. Has one or more origins and one or more cache behaviors.

Origins

Where CloudFront fetches content when it's not cached (cache miss). Can be: S3 bucket, ALB, EC2, API Gateway, or any HTTP server. A distribution can have multiple origins.

Cache Behaviors

Rules that define how CloudFront handles requests matching a URL path pattern. Different paths can route to different origins with different cache settings:

  https://example.com
  │
  ├── /api/*  ─────────────────────────► ALB → EC2 (no caching, dynamic)
  │   Cache: TTL=0, forward all headers │
  │
  ├── /static/* ────────────────────────► S3 Bucket (cached, long TTL)
  │   Cache: TTL=86400 (1 day)          │
  │
  └── /* (Default) ─────────────────────► S3 (index.html, SPA)
      Cache: TTL=300 (5 min)            │

OAC — Origin Access Control

Allows CloudFront to access a private S3 bucket on your behalf. Users access content via CloudFront URL only — the S3 bucket can block all direct access. Prevents bucket hotlinking, enforces CloudFront caching. OAC is the modern replacement for OAI (Origin Access Identity).

Lambda@Edge & CloudFront Functions

• CloudFront Functions: Ultra-lightweight JS functions running at the edge for request/response manipulation. Sub-ms latency. Free tier available. Good for: URL rewrites/redirects, add security headers, A/B testing at edge.
• Lambda@Edge: Full Lambda functions deployed globally to CloudFront PoPs. More powerful (Node.js, Python), slightly higher latency. Good for: authentication at edge, dynamic content generation, API calls at edge.

// CloudFront Function example: add security headers to all responses
function handler(event) {
    var response = event.response;
    var headers = response.headers;
    headers['strict-transport-security'] = {value: 'max-age=63072000; includeSubdomains; preload'};
    headers['x-content-type-options'] = {value: 'nosniff'};
    headers['x-frame-options'] = {value: 'DENY'};
    return response;
}

Application Load Balancer (ALB) — Layer 7

ALB operates at HTTP/HTTPS layer. It understands your request content and can make intelligent routing decisions. Every request is terminated at the ALB (it opens a new connection to the backend). Essential for microservices architectures.

Key ALB Components

• Listener: Waits on a port (80 or 443). Defines rules to route requests.
• Rules: IF (conditions match) THEN (action). Conditions: path, hostname, headers, query strings, source IP, HTTP method. Actions: forward, redirect, return fixed response.
• Target Groups: Collection of targets (EC2 instances, IP addresses, Lambda functions, containers). Each TG has health check configuration.

  Client HTTP Request
         │
         ▼
  ┌─────────────────┐
  │  ALB Listener   │ :443 (HTTPS)
  │  ─────────────  │
  │  Rule 1:         │ /users/* ────────► Target Group A (User Service)
  │  Rule 2:         │ /orders/* ───────► Target Group B (Order Service)
  │  Rule 3:         │ /api/* (host:api) ► Target Group C (API backend)
  │  Default:        │ /* ──────────────► Target Group D (Frontend SPA)
  └─────────────────┘

  Each Target Group:
  ┌───────────────────────────────────────────────────────┐
  │  EC2: i-001 (healthy ✓)  i-002 (healthy ✓)  i-003 ✗  │
  │  Health check: GET /health → 200 OK every 30s         │
  └───────────────────────────────────────────────────────┘

ALB Features

• HTTPS Termination: ALB decrypts HTTPS and talks to backend via HTTP. Offloads SSL processing from backends.
• Sticky Sessions: Route same user to same backend target using a cookie. Use with caution (undermines horizontal scaling).
• Weighted Target Groups: Send 90% to v2 TG, 10% to v3 TG. Canary deploys without DNS changes.
• Authentication: Native OpenID Connect/Cognito authentication. Reject unauthenticated requests before they hit your app.
• Access Logs: Log every request to S3. Useful for traffic analysis, debugging, compliance.

Network Load Balancer (NLB) — Layer 4

NLB operates at TCP/UDP layer. Doesn't inspect packet contents. Handles millions of requests per second with ultra-low latency (<1ms). Has static IP addresses (useful for whitelisting). Supports TLS termination at L4.

AWS Site-to-Site VPN

Encrypted connection between your on-premises network and your AWS VPC over the public internet. Uses IPsec. Two tunnels per VPN connection (for redundancy). Managed on AWS side by Virtual Private Gateway (VGW) or Transit Gateway. Bandwidth: ~1.25 Gbps max per tunnel, varies with internet conditions.

# VPN Connection components:
On-Prem Router/Firewall (Customer Gateway) ──IPsec Tunnel──► Virtual Private Gateway (VGW)
                                                                        │
                                                               Route table entry in VPC
                                                               10.0.0.0/8 → vgw-xxxxx

AWS Direct Connect (DX)

A dedicated physical private network connection from your datacenter to AWS. NOT over the internet — a private fiber link through an AWS Direct Connect partner (colocation facility). More expensive to set up but: consistent bandwidth, lower latency, more predictable, can carry more traffic more cheaply (data transfer pricing is lower on DX vs internet).

Core IAM Entities

IAM is a free, global service — it's not region-specific. IAM controls who can do what on which AWS resources. Everything in AWS is an API call, and every call goes through IAM for authorization.

IAM Policy Structure

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowS3ReadOnSpecificBucket",   // Optional statement ID
      "Effect": "Allow",                       // "Allow" or "Deny"
      "Action": [                              // What actions are allowed
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [                            // On which resources
        "arn:aws:s3:::my-company-bucket",      // The bucket itself (for ListBucket)
        "arn:aws:s3:::my-company-bucket/*"     // Objects within the bucket
      ],
      "Condition": {                           // Optional: extra conditions
        "StringEquals": {
          "s3:prefix": "reports/"             // Only objects under "reports/" prefix
        }
      }
    },
    {
      "Effect": "Deny",
      "Action": "s3:DeleteObject",
      "Resource": "arn:aws:s3:::my-company-bucket/*"
    }
  ]
}

IAM Policy Types

Policy Evaluation Logic

  Request arrives → Check for explicit DENY in any policy
                           │
                    Yes: DENY ✗ (Deny wins, always)
                           │
                    No: Check if SCP allows (Organizations)
                           │
                    No: DENY ✗
                           │
                    Yes: Check for explicit ALLOW
                           │
                    No: Implicit DENY ✗ (default deny)
                           │
                    Yes: Check Permission Boundary
                           │
                    No: DENY ✗
                           │
                    Yes: ALLOW ✓

  Rule: EXPLICIT DENY always wins. Default is DENY.
  You must explicitly ALLOW everything you want permitted.

IAM Roles — The Key Pattern

Instead of creating a user for your EC2 instance and storing access keys on the server (dangerous — keys can leak), you attach an IAM Role to EC2. EC2 automatically gets temporary credentials via IMDS. The credentials rotate every hour automatically. Lambda, ECS tasks, and other services all work the same way.

# BAD: Access keys hardcoded or in environment (never do this)
export AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
export AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

# GOOD: Use IAM Role attached to the EC2/Lambda/ECS task
# boto3 automatically fetches temp credentials from IMDS
import boto3
s3 = boto3.client('s3')  # No credentials needed — role creds used automatically
s3.get_object(Bucket='my-bucket', Key='file.txt')

Cross-Account Access with Roles

A role in Account B can be assumed by Account A's resources. This is how centralized tooling (one DevOps account managing multiple app accounts) works. The trust policy on the role in Account B says "allow Account A's role X to assume me."

# Trust Policy on Role in Account B (the target role)
{
  "Statement": [{
    "Effect": "Allow",
    "Principal": {
      "AWS": "arn:aws:iam::111111111111:role/DeployRole"  // Account A's role
    },
    "Action": "sts:AssumeRole"
  }]
}

# In Account A, assume the role:
aws sts assume-role \
  --role-arn "arn:aws:iam::222222222222:role/DeployTargetRole" \
  --role-session-name "deploy-session-$(date +%s)"

MFA (Multi-Factor Authentication)

• Virtual MFA: Authenticator app (Google Authenticator, Authy)
• Hardware MFA: Physical TOTP device or FIDO2 security key (YubiKey)
• Always enable MFA on root account — root has unlimited power and can't be restricted by SCPs
• You can enforce MFA for specific actions via policy condition: "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}

AWS KMS — Key Management Service

KMS is a managed service for creating and controlling encryption keys. It's the central key vault for all AWS encryption. When you "enable encryption" in S3, EBS, RDS — they're using KMS keys under the hood.

Key Types

Envelope Encryption

KMS doesn't encrypt your 5GB file directly (KMS keys stay in KMS — data never leaves). Instead: KMS generates a Data Encryption Key (DEK). Your code uses the DEK to encrypt the actual data. The DEK itself is encrypted with a KMS key (the "master key"). You store the encrypted DEK alongside the encrypted data. To decrypt: call KMS to decrypt the DEK, then use the DEK to decrypt the data. The master key never leaves KMS.

AWS Secrets Manager

Centralized, encrypted storage for secrets: database passwords, API keys, OAuth tokens. Auto-rotates secrets (can trigger a Lambda to rotate passwords in RDS). Applications retrieve secrets at runtime via API — no hardcoded passwords in code.

# Retrieve secret at runtime (Python)
import boto3, json
client = boto3.client('secretsmanager', region_name='ap-south-1')
secret = client.get_secret_value(SecretId='prod/myapp/db-password')
db_creds = json.loads(secret['SecretString'])
db_host = db_creds['host']
db_pass = db_creds['password']

# Application auto-rotates: RDS password changed every 30 days
# Lambda triggered by Secrets Manager updates RDS user password automatically

Secrets Manager vs SSM Parameter Store

AWS WAF — Web Application Firewall

WAF protects your web apps from common exploits at the application layer (L7). Works with CloudFront, ALB, API Gateway, AppSync. You define rules that filter HTTP requests.

Built-in rule groups (AWS Managed Rules): SQL injection protection, XSS protection, known bad IPs, AWS IP reputation lists. You can also write custom rules: "Block all requests where URI contains ../" or "Rate limit to 1000 req/5min per IP."

AWS Shield

Amazon GuardDuty

AI-powered threat detection service that continuously monitors your AWS account for malicious activity and unusual behavior. Analyzes: VPC Flow Logs, DNS logs, CloudTrail events, S3 access logs, EKS audit logs. Detects: compromised EC2 instances communicating with known bad IPs, unusual API calls, credential theft, S3 data exfiltration patterns.

AWS Security Hub

Central security dashboard aggregating findings from GuardDuty, Inspector, Macie, Firewall Manager, and third-party tools. Runs automated compliance checks against CIS AWS Foundations, PCI-DSS, and other standards. Gives you a security score and prioritized findings list.

Other Key Security Services

What is RDS?

RDS is a managed relational database service. AWS handles: OS patching, DB engine upgrades (with your approval), automated backups, replication, failover. You just connect and query. Supported engines: MySQL, PostgreSQL, MariaDB, Oracle, Microsoft SQL Server and Amazon Aurora (custom AWS engine).

Key RDS Concepts

Multi-AZ Deployment

The most important RDS HA feature. When enabled, AWS automatically maintains a synchronous standby replica in a different AZ. If primary fails, RDS automatically fails over to standby. Failover takes 60-120 seconds (DNS update). The standby is NOT accessible for reads — it's purely for failover. Separate from Read Replicas.

  MULTI-AZ (High Availability):           READ REPLICAS (Scalability):
  ┌──────────────────────────────┐        ┌──────────────────────────────┐
  │ AZ-1a: Primary RDS  ──sync──►│        │ Primary ──async──► Replica 1 │
  │         Read+Write   ◄failover│        │  (R+W)  ──async──► Replica 2 │
  │                              │        │         ──async──► Replica 3 │
  │ AZ-1b: Standby RDS           │        │                              │
  │         (NOT accessible)     │        │ Replicas: READ ONLY          │
  └──────────────────────────────┘        │ Can be in different region!  │
  For: automatic failover / HA            └──────────────────────────────┘
                                          For: scale out reads, reports,
                                          analytics, DR (promote to master)

Read Replicas

Asynchronous copies of your primary DB, used to offload read traffic. Up to 15 read replicas for Aurora, 5 for other engines. Can be in a different region (cross-region read replicas for DR). In disaster, promote a read replica to standalone DB — becomes the new primary.

Automated Backups

• Daily automated backup during your maintenance window (entire DB + transaction logs)
• Retained for 1-35 days (default 7). After that, deleted automatically.
• Point-in-time recovery: restore to any second within the backup retention period
• Manual snapshots: you control them, persist indefinitely until you delete them

RDS Proxy

A fully managed, highly available database proxy that sits between your app and RDS. Why use it? Lambda functions opening thousands of connections overwhelm RDS (too many connections). RDS Proxy pools and reuses connections — Lambda connects to Proxy, Proxy maintains a small pool to RDS. Also speeds up failover: clients connect to Proxy endpoint which auto-routes to healthy instance.

Storage Auto Scaling

Enable and set a maximum storage limit. If your DB is about to run out of disk space, RDS automatically scales up storage without downtime. You can never shrink it back (only grow). Set a high maximum and don't worry about disk again.

Amazon Aurora

AWS's custom-built cloud-native relational DB. MySQL and PostgreSQL compatible — your app code doesn't change. But it's re-engineered from scratch for cloud performance and resilience.

Aurora Serverless v2

Aurora that scales capacity in fine-grained increments (in 0.5 ACU steps from 0.5 to 256 ACUs) based on actual demand, in seconds. No pre-provisioning. Pay per second of actual ACU usage. Perfect for: unpredictable workloads, dev/test, multi-tenant SaaS with variable tenant load.

What is DynamoDB?

DynamoDB is AWS's fully managed NoSQL key-value and document database. No servers, no OS, no capacity planning. Single-digit millisecond performance at any scale. Used by Amazon itself for their shopping cart, sessions, order management. Built for internet-scale applications.

Core Concepts

Tables, Items, Attributes

DynamoDB is schemaless (except for keys). A Table holds Items (like rows), each with Attributes (like columns). No fixed schema — different items can have different attributes. Only the primary key is required.

Primary Key Types

Read Capacity Units (RCU) and Write Capacity Units (WCU)

DynamoDB bills on throughput. 1 RCU = 1 strongly consistent read (or 2 eventually consistent reads) of up to 4KB/second. 1 WCU = 1 write of up to 1KB/second. You either provision RCU/WCU (predictable, cheaper) or use On-Demand mode (pay per request, no planning, costlier per request but no idle waste).

Global Secondary Indexes (GSI)

Query your DynamoDB table on a different attribute. If your table's partition key is userId, but you need to query "all users who signed up on date X" — create a GSI with signupDate as partition key. GSIs have their own RCU/WCU separate from the main table.

DynamoDB Streams

A time-ordered stream of item-level changes (inserts, updates, deletes) in a DynamoDB table. Retained for 24 hours. Trigger Lambda functions on changes — powerful for: replication, cache invalidation, event sourcing, audit logs.

DynamoDB Accelerator (DAX)

In-memory cache for DynamoDB. API-compatible — swap your DynamoDB client for a DAX client, same code. Reduces read latency from single-digit ms to microseconds. Handles millions of reads per second. Use for: high-read, cost-sensitive workloads (DAX reads are cheaper than DynamoDB reads at high volume).

Global Tables

Multi-region, multi-active DynamoDB. Write to any region, DynamoDB replicates to others within seconds. Last-writer-wins conflict resolution. Perfect for: global apps needing local read/write latency everywhere, multi-region active-active architecture.

What is ElastiCache?

Managed in-memory caching service. Two engines: Redis and Memcached. Dramatically reduces database load and latency by serving frequent reads from memory (microseconds) instead of disk (milliseconds).

Redis vs Memcached on ElastiCache

Common Caching Patterns

# Lazy Loading (Cache-Aside) — most common pattern
def get_user(user_id):
    # Try cache first
    cached = redis.get(f"user:{user_id}")
    if cached:
        return json.loads(cached)  # Cache HIT

    # Cache MISS — query database
    user = db.query("SELECT * FROM users WHERE id = ?", user_id)

    # Store in cache with TTL (expiry)
    redis.setex(f"user:{user_id}", 3600, json.dumps(user))  # Cache 1 hour

    return user

# Write-Through — write to cache AND DB simultaneously
def update_user(user_id, data):
    db.update("UPDATE users SET ... WHERE id = ?", user_id, data)
    redis.setex(f"user:{user_id}", 3600, json.dumps(data))  # Always fresh

What is CloudWatch?

CloudWatch is AWS's unified observability platform. It collects metrics, logs, traces, and events from AWS services and your applications. Like a central nervous system for your AWS environment. Three pillars: Metrics (what's happening), Logs (what happened), Alarms (alert when something's wrong).

CloudWatch Metrics

Numeric data points over time. AWS services automatically push metrics: EC2 CPU%, RDS connections, ALB request count, Lambda errors. You can publish custom metrics from your application code.

CloudWatch Logs

Centralized log storage and analysis. Logs are organized in Log Groups (one per app/service), which contain Log Streams (one per instance/invocation). Lambda, ECS, and other services push logs automatically. EC2 needs the CloudWatch Agent installed to push logs.

# CloudWatch Agent config (simplified) — push /var/log/nginx/access.log
{
  "logs": {
    "logs_collected": {
      "files": {
        "collect_list": [{
          "file_path": "/var/log/nginx/access.log",
          "log_group_name": "/ec2/nginx/access",
          "log_stream_name": "{instance_id}",
          "timestamp_format": "%d/%b/%Y:%H:%M:%S %z"
        }]
      }
    }
  }
}

CloudWatch Logs Insights

Query language for analyzing logs. Like SQL for your logs. Very useful for debugging:

# Find all Lambda errors in the last hour
fields @timestamp, @message
| filter @message like /ERROR/
| sort @timestamp desc
| limit 50

# Calculate average response time from ALB access logs
fields @timestamp, targetProcessingTime
| stats avg(targetProcessingTime) as avgTime, count() as requests
| sort avgTime desc

CloudWatch Alarms

Trigger actions when a metric crosses a threshold. States: OK (metric within threshold), ALARM (metric breached threshold), INSUFFICIENT_DATA (not enough data yet).

Actions on ALARM: SNS notification (email/SMS), Auto Scaling (add/remove instances), EC2 action (stop/reboot/recover instance), Systems Manager action.

# Create alarm via CLI: alert if EC2 CPU > 80% for 2 consecutive 5-min periods
aws cloudwatch put-metric-alarm \
  --alarm-name "High-CPU-ec2-web-01" \
  --alarm-description "CPU usage too high" \
  --metric-name CPUUtilization \
  --namespace AWS/EC2 \
  --statistic Average \
  --dimensions Name=InstanceId,Value=i-0abc12345 \
  --period 300 \
  --evaluation-periods 2 \
  --threshold 80 \
  --comparison-operator GreaterThanThreshold \
  --alarm-actions "arn:aws:sns:ap-south-1:123456789:ops-alerts"

CloudWatch Dashboards

Custom dashboards combining metrics from multiple services. Create a single pane view: EC2 CPU + RDS connections + ALB latency + Lambda errors + SQS queue depth. Share with team. Use as your operations wall display.

CloudWatch Events / EventBridge

Rule-based event routing. React to AWS service events or scheduled triggers. EventBridge is the evolution of CloudWatch Events — more powerful, supports custom event buses, third-party SaaS events, schema registry.

# EventBridge rule: trigger Lambda every day at 8 AM UTC (cron)
{
  "source": "aws.events",
  "schedule": "cron(0 8 * * ? *)",
  "targets": [{"Id": "DailyReport", "Arn": "arn:aws:lambda:...daily-report"}]
}

# EventBridge rule: trigger when EC2 instance state changes to "stopped"
{
  "source": ["aws.ec2"],
  "detail-type": ["EC2 Instance State-change Notification"],
  "detail": {"state": ["stopped"]}
}

AWS CloudTrail

Records every AWS API call made in your account — via Console, CLI, SDK, or other AWS services. Who did what, when, from where. The audit trail for your entire AWS account. Enabled automatically but events only kept 90 days in CloudTrail console; create a Trail to send to S3 for long-term retention (required for compliance).

Trail Types

• Management Events: Control plane operations — CreateBucket, LaunchEC2, DeleteUser. Enabled by default. Free for first copy.
• Data Events: Data plane operations — S3 object reads/writes (PutObject, GetObject), Lambda invocations. High volume, extra cost. Enable for critical resources.
• Insight Events: Detect unusual API activity (e.g., sudden spike in IAM calls). Extra cost but powerful anomaly detection.

# Example CloudTrail event — someone deleted an S3 bucket
{
  "eventTime": "2024-01-15T14:23:01Z",
  "eventName": "DeleteBucket",
  "userIdentity": {"type": "IAMUser", "userName": "john.doe"},
  "sourceIPAddress": "203.0.113.45",
  "requestParameters": {"bucketName": "prod-customer-data-backup"},
  "eventSource": "s3.amazonaws.com"
}
# → John deleted the production backup bucket from IP 203.0.113.45 at 2:23 PM UTC

AWS X-Ray — Distributed Tracing

X-Ray helps debug and analyze distributed applications (microservices). When a user request flows through API Gateway → Lambda → DynamoDB → SQS → another Lambda — X-Ray traces the entire journey, showing where latency comes from and where errors occur.

  User Request (Total: 450ms)
  │
  ├── API Gateway: 5ms
  │
  ├── Lambda: process-order (380ms total)
  │   ├── Init (cold start): 150ms   ← performance problem!
  │   ├── DynamoDB PutItem: 12ms
  │   ├── SQS SendMessage: 8ms
  │   └── Execution: 210ms
  │
  └── Response: 65ms

  X-Ray shows: Cold start is causing 33% of total latency.
  Fix: Enable Provisioned Concurrency on this Lambda.

To use X-Ray: add the X-Ray SDK to your app code, or enable active tracing on Lambda/API Gateway (no code changes). X-Ray automatically generates a service map showing all components and their interconnections.

What is CloudFormation?

AWS's native IaC service. Define your entire infrastructure in YAML or JSON templates. CloudFormation handles creation, update, and deletion of resources in the right order. Free — you only pay for the resources it creates.

CloudFormation Template Structure

AWSTemplateFormatVersion: '2010-09-09'
Description: 'Web Application Stack'

Parameters:  # User inputs at deploy time
  EnvironmentName:
    Type: String
    Default: production
    AllowedValues: [development, staging, production]
  InstanceType:
    Type: String
    Default: t3.micro

Mappings:  # Lookup tables (e.g., AMI IDs per region)
  RegionAMIMap:
    ap-south-1:
      AMI: ami-0abc12345
    us-east-1:
      AMI: ami-0xyz67890

Conditions:  # Conditional resource creation
  IsProd: !Equals [!Ref EnvironmentName, production]

Resources:  # Actual AWS resources (required)
  MyEC2Instance:
    Type: AWS::EC2::Instance
    Properties:
      InstanceType: !Ref InstanceType
      ImageId: !FindInMap [RegionAMIMap, !Ref AWS::Region, AMI]
      SecurityGroupIds: [!Ref WebSecurityGroup]
      Tags:
        - Key: Environment
          Value: !Ref EnvironmentName

  WebSecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: Allow HTTP/HTTPS
      SecurityGroupIngress:
        - IpProtocol: tcp
          FromPort: 80
          ToPort: 80
          CidrIp: 0.0.0.0/0

  # Only create this in production
  ElasticIP:
    Type: AWS::EC2::EIP
    Condition: IsProd
    Properties:
      InstanceId: !Ref MyEC2Instance

Outputs:  # Values returned after stack creation
  InstancePublicIP:
    Value: !GetAtt MyEC2Instance.PublicIp
    Export:
      Name: !Sub "${AWS::StackName}-PublicIP"

Key CloudFormation Concepts

Stacks & Stack Sets

A Stack is a deployed instance of a template (all the resources it creates). You update a stack by updating the template and running a changeset. StackSets deploy one template across multiple accounts and regions simultaneously — essential for large organizations.

Changesets

Preview what changes CloudFormation will make before actually making them. Shows: which resources will be added, modified, or deleted. Always review changesets before applying — especially check for resource replacements (which cause downtime).

Drift Detection

Checks if actual resource state differs from what CloudFormation expects. If someone manually changed a Security Group that CloudFormation manages, drift detection finds it. Important for compliance and ensuring IaC is the source of truth.

!Ref and !GetAtt

Built-in functions for referencing other resources within the template. !Ref MyBucket returns the bucket name. !GetAtt MyBucket.Arn returns the bucket ARN. !Sub "arn:aws:s3:::${MyBucket}/*" substitutes variable into string.

CloudFormation vs Terraform (Key Differences)

AWS CI/CD Toolchain Overview

  ┌────────────────────────────────────────────────────────────────────┐
  │                        AWS CodePipeline                           │
  ├────────────┬───────────────┬──────────────┬────────────────────────┤
  │  SOURCE    │    BUILD      │    TEST       │       DEPLOY           │
  │            │               │              │                        │
  │ CodeCommit │  CodeBuild    │  CodeBuild   │  CodeDeploy → EC2      │
  │  GitHub    │  (compile,    │  (unit tests,│  CodeDeploy → Lambda   │
  │  Bitbucket │   lint,       │   integration│  ECS (Blue/Green)      │
  │  S3        │   docker build│   tests)     │  CloudFormation        │
  │            │   push to ECR)│              │  Beanstalk             │
  └────────────┴───────────────┴──────────────┴────────────────────────┘
  Each stage has actions. Failure at any stage stops the pipeline.

CodeBuild — Build Service

Managed build server. Runs your build commands in a Docker container, compiles code, runs tests, creates artifacts. Defined in a buildspec.yml file at the root of your repo.

# buildspec.yml — defines build steps
version: 0.2
phases:
  install:
    runtime-versions:
      python: 3.11
    commands:
      - pip install -r requirements.txt

  pre_build:
    commands:
      - echo Logging into ECR...
      - aws ecr get-login-password | docker login --username AWS --password-stdin $ECR_URI
      - COMMIT_HASH=$(echo $CODEBUILD_RESOLVED_SOURCE_VERSION | cut -c 1-7)
      - IMAGE_TAG=$COMMIT_HASH

  build:
    commands:
      - echo Running tests...
      - pytest tests/ --junitxml=test-results.xml
      - echo Building Docker image...
      - docker build -t $ECR_URI:$IMAGE_TAG .

  post_build:
    commands:
      - docker push $ECR_URI:$IMAGE_TAG
      - echo Build complete. Image $ECR_URI:$IMAGE_TAG

artifacts:
  files:
    - imagedefinitions.json  # Used by CodeDeploy for ECS deploy
reports:
  TestResults:
    files: test-results.xml
    file-format: JUNITXML

CodeDeploy — Deployment Service

Automates application deployments to EC2, on-premises servers, Lambda, and ECS. Handles rolling updates, blue/green deployments, automatic rollback on failure. Defined in appspec.yml.

# appspec.yml for EC2 deployment
version: 0.0
os: linux
files:
  - source: /app
    destination: /var/www/html
hooks:
  BeforeInstall:
    - location: scripts/stop_server.sh
      timeout: 30
  AfterInstall:
    - location: scripts/install_dependencies.sh
      timeout: 120
  ApplicationStart:
    - location: scripts/start_server.sh
      timeout: 30
  ValidateService:
    - location: scripts/health_check.sh
      timeout: 60

CodeDeploy Deployment Configurations

Elastic Beanstalk — PaaS Deploy

If you don't want to manage CI/CD pipelines at all, Elastic Beanstalk is AWS's PaaS. Upload your app code (zip), EB handles EC2 provisioning, Auto Scaling, Load Balancer, health monitoring, and rolling deploys. Runs on top of standard AWS services (you can still see and modify the EC2 instances). Great for smaller teams or migrating existing apps quickly. Less flexible than managing EC2/ECS directly.

What is AWS Systems Manager?

SSM is a collection of operational tools for managing your EC2 instances and on-premises servers at scale. Often overlooked but incredibly powerful for DevOps. It's a suite of services, not just one thing.

SSM Session Manager

Connect to EC2 instances via browser or CLI without opening port 22, without a bastion host, without managing SSH keys. The SSM Agent on the instance communicates outbound to SSM service — no inbound port needed. Fully audited — all sessions recorded to S3 or CloudWatch.

# Connect to EC2 via SSM (no SSH key, no port 22)
aws ssm start-session --target i-0abc12345

# Port forwarding via SSM (access RDS in private subnet)
aws ssm start-session --target i-0abc12345 \
  --document-name AWS-StartPortForwardingSession \
  --parameters '{"portNumber":["3306"],"localPortNumber":["13306"]}'
# Now: mysql -h 127.0.0.1 -P 13306 -u admin -p

SSM Parameter Store

Store configuration values and secrets. Types: String, StringList, SecureString (KMS-encrypted). Use for: app config, database hostnames, feature flags, non-sensitive or mildly-sensitive parameters.

# Store a parameter
aws ssm put-parameter \
  --name "/myapp/production/db-host" \
  --value "mydb.cluster.ap-south-1.rds.amazonaws.com" \
  --type String

# Store an encrypted secret
aws ssm put-parameter \
  --name "/myapp/production/api-key" \
  --value "sk-abc123secret" \
  --type SecureString \
  --key-id alias/myapp-key

# Retrieve in code (Python)
ssm = boto3.client('ssm')
param = ssm.get_parameter(Name='/myapp/production/db-host', WithDecryption=True)
db_host = param['Parameter']['Value']

SSM Run Command

Run commands across multiple EC2 instances without SSH. Execute shell scripts, PowerShell, Python across your entire fleet in seconds. With resource tags, target groups: "Run this on all instances tagged Environment=production."

SSM Patch Manager

Automate OS patching across your fleet. Define patch baselines (which patches to apply, e.g., only Critical + High severity), maintenance windows (when to apply — 2 AM Sunday), and patch groups (which instances). Never manually SSH to patch 50 servers again.

SSM State Manager

Keep instances in a desired state. Define an association: "All prod instances must have the CWAgent installed and running." State Manager periodically checks and enforces this. If someone removes the agent, SSM reinstalls it.

What is SQS?

SQS is a fully managed message queue service. It decouples producers (who send messages) from consumers (who process them). If your consumer is slow or down, messages accumulate safely in the queue. No message is lost. Classic async communication pattern.

  WITHOUT SQS (Tight Coupling):
  Web App ──HTTP──► Worker Service
  If Worker is slow/down → Web App blocks or errors ✗

  WITH SQS (Loose Coupling):
  Web App ──PutMessage──► [SQS Queue] ◄──PollMessages── Worker Service
  Web App returns immediately ✓           Worker processes at its own pace ✓
  Queue buffers messages during spikes ✓  Worker can scale independently ✓
  Messages survive worker crashes ✓

SQS Key Concepts

Queue Types

Visibility Timeout

When a consumer reads a message, it's hidden from other consumers for the visibility timeout period (default 30s, max 12h). The consumer must delete the message before timeout expires. If it doesn't (consumer crashed), the message becomes visible again for another consumer to process. Set visibility timeout to slightly longer than your max processing time.

Dead Letter Queue (DLQ)

If a message fails processing too many times (exceeds maxReceiveCount), SQS moves it to a Dead Letter Queue. DLQ lets you isolate and debug problematic messages without losing them. Always configure a DLQ for production queues — otherwise failed messages keep cycling forever consuming resources.

Long Polling

When a consumer calls ReceiveMessage and the queue is empty, short polling returns immediately (wasteful API calls). Long polling waits up to 20 seconds for a message to arrive before returning empty. Reduces cost (fewer API calls) and reduces false-empty responses. Always use long polling (WaitTimeSeconds=20).

# Sending a message (Python boto3)
sqs = boto3.client('sqs')
response = sqs.send_message(
    QueueUrl='https://sqs.ap-south-1.amazonaws.com/123456/my-queue',
    MessageBody=json.dumps({
        'order_id': 'ORD-12345',
        'customer_id': 'CUST-789',
        'items': [{'product': 'laptop', 'qty': 1}]
    }),
    MessageAttributes={
        'EventType': {'StringValue': 'OrderPlaced', 'DataType': 'String'}
    }
)

# Consuming messages (long polling)
while True:
    response = sqs.receive_message(
        QueueUrl=QUEUE_URL,
        MaxNumberOfMessages=10,
        WaitTimeSeconds=20,        # Long polling
        VisibilityTimeout=60       # 60s to process
    )
    for message in response.get('Messages', []):
        process_order(json.loads(message['Body']))
        # Delete after successful processing
        sqs.delete_message(
            QueueUrl=QUEUE_URL,
            ReceiptHandle=message['ReceiptHandle']
        )

Amazon SNS — Simple Notification Service

SNS is a publish/subscribe (pub/sub) messaging service. A publisher sends a message to a Topic, and SNS fans it out to all subscribers simultaneously. One message → many consumers. Perfect for: fanout pattern, notifications, decoupled event broadcasting.

SNS Subscribers

A topic can have multiple subscribers of different types: SQS queue, Lambda function, HTTP/HTTPS endpoint, Email, SMS, Mobile Push (APNs, GCM), Kinesis Data Firehose.

  Order Service publishes "OrderPlaced" event to SNS Topic
                              │
              ┌───────────────┼───────────────┐
              ▼               ▼               ▼
        SQS Queue       Lambda Fn        SQS Queue
        (Inventory      (Send email      (Analytics
         Service)        confirmation)    Service)

  All three consumers receive the same message independently.
  If one consumer is down, others still get the message.

SNS vs SQS — Key Difference

SNS + SQS Fanout Pattern

The most common real-world pattern: SNS pushes to multiple SQS queues. This gives you fanout (SNS) with durability and retry (SQS):

# Architecture:
# New Product Added → SNS Topic "product-events"
#   → SQS "inventory-queue" → Inventory Lambda
#   → SQS "search-index-queue" → Search Index Lambda
#   → SQS "notification-queue" → Push Notification Lambda

# If Search Index Lambda is down: messages buffer in search-index-queue
# Inventory and Push Notification still work independently
# When Search Lambda recovers: processes all buffered messages
# This is the gold standard for reliable event-driven microservices.

Amazon EventBridge

An event bus service for building event-driven applications. More powerful than SNS for complex routing — you can filter events by content, transform them, route to 20+ AWS services, connect to third-party SaaS apps (Salesforce, Zendesk, Datadog), and create custom event buses per service.

• Default Event Bus: Receives AWS service events (EC2 state changes, CodePipeline updates, etc.)
• Custom Event Bus: For your own application events. Publish events from your microservices here.
• Partner Event Bus: Receive events from SaaS partners (Shopify orders, GitHub events)

# Publish a custom event to EventBridge
events = boto3.client('events')
events.put_events(
    Entries=[{
        'Source': 'com.mycompany.orders',
        'DetailType': 'OrderPlaced',
        'Detail': json.dumps({'orderId': 'ORD-123', 'total': 599.99}),
        'EventBusName': 'my-app-events'
    }]
)
# EventBridge rule routes this to: Lambda for fulfillment,
# SQS for analytics, another EventBridge bus in a different account
# Based on content: {"source": ["com.mycompany.orders"], "detail-type": ["OrderPlaced"]}

Amazon Kinesis — Real-Time Streaming

For high-throughput, real-time data streaming. Unlike SQS (queue — messages consumed and deleted), Kinesis retains data as a stream that multiple consumers can read from. Think of it as a real-time data pipeline.