Why this lab matters

Provisioning an EC2 instance through the AWS console takes about ninety seconds of clicking. Doing it with Terraform takes ten minutes the first time, and thirty seconds every time after. The point isn't the EC2 instance. The point is the muscle memory: declarative infrastructure, version-controlled changes, and the loop of init then plan then apply then destroy that you'll repeat thousands of times across every cloud resource you ever touch.

This lab is the gateway. Every AWS lab that follows assumes you can do this in your sleep.

Prerequisites

Before you start, confirm:

• AWS account with programmatic access (Access Key ID + Secret Access Key)
• AWS CLI installed and configured (run aws configure)
• Terraform v1.6 or later installed (terraform version should print a version)
• A region picked. The lab defaults to us-east-1. If you're in another region, swap the value in main.tf and pick a matching AMI.

If any of those four are missing, fix them first. Don't try to debug Terraform errors caused by missing AWS credentials.

What this lab builds

A single t2.micro EC2 instance in us-east-1, defined declaratively in Terraform. Pinned AWS provider version. Identifying tags so you can find it again. Then a clean teardown when you're done.

Small surface area. Huge muscle memory return.

Get the code

Clone the repo from GitHub and navigate to the EC2 lab folder:

github.com/vandana-platform/02-tier-1-devops → aws → ec2-terraform-instance

Once cloned, cd into the ec2-terraform-instance directory. The main.tf file inside has the full Terraform definition. Read it before you apply.

Run the apply loop

From the lab directory, run terraform init, then terraform plan, then terraform apply.

init downloads the AWS provider. plan shows you what Terraform intends to do — read this output carefully every time. apply actually creates the instance and asks for confirmation.

When apply finishes, you'll have a running t2.micro instance. Verify in the AWS console under EC2 → Instances, or via CLI.

What to notice while you're doing it

Three things in the Terraform code worth pausing on:

1. The required_providers block pins the AWS provider to major version 5. Skipping this works today and breaks on a Tuesday in 2027 when the provider hits a major version bump.
2. The AMI ID is region-specific. The repo uses Amazon Linux 2023 in us-east-1. If you change region, you must change the AMI — look it up in the EC2 console under Launch Instance.
3. The tags aren't decorative. They're how you find this instance again in three months when you've forgotten you created it.

Destroy

This is the most important step. Free tier covers 750 hours of t2.micro per month, but you're going to forget. Run terraform destroy and type yes. The instance terminates. Bill stops. This is the loop you want burned into your reflexes.

Common gotchas

• UnauthorizedOperation on apply. Your IAM user doesn't have ec2:RunInstances permission. Attach AmazonEC2FullAccess for the lab, then strip it down for production work.
• InvalidAMIID.NotFound. Wrong region for the AMI. The AMI in the repo is for us-east-1 only. Look up the right AMI for your region in the EC2 console under Launch Instance.
• terraform apply hangs forever. Almost always a default VPC issue or a credentials problem. Check aws sts get-caller-identity runs successfully first.
• State file confusion. The terraform.tfstate file is created locally. If you delete it, Terraform loses track of the instance and you'll have to delete it manually from the console. For real work, use remote state in S3. For this lab, just don't delete the state file.

Interview-style questions to think through

While you run the lab, hold these in your head — they're the exact questions a senior engineer would ask in a screen:

• Why pin the provider version? What breaks if you don't?
• What's the difference between plan and apply? Why does plan matter in a team setting?
• What lives in terraform.tfstate and why is keeping it local a problem in production?
• If two engineers run terraform apply against the same state at the same time, what happens?
• How would you change this lab to provision the instance in a custom VPC instead of the default?

If you can answer these out loud without looking anything up, you've earned the lab.

What's next

Once init then plan then apply then destroy feels routine, the next lab adds a Security Group, a Key Pair, and SSH access. After that, ECS with blue/green deploys. The progression is intentional: every lab adds one production-grade concept on top of the previous one.

Real world: this is how every AWS infrastructure team you'll ever join provisions resources. Console clicks are for exploration. Terraform is for anything that has to exist tomorrow.