Series Wrap-up and a Full Audit of Your AWS Account

This is the last article of the series. Each prior article had its own cleanup section, so in theory your account is already clean. This article does something different: a full self-audit of the account to be sure nothing is left behind, then a review of what you learned and suggestions for where to go.

Periodically auditing your own account is a skill worth having, not just while learning. A resource forgotten in a rarely-used region is a common cause of surprise bills.

Why you have to audit each region

Most AWS services operate per region and are isolated from each other. An EC2 you accidentally created in another region won't show up when you're viewing your familiar region. The console also only displays resources for the region selected in the top-right corner. So when auditing, you have to scan across regions, not just the one you usually use.

Some services are global (not tied to any region), like IAM and S3 (bucket names are global, even though the data lives in one region).

Step 1: Look at the cost overview

The quickest place to look is Billing and Cost Management.

• Open Billing and Cost Management > Bills to see the current month's cost, broken down by service and region. If any service is generating unexpected charges, this is the first place you'll see it.
• Open Cost Explorer and look at the cost chart by day. A cost line that suddenly goes flat at a non-zero level shows something is running continuously.
• If the account uses the credit model, open the Credits page to see how much credit is left and what it's being spent on.

The budget you created in Article 1 should still be there. If you don't have one, go back to Article 1 and recreate it — it's a long-term safety net.

Step 2: Scan for billable resources across regions

Below are commands to quickly scan for the resources that tend to cost money. Run them one region at a time for each region you've used. You can loop over multiple regions:

for REGION in ap-southeast-1 us-east-1 us-west-2; do
  echo "=== Region: $REGION ==="

  echo "-- EC2 instances (dang chay) --"
  aws ec2 describe-instances --region $REGION \
    --filters Name=instance-state-name,Values=running,pending \
    --query "Reservations[].Instances[].InstanceId" --output text

  echo "-- RDS instances --"
  aws rds describe-db-instances --region $REGION \
    --query "DBInstances[].DBInstanceIdentifier" --output text

  echo "-- Elastic IP chua gan (van tinh tien) --"
  aws ec2 describe-addresses --region $REGION \
    --query "Addresses[?AssociationId==null].PublicIp" --output text

  echo "-- EBS volume khong gan vao dau --"
  aws ec2 describe-volumes --region $REGION \
    --filters Name=status,Values=available \
    --query "Volumes[].VolumeId" --output text

  echo "-- NAT Gateway (tinh tien theo gio) --"
  aws ec2 describe-nat-gateways --region $REGION \
    --query "NatGateways[?State=='available'].NatGatewayId" --output text
done

Two things beginners often miss because they're "not servers" but still bill you:

• Unassociated Elastic IP: a static IP address not attached to any instance still incurs a charge. If you see one, release it with aws ec2 release-address.
• Orphaned EBS volume: a disk left behind after an instance was deleted improperly. If you're sure you don't need it, delete it with aws ec2 delete-volume.

Scan the global and near-global services:

# S3 buckets (global)
aws s3 ls

# ECR repositories (per region, check the region you used)
aws ecr describe-repositories --region ap-southeast-1 \
  --query "repositories[].repositoryName" --output text

# Remaining CloudWatch alarms
aws cloudwatch describe-alarms --region ap-southeast-1 \
  --query "MetricAlarms[].AlarmName" --output text

If all the commands above return empty (except things you deliberately kept), the account is clean of cost drivers.

Step 3: Basic security review

While you're at it, check a few security points:

• Old access keys: go to IAM > Users and look at the access keys. Delete or disable keys you no longer use (for example a key you created for learning). Static keys left around for a long time are a risk.
• MFA: confirm both your root and IAM user still have MFA enabled (from Article 1).
• Leftover IAM users/roles: delete roles created temporarily while learning that you no longer need (like the pipeline role in Article 7 if you haven't deleted it).

Reviewing what you learned

Across nine articles, you touched the entire basic lifecycle of a system on AWS:

• A safe foundation (Article 1): root with MFA, using an IAM user, with a cost alarm.
• Compute (Article 2): creating and using EC2.
• Network (Article 3): VPC, public/private subnets, Security Group, the principle of only opening what's needed.
• Storage (Article 4): S3 and static web hosting.
• Database (Article 5): RDS in a private subnet, only the application accesses it.
• Packaging (Article 6): Docker and ECR.
• Automation (Article 7): CI/CD with GitHub Actions, OIDC instead of static keys.
• Monitoring (Article 8): CloudWatch alarms and centralized logs.

A few principles recurred throughout, worth remembering:

• Least privilege: open only the ports needed, grant only enough permissions, put the database in private.
• Don't use static keys when you can avoid it: use IAM roles and OIDC.
• Clean up whatever you create: a habit that keeps the account clean and the bill small.

Where to learn next

This series stops at a basic level and does a lot manually. A few natural next steps:

• Infrastructure as Code: instead of typing commands or clicking around, describe the entire infrastructure with Terraform or AWS CDK. This is the most important upgrade, turning everything in the series into code you can rebuild from.
• Container orchestration: run containers at a larger scale with ECS or EKS (Kubernetes), instead of a manual docker run on a single EC2.
• Separate environments: stand up distinct environments (dev, staging, production) and a pipeline that deploys through each.
• Deeper security: write narrow IAM policies scoped to actual needs instead of using ready-made admin policies, and manage secrets with AWS Secrets Manager or SSM Parameter Store.
• Observability: dashboards, custom metrics, distributed tracing (X-Ray) to understand the system more deeply than a CPU alarm.

Each of these is enough for its own series. The foundation from these nine articles makes it easier to approach them, because you already understand the basic pieces they build on.

Final words

Thank you for following the whole series. If you followed along and cleaned up thoroughly, the cost of the entire learning process is nearly zero. Keep the habit of auditing your account periodically, and every time you try a new service, keep applying the same principle: clean up whatever you create.