Chapter 45: Terraform 3-Tier Architecture in a Single Availability Zone

45.5 Apply, test and destroy the single-AZ 3-tier stack

By Ravindra Bagale · Last updated: 25 October 2026

Story. Suppose we are showing the HR portal pilot to the client on a call. We need three proofs: the web page loads, /api/ reaches the private app server, and the database endpoint exists without being public. After the demo we delete the whole stack, because a NAT gateway and RDS cost money every hour they run.

Steps

1. Run init, fmt and validate.
2. Save a plan and apply it.
3. Wait 3 minutes for user_data.
4. Curl / and /api/.
5. Check the RDS settings.
6. Run terraform destroy.

terraform init
terraform fmt -recursive
terraform validate
terraform plan -out tfplan
terraform apply tfplan

curl -s $(terraform output -raw web_url)
curl -s $(terraform output -raw web_url)/api/
aws rds describe-db-instances --db-instance-identifier tier1az-mysql \
  --query "DBInstances[0].[PubliclyAccessible,MultiAZ,AvailabilityZone]"

terraform destroy

What each line does

• terraform plan -out tfplan — Saves the exact plan so apply runs what you reviewed.
• terraform apply tfplan — Applies that saved plan without asking again.
• curl -s .../ — Tests the web tier.
• curl -s .../api/ — Tests web to app through nginx.
• aws rds describe-db-instances ... --query — Shows public access false, Multi-AZ false and the zone.
• terraform destroy — Deletes all 24 resources.

When it is green.

web tier ok
app tier: ip-10-30-11-25.ap-south-1.compute.internal
[ false, false, "ap-south-1a" ]

Plan: 0 to add, 0 to change, 24 to destroy.
Destroy complete! Resources: 24 destroyed.

When it is red.

Error: deleting EC2 Internet Gateway: DependencyViolation:
Network vpc-... has some mapped public address(es)

Fix. Usually a resource created outside Terraform (for example a console test instance) is still in the VPC. Delete it, then run terraform destroy again.

What: every term in plain English

• saved plan — A file from terraform plan -out tfplan. apply tfplan runs exactly that plan, nothing else.
• smoke test — A quick check that the main paths work: page loads, API answers, DB reachable.
• output — A value Terraform prints after apply, such as web_url, used by tests and people.
• terraform destroy — Deletes every resource in the state, in reverse dependency order.
• dependency violation — AWS refuses to delete something because another object still uses it.
• drift — A difference between real AWS and the state, often from console changes.
• runbook — A short written list of steps that anyone on the team can follow.

Example 1: The full run as one runbook

At an L&T Infotech project, every lab and release follows the same runbook so a new joiner gets the same result as a senior.

1. init, fmt, validate.
2. plan -out tfplan.
3. apply tfplan.

terraform init
terraform fmt -check -recursive
terraform validate
terraform plan -out tfplan
terraform apply tfplan

Output

Apply complete! Resources: 27 added, 0 changed, 0 destroyed.

Outputs:

app_private_ip = "10.30.11.25"
db_endpoint = "hrportal-mysql.c1a2b3c4d5e6.ap-south-1.rds.amazonaws.com:3306"
web_url = "http://13.233.10.20"

What it shows: fmt -check fails the run if a file is not formatted. Good habit before CI does it for you.

Example 2: Smoke test script

A Myntra release engineer never says "it looks fine". A tiny script checks every tier and prints PASS or FAIL.

1. Read outputs.
2. Curl both paths.
3. Print PASS or FAIL per check.

#!/bin/bash
WEB=$(terraform output -raw web_url)
check() { if eval "$2" >/dev/null 2>&1; then echo "PASS $1"; else echo "FAIL $1"; fi; }
check "web page"  "curl -sf $WEB/ | grep -q 'web tier ok'"
check "api path"  "curl -sf $WEB/api/ | grep -q 'app tier'"
check "db private" "test \"$(aws rds describe-db-instances --db-instance-identifier hrportal-mysql --query 'DBInstances[0].PubliclyAccessible')\" = false"

Output

PASS web page
PASS api path
PASS db private

What it shows: Run it right after apply and again after any change. Three PASS lines means all tiers are healthy.

Example 3: Spot console drift before destroy

Someone may have added a rule in the console during testing. A refresh-only plan shows it before destroy surprises you.

1. Run a refresh-only plan.
2. Read any changes.
3. Decide: import, revert or ignore.

terraform plan -refresh-only

Output

No changes. Your infrastructure still matches the configuration.

What it shows: If it lists changes, somebody touched AWS by hand. Fix that first, or destroy may fail on extra objects.

Example 4: Destroy and confirm nothing is left

A forgotten NAT gateway or Elastic IP keeps billing. After destroy, ask AWS directly instead of trusting memory.

1. Run terraform destroy.
2. Check state is empty.
3. Query NAT gateways and EIPs.

terraform destroy -auto-approve
terraform state list | wc -l
aws ec2 describe-nat-gateways --filter Name=state,Values=available --query "length(NatGateways)"
aws ec2 describe-addresses --query "length(Addresses)"

Output

Destroy complete! Resources: 27 destroyed.
0
0
0

What it shows: Three zeros: empty state, no live NAT, no Elastic IP. Your bill is safe.

Example 5: Fix a stuck destroy

The classic stuck destroy: a console test instance still uses the VPC. Find it by VPC id and remove it.

1. Read the error.
2. List instances in the VPC.
3. Terminate the stray one and destroy again.

VPC=$(aws ec2 describe-vpcs --filters Name=tag:Name,Values=hrportal-vpc --query "Vpcs[0].VpcId" --output text)
aws ec2 describe-instances --filters Name=vpc-id,Values=$VPC Name=instance-state-name,Values=running \
  --query "Reservations[].Instances[].[InstanceId,Tags[?Key=='Name']|[0].Value]" --output table

Output

-------------------------------------
|         DescribeInstances         |
+----------------------+------------+
|  i-0stray9876543210f |  test-box  |
+----------------------+------------+

What it shows: test-box was made by hand. Terminate it (after checking with the owner), then run terraform destroy again.

Command cheat sheet

Verify: did it work?

1. Smoke test passes

   bash smoke.sh | grep -c PASS
   

   Output

   3
   

2. State empty after destroy

   terraform state list | wc -l
   

   Output

   0
   

3. No NAT left

   aws ec2 describe-nat-gateways --filter Name=state,Values=available --query "length(NatGateways)"
   

   Output

   0
   

When it is red 1

Error: Saved plan is stale: The given plan file can no longer be applied because the state was changed by another operation

Cause. State changed after the plan was saved.

Fix, step by step

1. Run terraform plan -out tfplan again.
2. Apply the new plan.

When it is red 2

curl: (7) Failed to connect to 13.233.10.20 port 80: Connection refused

Cause. nginx has not finished installing yet, or user_data failed.

Fix, step by step

1. Wait three minutes and retry.
2. Read /var/log/cloud-init-output.log on the web server.

When it is red 3

Error: deleting EC2 Subnet: DependencyViolation: The subnet 'subnet-0abc' has dependencies and cannot be deleted.

Cause. A hand-made resource (instance or ENI) is still in the subnet.

Fix, step by step

1. List ENIs with describe-network-interfaces filtered by subnet-id.
2. Remove the stray resource and destroy again.

Cleanup

terraform destroy -auto-approve
rm -f tfplan

Practice tasks

Homework: try at home

Recap

• Always apply a saved plan.
• Smoke test every tier with a script.
• Check drift before destroy.
• Confirm NAT and EIP are gone.
• Stray console resources block destroy.

FAQ

Why 27 resources?

Roughly 13 network resources, 3 security groups with their rules, 2 servers, the DB subnet group and RDS. Data sources such as the AMI lookup are not counted.

Can I keep RDS and destroy the rest?

Use -target only for emergencies; better split into separate stacks.

How long does destroy take?

About 10 minutes, mostly RDS and the NAT gateway.

Is -auto-approve safe?

In your own lab yes. In shared environments review the destroy plan first.

Interview questions

1. Why apply a saved plan?

   It applies exactly what was reviewed, nothing that changed later.

2. How do you check drift?

   terraform plan -refresh-only.

3. What causes DependencyViolation on destroy?

   Resources created outside Terraform still using the VPC or subnet.

4. How do you avoid cost after a lab?

   Destroy, then confirm no NAT gateway or Elastic IP remains.

Samajla ka?

Ravi Sir's Cards for this lesson

Revision cardInterview card

मराठी cards