🔗 Repo: github.com/Push/terraform-aws-labs/day17

🎯 Goal: Deploy app versions to identical environments → swap DNS → zero-downtime releases.

✅ You’ll build:

🧠 Why Blue/Green? (Not Just Theory)

Deployment Strategy Downtime Risk Use Case
❌ In-Place (EC2) High (minutes) Critical (rollback = manual) Legacy apps
❌ Rolling Update Medium (seconds) Medium (partial traffic) Stateless apps
✅ Blue/Green None (swap in <30s) Low (rollback = 1 click) Production APIs, E-commerce

💡 Golden Rule:

“If your app can’t tolerate 5 seconds of downtime — Blue/Green is non-negotiable.”

📦 Architecture Diagram

flowchart LR
  subgraph BEFORE_SWAP [Before Swap]
    A[Users] -->|blue.example.com| B[Blue Env (v1.0)]
    A -->|green.example.com| C[Green Env (v2.0)]
    B --> D[(S3: app-v1.zip)]
    C --> E[(S3: app-v2.zip)]
  end

  subgraph AFTER_SWAP [After Swap]
    A -->|blue.example.com| C
    A -->|green.example.com| B
  end

  Click[Swap CNAME] --> AFTER_SWAP

✅ Critical Flow:

  1. Deploy v1.0 to Blue → users → blue.example.com
  2. Deploy v2.0 to Green (identical infra, no traffic)
  3. Test v2.0 (smoke tests, perf, security scans)
  4. Swap CNAMEs → traffic instantly shifts to v2.0
  5. Rollback? Swap again → back to v1.0 in <30s

✏️ Hands-On: Terraform Implementation

🔹 File Structure (/day17/)

day17/
├── main.tf             # Shared resources (S3, IAM roles, EB app)
├── blue_env.tf         # Blue environment (v1.0)
├── green_env.tf        # Green environment (v2.0)
├── package-apps.sh     # 📦 Build app zip (v1, v2)
└── TASK.md             # 📝 Your challenge (Canary, CloudWatch alarms)