What’s the cheapest practical way to deploy a Kubernetes microservices stack in the cloud?

Be careful with the assumption that destroying the compute resources automatically eliminates every charge. Public IP addresses, disks, snapshots, load balancers, registries, logs, and unused volumes can remain behind. Add Terraform outputs and cleanup steps, use budgets and billing alerts, apply strict resource requests and limits, and set log retention aggressively. A low-cost demo can also use a temporary DNS record or a tunnel instead of creating a permanent load balancer, depending on the security requirements.

Serverless platforms such as Cloud Run can be cheaper and easier for the application services, especially when they are idle, but they won’t teach you much about operating Kubernetes. Since your goal is explicitly to demonstrate Kubernetes and Terraform, a small k3s deployment or a short-lived managed Kubernetes cluster is more aligned with that goal. For a resume, showing the Terraform code, architecture decisions, teardown process, resource limits, persistent-volume handling, and documented limitations is often more valuable than claiming every component uses a managed service.

If Kubernetes itself is the learning objective, a single VM running k3s may be the cheapest and simplest starting point. You can install a lightweight ingress controller, expose one HTTP or HTTPS port, and avoid provisioning a cloud load balancer. That won’t provide the same experience as a highly available managed cluster, but it is honest to describe it as a cost-optimized single-node environment rather than production infrastructure.

If you specifically want EKS experience, use Terraform to create the cluster only for scheduled demos, keep the node group at the smallest practical size, and destroy everything afterward. Spot instances can reduce compute costs, but they can be interrupted, so they are better for disposable environments than for a reliable production setup.

For a project this large, the standard free tier on a single small cloud VM probably won’t have enough memory. Oracle’s Always Free resources may be worth investigating because they can provide more capacity than the smallest offerings from the major providers. Whichever provider you choose, keep the deployment in one cloud rather than spreading services across several providers; cross-cloud networking adds complexity without much benefit for a portfolio demo.

You can reduce the footprint substantially by consolidating the five logical databases onto one PostgreSQL server or PostgreSQL instance. Separate databases or schemas can still preserve service ownership without requiring five database servers. You should also question whether Kafka, Redis, and the full observability stack need to run at the same time for every demo. Running them in Kubernetes is completely valid for demonstrating Kubernetes skills, but explain the production tradeoffs: managed databases and messaging services usually reduce operational work, while in-cluster stateful services give you more hands-on experience with storage, backups, upgrades, and failure recovery.