I'm learning Amazon EKS and migrating an application from Docker Compose. I'm planning to use Amazon RDS for MySQL and want to understand the recommended production architecture. Should RDS remain outside the EKS cluster while backend Pods connect to it, or are there cases where running MySQL inside a Pod is appropriate? I'd also like guidance on securely managing database credentials and configuring network connectivity between EKS and RDS.
3 Answers
Store the credentials in AWS Secrets Manager and expose them to the workloads through External Secrets Operator or a similar integration. Avoid committing credentials to manifests or relying on a local .env file for production. For networking, use security groups and network policies so only the required application workloads can reach the RDS port, rather than allowing broad access from the entire network.
For production, keep MySQL outside the cluster and use Amazon RDS. Put the database in private subnets, ideally in the same VPC as EKS, and let the application connect through the RDS endpoint. RDS handles backups, patching, failover, and storage far more reliably than a database running in a regular Pod.
Place EKS and RDS in the same VPC, with appropriate private-subnet routing and DNS enabled. The RDS security group should allow MySQL traffic only from the security group associated with the worker nodes or, where applicable, the security group used by the Pods. Running MySQL in EKS can make sense for development, experiments, or teams that deliberately operate a database operator and accept the additional responsibility, but managed RDS is usually the simpler and more reliable production choice.
That makes sense—keeping the database managed separately sounds much safer than trying to handle persistence and recovery inside the cluster.