DEV Community: Krembo Vitman

AWS Portfolio Projects That Actually Teach Real Infrastructure

Krembo Vitman — Sat, 22 Aug 2026 10:03:16 +0000

Some AWS portfolio projects look good in a README but do not teach much about
production infrastructure.

The better projects force you to answer practical questions:

What can break?
What costs money every month?
Who can access it?
How would I monitor it?
How would I safely remove it later?

Here are project ideas that teach those habits.

Disclosure: Some links may be affiliate links. I only include resources that fit
the topic.

1. Cloud Bill Cleanup Report

Build or run a read-only scanner that finds common wasted AWS resources:

unattached EBS volumes
old snapshots
unused Elastic IPs
idle NAT gateways
forgotten load balancers

This is a strong portfolio project because it connects AWS APIs, IAM,
CloudWatch, regions, and cost awareness.

I built a small tool for this:

Free repo:
https://github.com/byanivb/aws-waste-finder?utm_source=devto&utm_medium=post&utm_campaign=product2_portfolio_projects

Paid starter bundle:
https://basilian1.gumroad.com/l/aws-waste-finder?utm_source=devto&utm_medium=post&utm_campaign=product2_portfolio_projects

The key lesson is not "delete everything." The key lesson is learning how to
verify ownership, dependencies, traffic, backups, and rollback risk before
removing anything.

2. Cloud Resume Challenge

The Cloud Resume Challenge is still useful because it combines many real AWS
pieces into one small product:

static hosting
DNS
HTTPS
Lambda or serverless logic
a database
CI/CD
IAM permissions

Guidebook:
https://forrestbrazeal.gumroad.com/l/cloud-resume-challenge-book?a=93367907&utm_source=devto&utm_medium=post&utm_campaign=product2_portfolio_projects

The important part is finishing the loop: deploy it, document it, and explain
what could cost money if it was left running.

3. Read-Only IAM Role for Automation

Create a role that allows inspection but not cleanup.

Then document:

which APIs are allowed
which APIs are intentionally denied
how to test the role
how CloudTrail records the activity

This project is small, but it shows mature judgment. A lot of real automation
should start read-only.

4. NAT Gateway Dependency Map

NAT gateways are expensive enough to be worth understanding.

Build a script or diagram that maps:

NAT gateways
subnets
route tables
private workloads
CloudWatch traffic

Then explain how you would decide whether a NAT gateway is safe to remove.

This teaches VPC routing better than most abstract tutorials.

5. Snapshot Retention Cleaner

Create a report that lists old EBS snapshots and groups them by owner, age, and
likely purpose.

Do not auto-delete them at first.

A good portfolio version includes:

age buckets
volume references
AMI references
owner tags
a manual approval checklist

Storage cleanup is easy to automate badly. Showing the safety checks matters.

What Makes These Projects Better

The best AWS portfolio projects do not just prove you can create cloud
resources. They prove you can operate them.

For each project, add a short section to the README:

Monthly cost estimate
Security model
Failure modes
Cleanup steps
What you would monitor

That turns a toy project into evidence of real infrastructure thinking.

Final Thought

If you want AWS projects that teach production habits, start with the bill,
permissions, and cleanup path.

Every useful cloud system has a lifecycle: create it, run it, observe it, pay
for it, and eventually remove it safely.

Best AWS Learning Resources After You Clean Up Your Cloud Bill

Krembo Vitman — Wed, 05 Aug 2026 17:35:10 +0000

Cleaning up AWS waste is a great first step, but it also teaches you where your
cloud knowledge is thin.

When you find an unattached EBS volume, an idle NAT gateway, an unused Elastic
IP, or old snapshots, you are not just saving money. You are seeing real
infrastructure decisions that someone forgot to finish.

This post is a practical path for what to learn next.

Disclosure: Some links may be affiliate links. I only include tools or resources
that fit the topic.

Start With the Bill

Most AWS learning paths start with service names:

EC2
S3
IAM
VPC
Lambda
DynamoDB

That is useful, but the bill shows you what matters in production.

If a small account has a surprising monthly cost, the cause is often something
concrete:

a NAT gateway left running
an Elastic IP that is no longer attached
old EBS volumes
old snapshots
oversized storage
logs or backups retained forever

Those are better learning prompts than abstract tutorials because they connect
AWS services to operational behavior.

Resource 1: A Cost Cleanup Scanner

Before studying more AWS, scan your own account in read-only mode and make a
short list of things to understand.

I built AWS Waste Finder for this exact loop:

python3 aws_waste_finder.py --profile default --all-regions --format html --output report.html

It checks common AWS waste signals and generates Markdown, JSON, or HTML
reports.

Free repo:
https://github.com/byanivb/aws-waste-finder?utm_source=devto&utm_medium=post&utm_campaign=product2_learning_resources

Paid starter bundle:
https://basilian1.gumroad.com/l/aws-waste-finder?utm_source=devto&utm_medium=post&utm_campaign=product2_learning_resources

Use the report as a study guide. For each finding, ask:

Why does this resource exist?
What other resources depend on it?
What would break if it disappeared?
How would I verify that safely?

That is how AWS stops being a list of icons and starts becoming a system.

Resource 2: The Cloud Resume Challenge

If you want a structured AWS project after cleanup work, the Cloud Resume
Challenge is a good next step.

It usually touches several real-world pieces:

static hosting
DNS
HTTPS
serverless functions
databases
CI/CD
IAM permissions

The paid guidebook is here:
https://forrestbrazeal.gumroad.com/l/cloud-resume-challenge-book?a=93367907

Why I like this kind of project: it forces you to build something small but
complete. That is much better than clicking around one AWS service at a time.

Resource 3: IAM and Least Privilege

After you scan for waste, learn IAM next.

Cost cleanup is full of permission questions:

Can this scanner run read-only?
Which API calls does it need?
Who is allowed to delete resources?
Should cleanup be manual, automated, or approval-based?

For your first pass, learn:

users vs roles
managed policies vs inline policies
read-only policies
sts get-caller-identity
CloudTrail basics

Do not start by giving every tool admin access. A boring read-only role is a
better habit.

Resource 4: VPC Basics

NAT gateway findings are a signal that you should understand VPC networking.

Learn:

public vs private subnets
route tables
internet gateways
NAT gateways
security groups
network ACLs

Before deleting a NAT gateway, always check route table usage and traffic. A
quiet NAT gateway might still support a private workload that only runs once a
day.

Resource 5: Terraform or OpenTofu

Once you understand the resources, learn infrastructure as code.

The useful idea is not just "write Terraform." The useful idea is that your
cloud should have a reviewable source of truth.

Start with:

variables
outputs
state
modules
importing existing resources
plan before apply

This also makes cost cleanup safer because you can see whether a resource was
created intentionally or by accident.

Resource 6: DynamoDB or One Managed Database

Do not try to learn every AWS database at once.

Pick one managed database and go deeper.

DynamoDB is a good choice for AWS developers because it teaches:

access patterns
partition keys
sort keys
indexes
capacity modes
backups
operational limits

Even if you do not use DynamoDB every day, learning one AWS database deeply
will make the others easier to reason about.

A Simple 7-Day Path

If you want a practical sequence:

Run a read-only cost scan.
Pick one finding and understand every dependency around it.
Learn the IAM permissions needed to inspect it.
Learn the VPC or storage concept behind it.
Build one small AWS project.
Put that project in GitHub.
Write down what you would monitor and what could cost money.

That path is small enough to finish, but real enough to matter.

Final Thought

AWS cost cleanup is not separate from AWS learning.

It is one of the fastest ways to learn what real infrastructure is doing,
because every wasted dollar points back to a resource, a dependency, and a
decision.

Start with the bill, then learn the system behind it.

How to Find AWS NAT Gateway Waste

Krembo Vitman — Tue, 04 Aug 2026 20:38:54 +0000

NAT gateways can become one of the most expensive "forgotten" AWS resources.
They charge hourly, and they also charge for data processing.

This guide shows how to find NAT gateways that deserve review.

Why NAT Gateways Are Expensive

A NAT gateway may be needed for private subnets to reach the internet. But old
test environments, retired VPCs, and low-traffic workloads often leave NAT
gateways running long after they are useful.

Even a single NAT gateway can cost meaningful money every month before data
processing charges.

List NAT Gateways

Run this in one region:

aws ec2 describe-nat-gateways \
  --region us-east-1 \
  --filter Name=state,Values=available \
  --query 'NatGateways[].{NatGatewayId:NatGatewayId,VpcId:VpcId,SubnetId:SubnetId,State:State}' \
  --output table

With a profile:

aws ec2 describe-nat-gateways \
  --profile production \
  --region us-east-1 \
  --filter Name=state,Values=available \
  --query 'NatGateways[].{NatGatewayId:NatGatewayId,VpcId:VpcId,SubnetId:SubnetId,State:State}' \
  --output table

Check All Regions

for region in $(aws ec2 describe-regions --query 'Regions[].RegionName' --output text); do
  echo "Region: $region"
  aws ec2 describe-nat-gateways \
    --region "$region" \
    --filter Name=state,Values=available \
    --query 'NatGateways[].{NatGatewayId:NatGatewayId,VpcId:VpcId,SubnetId:SubnetId,State:State}' \
    --output table
done

Check Route Table Usage

Before considering cleanup, inspect routes that point to the NAT gateway:

aws ec2 describe-route-tables \
  --region us-east-1 \
  --filters Name=route.nat-gateway-id,Values=nat-0123456789abcdef0 \
  --query 'RouteTables[].{RouteTableId:RouteTableId,VpcId:VpcId,Routes:Routes}' \
  --output json

If route tables still point 0.0.0.0/0 at the NAT gateway, deleting it can
break internet access from private subnets.

Check Traffic

Use CloudWatch metrics before making any decision. Look at bytes in/out and
packet drops over a meaningful window, such as 14 or 30 days.

Low traffic does not always mean unused, but it tells you where to investigate.

Safe Cleanup Order

If you confirm a NAT gateway is unnecessary:

Update or remove route table references.
Verify no route table points at the NAT gateway.
Delete the NAT gateway.
Wait for deletion to finish.
Decide separately whether to release the Elastic IP.

The Elastic IP may have separate external dependencies.

Easier Option

AWS Waste Finder flags running NAT gateways and puts them at the top of the
report because they have high cost potential.

Free repo:
https://github.com/byanivb/aws-waste-finder

Paid starter bundle:
https://basilian1.gumroad.com/l/aws-waste-finder

How to Find Old EBS Snapshots Costing Money in AWS

Krembo Vitman — Tue, 04 Aug 2026 20:32:29 +0000

Old EBS snapshots are a common AWS storage leak. A snapshot may only cost a few
dollars per month, but stale snapshots across regions and accounts can quietly
pile up.

This guide shows how to find old snapshots safely.

Why Old Snapshots Matter

EBS snapshots are incremental, but they still store changed blocks. Keeping old
snapshots forever can create long-term storage cost, especially when snapshots
come from retired instances, old migrations, or abandoned backup jobs.

AWS CLI Command

List snapshots owned by your account:

aws ec2 describe-snapshots \
  --owner-ids self \
  --region us-east-1 \
  --query 'Snapshots[].{SnapshotId:SnapshotId,StartTime:StartTime,VolumeSize:VolumeSize,Description:Description}' \
  --output table

Find Snapshots Older Than 90 Days

You can use jq for a more precise local filter:

cutoff=$(date -u -v-90d '+%Y-%m-%dT%H:%M:%S')

aws ec2 describe-snapshots \
  --owner-ids self \
  --region us-east-1 \
  --output json |
jq -r --arg cutoff "$cutoff" '
  .Snapshots[]
  | select(.StartTime < $cutoff)
  | [.SnapshotId, .StartTime, .VolumeSize, .Description]
  | @tsv
'

On Linux, replace the date command with:

cutoff=$(date -u -d '90 days ago' '+%Y-%m-%dT%H:%M:%S')

Check All Regions

Snapshots are regional:

for region in $(aws ec2 describe-regions --query 'Regions[].RegionName' --output text); do
  echo "Region: $region"
  aws ec2 describe-snapshots \
    --owner-ids self \
    --region "$region" \
    --query 'Snapshots[].{SnapshotId:SnapshotId,StartTime:StartTime,VolumeSize:VolumeSize}' \
    --output table
done

Before You Delete a Snapshot

Do not delete old snapshots blindly.

Check:

whether the snapshot backs an AMI
retention policies
compliance or audit requirements
disaster recovery plans
whether it was created before a risky migration or upgrade

If a snapshot backs an AMI, deregistering or deleting things in the wrong order
can break restore workflows.

Easier Option

AWS Waste Finder finds owned EBS snapshots older than your configured threshold
and estimates the monthly snapshot storage cost.

Free repo:
https://github.com/byanivb/aws-waste-finder

Paid starter bundle:
https://basilian1.gumroad.com/l/aws-waste-finder

How to Find Unused Elastic IPs in AWS

Krembo Vitman — Tue, 04 Aug 2026 20:31:56 +0000

Unused Elastic IPs are one of the easiest AWS cost leaks to miss. They look
small, but they keep billing while they are allocated and not attached to a
running resource.

This guide shows how to find them safely.

What Is an Unused Elastic IP?

An Elastic IP is likely unused when it has no AssociationId.

That means AWS has allocated the public IP to your account, but it is not
currently associated with an EC2 instance, NAT gateway, network interface, or
other resource.

AWS CLI Command

Run this for one region:

aws ec2 describe-addresses \
  --region us-east-1 \
  --query 'Addresses[?AssociationId==null].[AllocationId,PublicIp]' \
  --output table

Run it with a profile:

aws ec2 describe-addresses \
  --profile production \
  --region us-east-1 \
  --query 'Addresses[?AssociationId==null].[AllocationId,PublicIp]' \
  --output table

Check All Regions

Elastic IPs are regional, so check every enabled region:

for region in $(aws ec2 describe-regions --query 'Regions[].RegionName' --output text); do
  echo "Region: $region"
  aws ec2 describe-addresses \
    --region "$region" \
    --query 'Addresses[?AssociationId==null].[AllocationId,PublicIp]' \
    --output table
done

Before You Release an Elastic IP

Do not release an IP just because it is unattached.

First check:

DNS records
customer allowlists
partner allowlists
firewall rules
webhook documentation
old deployment or rollback notes

Some public IPs are referenced outside AWS, so AWS cannot tell you every
dependency.

Easier Option

AWS Waste Finder scans for unassociated Elastic IPs and includes them in a
Markdown, JSON, or HTML report.

Free repo:
https://github.com/byanivb/aws-waste-finder

Paid starter bundle:
https://basilian1.gumroad.com/l/aws-waste-finder