I'm managing two environments with very different setups: development runs on EC2, while production runs on Amazon EKS. That difference creates extra maintenance work and makes it difficult to test production changes confidently before deployment.
I could create a UAT or staging EKS cluster for load testing and production preparation, but the additional cost is becoming a problem. The clients initially requested that setup and are now concerned about the bill, so I'm looking for a practical way to keep the environments reasonably consistent without spending more than necessary.
Production uses EKS because multiple applications will share the cluster, and we rely on Kubernetes features such as scaling and deployments. What approach would you use for development, staging, and performance testing in this situation?
5 Answers
The EKS control-plane cost is usually small compared with the operational time spent supporting two unrelated environments. If production depends on Kubernetes features, trying to avoid Kubernetes entirely in development may save some infrastructure money while creating much more troubleshooting and maintenance work.
I’d quantify both the AWS bill and the engineering hours. If the cost difference is only a modest amount, using a smaller always-on Kubernetes environment may be the simpler and cheaper option overall.
A staging environment should generally resemble production, but it can be smaller. The important part is keeping the application packaging and deployment process identical. Containerize the workloads and use the same manifests or templates across environments, with differences limited to capacity, replicas, and environment-specific settings.
The data side needs extra care. Don’t copy more production data into development than necessary, and use sanitized or synthetic data wherever possible.
You probably don’t need a full-time UAT cluster. Automate the entire environment deployment so the test environment is created only when you need load testing or release validation, then tear it down afterward. That limits the cost to the time the infrastructure is actually running.
For ordinary development, use a smaller and more disposable cluster. Keep performance testing separate and run it only on demand.
You can also use a lightweight local or shared Kubernetes environment for most development, then create a cloud-based EKS environment only for integration and load testing. That gives developers the right deployment model without paying for a second production-sized cluster around the clock.
The key is to make infrastructure reproducible with automation. Whether the environment is local, small, or production-sized, it should be created from the same source definitions and differ only through explicit configuration.
The biggest issue is the mismatch between EC2 and EKS. Development should use the same deployment model as production, even if it runs at a much smaller scale. Otherwise, you end up spending engineering time maintaining two different platforms and discovering environment-specific problems late.
An inexpensive Kubernetes distribution such as k3s or k0s could provide a closer development setup. It won’t reproduce production capacity, but it can preserve the same container, deployment, service, and configuration patterns.
The reason production uses EKS is that we plan to host multiple applications in one cluster and rely on Kubernetes for scaling and deployments, so a single smaller EC2 instance wouldn’t provide an equivalent setup.