DevOps & Cloud Concepts

Why This Module?

Before diving into specific AWS services, it helps to understand the foundational concepts that underpin every cloud architecture. These ideas are cloud-agnostic — they apply equally to AWS, Azure, and GCP.

High Availability (HA)

High availability means your system continues operating when components fail. It's measured as a percentage of uptime:

Key HA Patterns

• Redundancy: No single point of failure. Run 2+ instances, across 2+ Availability Zones
• Health checks: Continuously monitor components and automatically replace unhealthy ones
• Failover: Automatic promotion of standby systems (e.g., RDS Multi-AZ)
• Statelessness: Store session data externally (Redis/DynamoDB) so any instance can serve any request

HA on AWS

Single instance (no HA):
  User → EC2 → RDS
  Availability: ~99.5%

Basic HA (Multi-AZ):
  User → ALB → [EC2 AZ-a, EC2 AZ-b] → RDS Multi-AZ
  Availability: ~99.99%

Full HA (Multi-Region):
  User → Route 53 (failover) → [Region A: ALB → ASG → Aurora]
                               [Region B: ALB → ASG → Aurora Replica]
  Availability: ~99.999%

Load Balancing

A load balancer distributes incoming requests across multiple targets to prevent any single server from becoming a bottleneck.

Load Balancing Algorithms

AWS Load Balancer Types

Health Checks

Load balancers rely on health checks to know which targets are alive. A health check sends a request (e.g., GET /health) at regular intervals. If a target fails consecutive checks, it's removed from rotation.

Health Check Config:
  Path:              /health
  Interval:          30 seconds
  Healthy threshold: 2 consecutive successes → mark healthy
  Unhealthy threshold: 3 consecutive failures → mark unhealthy
  Timeout:           5 seconds per check

Autoscaling

Autoscaling automatically adjusts the number of compute instances based on demand. It scales out (add instances) under load and scales in (remove instances) when demand drops.

Scaling Types

Scaling Policies

Target Tracking (recommended):
  "Keep average CPU at 60%"
  → ASG automatically adds/removes instances to maintain target
  → Simple, self-managing

Step Scaling:
  CPU > 60% → add 1 instance
  CPU > 80% → add 3 instances
  CPU < 30% → remove 1 instance
  → More control, more config

Simple Scaling:
  CPU > 70% → add 1 instance, then wait 300s cooldown
  → Basic, legacy — prefer Target Tracking

Scaling on AWS — The Key Services

• EC2 Auto Scaling Groups: Scale EC2 instances horizontally
• ECS Service Auto Scaling: Scale container tasks based on CPU/memory or custom metrics
• K8s HPA: Scale pods on EKS based on metrics
• Lambda: Scales automatically with no config (up to account concurrency limit)
• DynamoDB: Auto-scales read/write capacity units
• Aurora: Auto-scales read replicas and storage

Deployment Strategies

How you ship changes to production determines your risk, speed, and rollback capabilities. Here are the main strategies:

1. Rolling Deployment

Time →
Instance 1:  [v1] [v1] [v2] [v2] [v2]
Instance 2:  [v1] [v1] [v1] [v2] [v2]
Instance 3:  [v1] [v1] [v1] [v1] [v2]

✅ Low cost (no extra instances)
✅ Gradual rollout
❌ During update, mix of v1 and v2 serving traffic
❌ Slow rollback (must re-deploy v1)

2. Blue/Green Deployment

                    ┌── Blue (v1) ← LIVE
LB ──┤
                    └── Green (v2) ← Idle, testing

After validation:

                    ┌── Blue (v1) ← Idle (keep for rollback)
LB ──┤
                    └── Green (v2) ← LIVE ✓

✅ Instant rollback (switch back to blue)
✅ Zero-downtime
✅ Full testing before go-live
❌ Costs 2x resources during deployment

3. Canary Deployment

Time →
Phase 1:  5% traffic → v2, 95% → v1    (test with small %)
Phase 2:  25% traffic → v2, 75% → v1   (if metrics OK, increase)
Phase 3:  100% traffic → v2             (full rollout)

✅ Lowest risk — errors affect few users
✅ Data-driven decision (watch error rates)
❌ Most complex to implement
❌ Need good observability to detect issues

4. A/B Testing (Traffic Splitting)

Similar to canary but the split is for feature comparison, not just safety. Route specific user segments to different versions and measure business metrics (conversion rate, engagement).

AWS Implementation

Disaster Recovery (DR)

DR is your plan for recovering from catastrophic failures — region outages, data corruption, or complete infrastructure loss. Two critical metrics define DR:

DR Strategies (by cost & speed)

Example: Warm Standby

Primary Region (us-east-1):         DR Region (us-west-2):
┌─ ALB → ASG (4 instances)       ┌─ ALB → ASG (1 instance)
├─ RDS Primary                   ├─ RDS Read Replica
├─ ElastiCache                   └─ Route 53 health check
└─ S3 (cross-region replication)

On failure:
1. Route 53 detects primary unhealthy
2. DNS fails over to us-west-2
3. ASG scales from 1 → 4 instances
4. RDS replica promoted to primary
5. ~5 minute recovery time

Observability

Observability answers: "What is my system doing and why?"It's built on three pillars:

The Three Pillars

AWS Observability Stack

The Golden Signals

Google's SRE book defines four signals every service should monitor:

• Latency: How long requests take (track p50, p95, p99)
• Traffic: How many requests per second (demand)
• Errors: Rate of failed requests (5xx, timeouts)
• Saturation: How "full" your system is (CPU, memory, disk, connections)

Immutable Infrastructure

Instead of updating servers in place (mutable), you replace them entirelywith new versions. Think of servers like cattle, not pets.

Benefits of Immutable Infrastructure

• No configuration drift: Every instance is identical — built from the same AMI/image
• Reliable rollbacks: Deploy old version = launch old AMI
• Easier debugging: "It works in staging" actually means something when staging = production image
• Security: No SSH access needed. Smaller attack surface

The Immutable Pipeline

Code Change → Build → Create AMI/Image → Deploy New Instances → Terminate Old

Developer pushes code
     │
     ▼
CodeBuild: npm install, test, build
     │
     ▼
Packer: Bake AMI with app + dependencies
     │
     ▼
Terraform/CloudFormation: Update Launch Template with new AMI
     │
     ▼
ASG: Rolling replacement of old instances with new ones

More Key Concepts

Infrastructure as Code (IaC)

Manage infrastructure through code instead of manual console clicks. Version-controlled, reviewable, repeatable, and testable. CloudFormation and Terraform are the two main tools (covered in Module 5).

GitOps

Git is the single source of truth for infrastructure and application state. Changes are made via Pull Requests. A reconciliation tool (ArgoCD, Flux) ensures the live state matches what's in git.

Developer → PR to git → Approved → Merged
                                       ↓
ArgoCD watches git → Detects change → Applies to K8s cluster
                                       ↓
Cluster state = Git state (always)

12-Factor App Principles (for Cloud-Native)

Idempotency

An operation is idempotent if running it multiple times produces the same result as running it once. This is critical for:

• IaC: terraform apply can be run repeatedly without side effects
• APIs: Retrying a PUT request doesn't create duplicate records
• Deployments: Re-running a deployment script doesn't break the existing setup
• Ansible playbooks: Run 10 times, same result every time

Principle of Least Privilege

Grant only the minimum permissions needed for a task. Every IAM role, security group, and NACL should follow this principle. If a service only reads from S3, don't give it write access.

Key Takeaways

• HA = redundancy + health checks + auto-failover across multiple AZs
• Autoscaling = use Target Tracking for simplicity, always include scale-in
• Deployment strategies = rolling for simplicity, blue/green for safety, canary for precision
• DR = define RTO/RPO first, then choose strategy. Test your DR plan!
• Observability = metrics + logs + traces. Alert on symptoms, not causes
• Immutable infra = cattle not pets. Replace, don't repair
• These concepts are cloud-agnostic — they apply to AWS, Azure, GCP, and on-prem