Skip to content

Cloud Playbooks

Practical paths for designing, building, and operating cloud systems. Each playbook connects the why, the manual workflow, the automation layer, and the production checks that prevent avoidable incidents.

Start in a sandbox. Use least-privilege identities, budgets, private networking by default, and destroy temporary resources after each exercise.

Choose Your Path

Goal Start with Then automate with Production check
Launch a web server AWS guide Terraform guide Health check, logs, restricted ingress
Publish a static site AWS S3 workflow in the hands-on labs Terraform and CI/CD Private origin, CDN, HTTPS, rollback
Run containers Docker guide Kubernetes guide Image scan, resource limits, probes
Ship safely Azure DevOps guide DevOps projects Approval gates, artifacts, rollback
Improve reliability Monitoring guide GitOps and alerts SLOs, dashboards, tested recovery

Playbook 1: Web Service From Zero to Repeatable

Design

Developer -> Git -> CI checks -> Terraform plan -> Cloud resources -> HTTP service
                                              \-> logs, metrics, alerts

Manual checkpoint

  1. Select a region and define an owner, environment, and expiry date.
  2. Create a private network or use a controlled default network in a sandbox.
  3. Create a security group with only the required application port.
  4. Launch the smallest suitable compute instance.
  5. Install the service and verify its health endpoint.
  6. Record the public address, logs location, and cleanup command.

Automation checkpoint

Move each manual decision into versioned code:

  • Provider and region become variables.
  • Network and security rules become resources.
  • User data or cloud-init installs the service consistently.
  • Outputs expose only useful values such as an address or load balancer name.
  • CI runs formatting, validation, plan, security scanning, and approval before apply.

Use the complete AWS EC2 manual-to-Terraform lab for a working example.

Playbook 2: Infrastructure as Code That Teams Can Trust

A reliable Terraform repository usually has this shape:

infra/
├── envs/
│   ├── dev/
│   └── prod/
├── modules/
│   ├── network/
│   └── service/
├── backend.tf
├── providers.tf
├── variables.tf
└── outputs.tf

Review gates

  • terraform fmt -check
  • terraform init -upgrade in a controlled build image
  • terraform validate
  • terraform plan -out=tfplan
  • Policy and secret scanning
  • Human review of destructive changes
  • Apply the saved plan, not a second unreviewed plan

Keep state in a protected remote backend with encryption and locking. Separate environments by state, identity, and approval boundary.

Playbook 3: Container to Kubernetes

Build

docker build --tag example-service:dev .
docker run --rm --publish 8080:8080 example-service:dev

Promote

  1. Add a health endpoint and graceful shutdown.
  2. Build an immutable image tagged with a commit SHA.
  3. Scan the image before pushing it to a registry.
  4. Define CPU and memory requests and limits.
  5. Add readiness and liveness probes.
  6. Deploy with a manifest or Helm chart.
  7. Observe the rollout, then verify the service from outside the cluster.

Read the Docker guide, Cloud Native guide, and GitOps guide for the detailed layers.

Playbook 4: CI/CD With a Safe Promotion Model

stages:
- stage: Verify
  jobs:
  - job: Quality
    steps:
    - script: ./scripts/test.sh
    - script: ./scripts/security-scan.sh
    - script: terraform plan -out=tfplan

- stage: DeployDev
  dependsOn: Verify
  jobs:
  - script: terraform apply tfplan

- stage: ProductionApproval
  dependsOn: DeployDev
  jobs:
  - deployment: DeployProduction
    environment: production
    strategy:
      runOnce:
        deploy:
          steps:
          - script: terraform apply tfplan

The important part is not the YAML syntax. It is the contract: the same artifact is tested once, promoted through controlled environments, and deployed with an auditable identity.

Playbook 5: Operate What You Deploy

Before calling a service production-ready, answer these questions:

  • What is the service-level objective?
  • Which dashboard shows traffic, errors, latency, and saturation?
  • Which alert wakes a person, and which alert creates a ticket?
  • Where are application and audit logs retained?
  • How do you roll back the last release?
  • What is the recovery point and recovery time objective?
  • Who owns the service and the runbook?

Continue with Monitoring, DevSecOps, and DevOps Projects.

Suggested Progression

  1. Build the EC2 lab manually.
  2. Rebuild it with Terraform.
  3. Add CI validation and a saved plan.
  4. Containerize the service with Docker.
  5. Deploy it to Kubernetes.
  6. Add dashboards, alerts, and a rollback drill.
  7. Document the architecture and teach the workflow to another engineer.