The AWS Lab Step Tracker You’ll Actually Use
Scattered console clicks, shell history, and half-written wikis make AWS labs feel disposable. Here’s the lightweight system senior engineers use to capture, structure, and replay every lab step.
Why AWS labs become a blur
You start with a clean goal: build a private VPC, deploy an EC2 instance, attach an IAM role. Four hours later you have 18 browser tabs, a shell history full of `aws s3api` calls, and a note that says “fix DNS maybe.” The lab is finished, but the learning has evaporated.
AWS labs are uniquely hard to track because the console is stateful and click-driven. It does not produce a commit log. Shell history is chronological but noisy. Screenshots capture pixels, not intent.
The three ways experienced engineers track lab steps
1. Runbooks, not notes
A note says “create a VPC.” A runbook says:
Open VPC console → Your VPCs → Create VPC
Name: `lab-vpc`, CIDR: `10.16.0.0/16`
Enable DNS hostnames: yes
Verify: `aws ec2 describe-vpcs --filters Name=tag:Name,Values=lab-vpc`
That difference is the whole game.
2. Terminal as lab notebook
Use [`script`](https://man7.org/linux/man-pages/man1/script.1.html) or [`asciinema`](https://asciinema.org) to capture commands and output. Pair it with a Git branch. At Sapior, we recommend keeping a `labs/aws/YYYY-MM-DD-vpc-peering/` directory with:
`README.md` runbook
`commands.sh`
`console-steps.md`
`cleanup.sh`
This makes a lab reviewable, searchable, and shareable.
3. Infrastructure as Code, even for practice
The fastest way to track AWS lab steps is to make the steps executable. A simple [CloudFormation](https://docs.aws.amazon.com/cloudformation/) template or [Terraform](https://developer.hashicorp.com/terraform) file records parameters, dependencies, and cleanup in one place. Even if you started in the console, extracting the final state into IaC is a strong post-lab habit.
Why most tracking fails
Most engineers fall back to browser bookmarks, Notion pages, or mental models. Those fail because they capture the artifact, not the action. A screenshot of an EC2 security group does not tell you why port 5432 is open or which lab required it.
The fix is to lower the cost of capture. If recording a step takes more than a few seconds, you will stop doing it when the lab gets hard.
A minimal AWS lab tracking stack
1. **Runbook repo**: one folder per lab, with README and cleanup script.
2. **Terminal recorder**: `asciinema` for commands, `script` for full sessions.
3. **Console step log**: a browser or CLI recorder that captures AWS Console actions.
4. **IaC export**: CloudFormation or Terraform for the final topology.
5. **Weekly review**: convert one messy lab into a clean runbook.
How Sapior makes lab tracking automatic
Sapior records the browser and CLI actions as you work, then turns them into a structured runbook with step IDs, parameters, and verification commands. Instead of trying to remember whether you clicked “Enable DNS hostnames,” you get a replayable sequence you can share with a teammate. That closes the gap between doing a lab and keeping the lab.
The payback is compounding
The first lab you track feels slower. The tenth lab is fast because you reuse runbooks, cleanup scripts, and CloudFormation snippets. Eventually, your AWS lab repo becomes a private training platform—and you stop solving the same problem twice.