AWS Builder Center

Builder Center

What I Learned About AWS Costs While Building My First Cloud Projects.

Starting with AWS is exciting, but one of the first things I learned is that understanding cloud costs is just as important as learning how to deploy resources. Here are the practical lessons that helped me become more careful with AWS resources and avoid unexpected charges.

What I Learned About AWS Costs While Building My First Cloud Projects

When I started learning AWS, most of my attention was on building things.
I wanted to understand EC2, VPCs, Docker, networking, IAM, and eventually how all of these pieces fit into a DevOps workflow.
At first, I was mainly thinking about one question:
“How do I make this work?”
After spending more time working with AWS, I realized there was another question I needed to ask:
“What is this going to cost if I leave it running?”
That change in mindset has been one of the most useful lessons in my AWS learning journey.

Learning AWS Is Also Learning Resource Management

When you're following tutorials or building your first projects, it's easy to create resources without thinking too much about what happens afterward.
You create an EC2 instance.
Then you create a VPC.
Maybe you add a NAT Gateway.
You attach storage.
You experiment with networking.
Then you finish the tutorial and move on to something else.
The problem is that some resources don't simply disappear when you're finished with your experiment.
That's why I started treating resource cleanup as part of the project, rather than something optional.

1. Don't Assume That Everything Is Free

One of the first things I learned is that the AWS Free Tier doesn't mean that every AWS resource is completely free.
Free usage depends on the specific service, usage limits, account eligibility, and other conditions.
So before creating a resource, I try to understand:
  • What service am I creating?
  • Is it covered by Free Tier benefits?
  • What are the usage limits?
  • Can associated resources generate charges?
  • What happens if I exceed the included usage?
This sounds simple, but it can make a big difference when you're learning in a personal AWS account.

2. EC2 Isn't the Whole Story

When I first started learning EC2, I naturally focused on the instance itself.
But an EC2 environment can involve much more than the instance.
For example:
1
2
3
4
5
6
7
8
9
EC2 Instance
|
+-- EBS Volume
|
+-- Elastic IP
|
+-- Security Group
|
+-- Network Interface
Some of these resources may have different billing implications depending on their configuration and usage.
So now, whenever I finish an EC2 experiment, I don't just check whether the instance is running.
I also look at the resources associated with it.
That small habit has made AWS much easier to manage.

3. Be Careful With NAT Gateway

NAT Gateway was one of the AWS networking components that made me realize how important it is to understand architecture and pricing together.
A typical setup can look like this:
1
2
3
4
5
6
7
8
9
10
11
Internet
|
Internet Gateway
|
Public Subnet
|
NAT Gateway
|
Private Subnet
|
Private Resources
A NAT Gateway can be very useful when private resources need outbound internet access.
But if you're simply learning AWS and don't actually need one for your lab, creating it without understanding its pricing can be an unnecessary expense.
The important lesson for me was:
Don't create an AWS resource just because you see it in a production architecture. First understand why it is there and whether your current project actually needs it.

4. Check Your Region

AWS has multiple Regions, and it's surprisingly easy to forget where you created something.
You might create an EC2 instance while following one tutorial, switch Regions later, and then wonder why you can't find it.
I now try to keep my learning environment organized and pay attention to the Region whenever I create or troubleshoot a resource.
A simple habit is:
1
2
3
4
5
6
7
8
Before creating:
Check Region

While working:
Remember Region

After finishing:
Check resources in that Region
This is especially useful when you're working with multiple AWS services.

5. Don't Forget About Storage

Another thing I pay attention to now is storage.
For example, after working with EC2, it's worth checking whether there are EBS volumes or snapshots that you no longer need.
The important point isn't to delete everything blindly.
Instead:
Understand → Verify → Clean up
If you know that a resource is no longer required, then remove it according to your project's needs.

6. When You See a Charge, Investigate It

If you notice an unexpected AWS charge, the first reaction can be:
“Where did this come from?”
I've learned that the best approach is not to start deleting resources randomly.
Instead, investigate step by step.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Unexpected charge
↓
Check billing information
↓
Identify the service
↓
Check the Region
↓
Review resource usage
↓
Find the resource responsible
↓
Decide whether it is required
↓
Clean up if appropriate
This approach is much more useful than simply guessing.
It also teaches you something important about AWS:
Billing information is part of understanding your infrastructure.

7. Cost Awareness Is a DevOps Skill

This is probably the biggest lesson I've taken from the experience.
When learning DevOps, we usually focus on tools:
  • Git
  • Docker
  • Jenkins
  • Ansible
  • Terraform
  • Kubernetes
  • AWS
  • Prometheus
  • Grafana
But knowing the tools isn't enough.
A good DevOps engineer also needs to think about:
1.Security
2.Reliability
3.Automation
4.Scalability
5.Performance and Cost
For example, Terraform can make it extremely easy to create infrastructure.
That's powerful.
But automation doesn't automatically mean that the infrastructure is cost-efficient.
If you automate the creation of resources without understanding their purpose and lifecycle, you can also automate unnecessary spending.

My Simple AWS Cleanup Routine

I've started following a simple routine whenever I finish an AWS experiment.

Before I leave the AWS Console, I check:

EC2
Are there any instances still running that I don't need?
EBS
Are there unused volumes or snapshots?
Networking
Did I create resources that I no longer require?
Databases
Are any test databases still running?
S3
Did I upload anything that I no longer need?
Billing
Does the recent usage look as expected?
It only takes a few minutes, but it gives me much more confidence when experimenting with AWS.

What I Would Tell Someone Starting AWS

If you're just starting with AWS, don't be afraid of experimenting.
Breaking something and fixing it is actually one of the best ways to learn.
But try to develop one habit from day one:
Know what you created. Know why you created it. Know how long you need it.
Don't just learn how to launch an EC2 instance.
Learn what is connected to it.
Don't just learn how to create a VPC.
Understand the networking components inside it.
Don't just learn how to deploy an application.
Understand what resources continue running after the deployment.
And don't wait until you see a bill to start thinking about cost.

Final Thoughts

My AWS journey is still ongoing, and I'm continuing to learn technologies such as Docker, Ansible, Terraform, Kubernetes, and CI/CD.
But one thing I've started to understand is that becoming a cloud engineer isn't simply about knowing more AWS services.
It's about learning how to make better decisions with those services.
For me, AWS cost management is not a separate topic anymore.
It's part of learning cloud engineering.
And the mindset I'm trying to follow is simple:
Build it. Understand it. Monitor it. Clean it up. Then build something better.
# cost-optimization# aws-free-tier# devops# cloud-operations# student-builders
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article