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 the database run separately outside the Kubernetes cluster while backend Pods connect to it, or are there situations where running MySQL inside a Pod is reasonable? I'd also like advice on securely managing database credentials and configuring network connectivity between EKS and RDS.
3 Answers
Running MySQL in a Pod can work for development, testing, or a carefully managed self-hosted setup, but it adds responsibility for storage, backups, replication, upgrades, failover, and recovery. For most production applications, RDS is the simpler and safer choice. If you do run a stateful database in Kubernetes, use a mature database operator and make sure you understand its backup and disaster-recovery behavior.
Put EKS and RDS in the same VPC, with suitable private subnet routing and security groups. The application can then connect using the RDS endpoint. Configure the RDS security group to accept traffic only from the specific EKS security group rather than broadly allowing the node subnet or VPC CIDR.
For production, keep MySQL outside the cluster and use Amazon RDS. Place the RDS instance in private subnets, then allow connections only from the appropriate EKS worker-node or workload security group on the MySQL port. Store the credentials in AWS Secrets Manager and use something like External Secrets Operator to make them available to Kubernetes workloads. Avoid relying on plain .env files for production secrets.
External Secrets Operator is much cleaner than manually copying values into Kubernetes Secrets, and it keeps the source of truth in Secrets Manager.