Building a cloud-native application on AWS is a great way to learn Kubernetes, Infrastructure as Code, and cloud operations.
But there is one question that deserves attention from the very beginning:
How much does it actually cost to run the architecture?
For my LibraryCorner project, I designed an AWS architecture around Amazon EKS, managed PostgreSQL, load balancing, monitoring, and Terraform.
The goal was not just to deploy an application. It was to build an environment that reflects common cloud engineering practices while understanding the infrastructure and operational costs behind it.
In this article, I’ll break down the estimated monthly cost of this architecture, explain the main cost drivers, and share a few lessons about keeping cloud spending under control.
Note: The figures below are indicative estimates for planning purposes, not actual billing data or a guaranteed AWS quote. Actual costs depend on the AWS Region, resource sizes, usage, and pricing options.
1. The architecture behind the estimate
LibraryCorner uses several AWS services to support a containerized application.
The main components include:
- Amazon EKS to orchestrate the application containers.
- Amazon EC2 for the Kubernetes worker nodes.
- Amazon RDS for PostgreSQL for managed relational data, with a Multi-AZ configuration in production.
- Application Load Balancer (ALB) to route external traffic to the application.
- Amazon VPC for networking.
- Amazon ECR to store container images.
- Amazon CloudWatch and a Prometheus/Grafana stack for observability.
- AWS KMS and Secrets Manager for encryption and secrets management.
Terraform manages the infrastructure, while Kustomize handles environment-specific Kubernetes configuration.
This architecture introduces several independent cost categories. Some are directly related to compute, while others come from networking, managed services, and operational tooling.
2. The estimated monthly budget
For this architecture, I use an indicative planning budget of approximately $133 per month.
Here is an illustrative allocation of that budget:
| Cost category | Estimated monthly budget |
|---|---|
| Amazon EKS | $73 |
| EC2 worker nodes | $15 |
| Amazon RDS for PostgreSQL | $25 |
| Application Load Balancer | $10 |
| Networking and data transfer | $5 |
| Storage, monitoring, and supporting services | $5 |
| Total | $133/month |
These figures are a simplified budget allocation, not a service-by-service AWS price calculation. They should not be interpreted as a verified quote: the actual cost of each component can vary significantly with the selected Region, instance types, storage configuration, traffic, and monitoring setup.
The purpose of this breakdown is to identify the categories to investigate when estimating a cloud architecture, rather than to predict an exact invoice.
3. Why Kubernetes infrastructure can be expensive
One important lesson is that running Kubernetes involves more than paying for compute resources.
Amazon EKS has a cluster management fee, separate from the EC2 instances or other compute resources used by the workloads.
Worker nodes add another cost, even when the application receives little traffic. If the cluster runs continuously, the underlying infrastructure can continue generating charges while the application is idle.
This leads to a practical question:
Do I need a continuously running Kubernetes cluster for every development and testing activity?
Not necessarily.
For a learning project, it is worth considering whether the environment needs to run 24/7. Creating resources only when needed and deleting them afterward can help reduce costs, provided that persistent data and recovery requirements are handled carefully.
4. The hidden cost of networking and managed services
Compute is only part of the picture.
Several supporting services can contribute to the monthly bill:
- Load balancing: An Application Load Balancer can incur hourly and usage-based charges.
- Networking: Public IPv4 addresses, NAT gateways, and data transfer can add costs. A NAT gateway, in particular, deserves attention in a small environment.
- Database availability: RDS Multi-AZ improves availability, but generally costs more than a comparable Single-AZ deployment.
- Observability: Log ingestion, retention, metrics, and monitoring services can generate additional charges.
- Container storage and secrets: ECR storage, KMS requests, and Secrets Manager usage may contribute smaller amounts.
These costs are easy to overlook when focusing mainly on EC2 instance prices.
For this reason, I recommend estimating the entire architecture before deployment rather than calculating only the cost of the worker nodes.
5. Production-like architecture versus a learning budget
There is an important distinction between learning how production architectures work and operating a production system.
For LibraryCorner, using components such as RDS Multi-AZ, an Application Load Balancer, and Kubernetes autoscaling helps explore real cloud engineering concerns.
However, a production-like architecture does not automatically mean that every resource is necessary at all times.
For example:
- A development environment may not need Multi-AZ database deployment.
- A test cluster may be created only for specific exercises.
- Monitoring retention can be adjusted to match the project's needs.
- Resource requests and limits can help avoid unnecessary capacity.
- Unused load balancers, volumes, addresses, and other resources should be reviewed regularly.
These decisions involve trade-offs. Reducing costs should not mean ignoring availability, security, or the learning objectives of the project.
The right configuration depends on whether the priority is realistic production design, experimentation, or minimizing the cost of a portfolio project.
6. How I would approach AWS cost optimization
My approach is to make cost management part of the infrastructure workflow, rather than something to consider only after deployment.
First, estimate before provisioning.
AWS pricing tools can help compare configurations before resources are created. The estimate should include managed-service fees, compute, storage, networking, and expected usage.
Second, monitor actual spending.
AWS Cost Explorer helps identify spending trends and service-level cost drivers. AWS Budgets can provide alerts when spending reaches a defined threshold.
Third, review idle resources.
Unused environments, unattached volumes, obsolete load balancers, and unnecessary public IPv4 addresses can create avoidable expenses.
Fourth, right-size the infrastructure.
CPU and memory utilization can help determine whether worker nodes or application resource requests are larger than necessary. Kubernetes autoscaling should be configured with an understanding of its limits and the minimum infrastructure required.
Finally, separate development and production requirements.
Not every environment needs the same availability, capacity, or retention settings. Documenting these differences makes cost decisions easier to understand and reproduce.
7. What I learned from this project
Building LibraryCorner reinforced an important lesson: cloud architecture is not just about making an application run. It is also about understanding the operational consequences of every design choice.
Managed services simplify operations, but they have costs. High availability improves resilience, but it requires additional resources. Observability improves troubleshooting, but monitoring data also needs to be managed.
Terraform makes infrastructure reproducible, but reproducibility alone does not make it inexpensive.
For me, cost awareness belongs alongside security, reliability, performance, and maintainability when designing cloud infrastructure.
A useful cloud engineer should be able to explain not only why a service was selected, but also what it contributes and what it costs.
Conclusion
An indicative budget of $133 per month provides a useful starting point for discussing the cost of a Kubernetes-based AWS architecture such as LibraryCorner.
The exact amount will depend on the deployment configuration, Region, and usage patterns. The more important lesson is to identify cost drivers early, monitor spending continuously, and choose infrastructure according to the environment's actual requirements.
For anyone building a cloud portfolio project, cost estimation is a valuable part of the engineering process — not an afterthought.
What is your approach to controlling AWS costs in personal projects? Do you prioritize production-like architecture, minimizing spending, or finding a balance between the two?
Top comments (0)