Multi-Account Configuration for EKS

When you are a small startup, working in a Single AWS Account is easy. But as you grow; keeping development (Dev), test (Stage), and live (Prod) environments in the same account becomes risky. A developer might accidentally delete the Prod database, or a resource in the Dev environment might fill the Quota and affect Prod.

Solution: Multi-Account architecture with AWS Organizations.

Account Separation Strategy

Open a separate AWS account for each environment:

1. Workload - Prod: EKS cluster receiving only live customer traffic. Access is very restricted.
2. Workload - NonProd: Dev and Staging clusters. Developers have broader permissions.
3. Shared Services: Common services like ECR (Container Registry), CI/CD tools (Jenkins), and VPN reside here.

Cross-Account Access Between EKS and ECR

Your images are in ECR in the Shared Services account, but EKS runs in the Prod account. How will EKS pull that image?

• ECR Policy: Add a rule to the ECR repository policy granting ecr:BatchGetImage permission to the Prod account ID.
• This way, you can use a central registry without copying images.

This structure limits the "Blast Radius". Even if the Dev account is hacked, the attacker cannot access the Prod account. We always set up this structure for our enterprise customers in our AWS Consultancy service.