← All posts

☁️AWS from Zero

Part 10 of 10
3 min read

Automation and the long AWS roadmap

#aws#automation#cloudformation#cli
📑 On this page

Part 10 of AWS from Zero. The first nine parts taught the shape:

  • Configure identity.
  • Read help.
  • Query output.
  • Create small resources.
  • Inspect them.
  • Delete them.

Now we turn that shape into automation.

Stop pasting long commands forever

Long AWS CLI commands are okay while learning. But after the third repeat, create a script.

Example folder:

aws-from-zero/
  scripts/
    whoami.sh
    list-regions.sh
    cleanup-s3-demo.sh
  inputs/
    bucket-website.json
    tags.json

Simple script:

#!/usr/bin/env bash
set -euo pipefail
 
aws sts get-caller-identity
aws configure list

Run:

chmod +x scripts/whoami.sh
./scripts/whoami.sh

Use JSON input files

Many AWS CLI commands accept JSON files. This keeps commands readable.

Instead of:

aws s3api put-bucket-website --bucket "$BUCKET" --website-configuration '{...}'

use:

aws s3api put-bucket-website \
  --bucket "$BUCKET" \
  --website-configuration file://inputs/website.json

That is easier to review, commit, and reuse.

Learn CloudFormation next

AWS CLI is excellent for understanding APIs. But when infrastructure grows, you want a desired-state tool.

CloudFormation lets you define resources in YAML or JSON:

aws cloudformation deploy \
  --stack-name aws-zero-demo \
  --template-file template.yaml \
  --capabilities CAPABILITY_NAMED_IAM

Then AWS creates or updates the stack.

Terraform and CDK are also important, but CloudFormation is worth learning because it is AWS-native and many services document it directly.

The long service roadmap

This series can now expand in layers. The goal is not to finish AWS in one pass. The goal is to create a growing library where a beginner can search for one tiny AWS action and find the exact CLI-first lesson for it.

Core infrastructure

  • EC2
  • VPC
  • EBS
  • EFS
  • Elastic Load Balancing
  • Auto Scaling
  • Route 53

Storage

  • S3
  • S3 Glacier
  • EFS
  • FSx
  • AWS Backup

Databases

  • RDS
  • Aurora
  • DynamoDB
  • ElastiCache
  • Redshift
  • DocumentDB
  • Neptune
  • Keyspaces

Serverless and events

  • Lambda
  • API Gateway
  • EventBridge
  • Step Functions
  • SQS
  • SNS

Containers

  • ECR
  • ECS
  • Fargate
  • EKS
  • App Runner

Security and governance

  • IAM
  • KMS
  • Secrets Manager
  • Certificate Manager
  • WAF
  • GuardDuty
  • Inspector
  • Security Hub
  • Organizations
  • Control Tower

Operations

  • CloudWatch
  • CloudTrail
  • Systems Manager
  • Config
  • Health

Data, analytics, and AI

  • Athena
  • Glue
  • EMR
  • Kinesis
  • OpenSearch
  • QuickSight
  • Bedrock
  • SageMaker
  • Textract
  • Transcribe
  • Polly
  • Rekognition

Migration and hybrid

  • DMS
  • DataSync
  • Transfer Family
  • Storage Gateway
  • VPN
  • Direct Connect

The rule for every future service

Every service lesson should keep the same shape:

What is it?
When should you use it?
What is the smallest safe command?
How do you inspect it?
What is one variation?
How do you clean it up?
What production topic comes later?

That structure is how we can slowly cover AWS without drowning in it.

The next writing lane is deeper S3, then IAM policies, then EC2 plus VPC as real mini projects. After that, the same pattern can repeat across the rest of AWS: one small command, one clear explanation, one safe cleanup path.