AWS CLI and Infrastructure as Code

After this lesson, you will be able to: Use the AWS CLI for common operations and write basic Infrastructure-as-Code with Terraform (and recognise CloudFormation).

Click-ops doesn't scale. IaC is what mature teams use for everything. This lesson covers the CLI + a Terraform on-ramp.

Prerequisites:CloudFront

AWS CLI essentials

Beyond `aws configure`, these are the daily commands.

tsx

# General shape: aws <service> <verb> --options
aws s3 ls
aws ec2 describe-instances
aws ec2 describe-instances --filters 'Name=tag:Name,Values=prod' --query 'Reservations[].Instances[].InstanceId' --output text
aws iam list-users
aws rds describe-db-instances
aws logs tail /aws/lambda/myfunction --follow

# Profiles (multiple accounts)
aws configure --profile prod
AWS_PROFILE=prod aws s3 ls

# Output formats
--output json   (default)
--output text   (script-friendly)
--output table  (human-readable)
--query         (JMESPath; like jq but for AWS responses)

Why Infrastructure-as-Code (IaC)

Manual console clicks: untracked changes, no rollback, no review, lost knowledge. IaC: cloud config is YAML / HCL / TypeScript in git. Code review on changes. Rollback via git revert. Reproducible (same code, same infra). Tools: Terraform / OpenTofu (cloud-agnostic, HCL); CloudFormation (AWS-only, YAML); Pulumi / AWS CDK (real programming languages); SST / Serverless Framework (higher-level wrappers). For learning + most jobs: Terraform.

Terraform: hello world

Provisions an S3 bucket. Install: brew install terraform or download from terraform.io.

tsx

# main.tf
terraform {
  required_providers {
    aws = { source = "hashicorp/aws", version = "~> 5.0" }
  }
}

provider "aws" {
  region = "us-east-1"
}

resource "aws_s3_bucket" "my_bucket" {
  bucket = "my-bucket-${random_id.suffix.hex}"
}

resource "random_id" "suffix" {
  byte_length = 4
}

output "bucket_name" {
  value = aws_s3_bucket.my_bucket.bucket
}

# Workflow:
terraform init       # one-time, downloads providers
terraform plan       # shows what would change
terraform apply      # applies the plan
terraform destroy    # tears down everything

The IaC mental model

Declare DESIRED state. Tool figures out the diff vs CURRENT state. Apply the diff. State file: Terraform tracks what's been created. Store remotely (S3 + DynamoDB lock) for team use. Modules: reusable IaC packages. The Terraform Registry has thousands of community modules. Plan first, always. Never `terraform apply` without reading `plan` output. Catches the 'oh no I would have deleted the prod DB' bug.

Common mistakes only experienced engineers avoid

Editing infrastructure manually after it's in IaC. Drift creeps in; next `terraform apply` reverts your manual change. No remote state. Local state files = team can't collaborate; lose laptop = lose state. No state locking. Two `terraform apply`s in parallel corrupt state. Hardcoded secrets in .tf files. Use AWS Secrets Manager + data source; never commit secrets. Skipping `plan`. The shocked face when you realise apply deleted your prod DB. Always plan.

Quick Check

Why is `terraform plan` important before `terraform apply`?

Pick the most important reason.

Required by the toolPlan shows EXACTLY what will change; lets you catch surprises (like deleting prod resources) before they happenPlan is fasterPlan is more reliable

←AWS Monitoring and Security Services

Back to Cloud Platforms — AWS

AWS-Native CI/CD: CodePipeline, CodeBuild, CodeDeploy→