Building a Private VPC, Kubernetes Cluster & EFS on AWS
Here’s another relatively simple process ( shell script ) that will build a service, complete with its own VPC, subnets both public and private, Kubernetes cluster along with an EFS server to support a persistent data storage function. I’ll also supply some of the AWS documentation URL’s so we can have some reference to where this is all coming from.
The shell script that can be run from the command line, it creates a complete private VPC/Subnets/Kubernetes Cluster/Elastic File Server and several supporting IAM policies/roles as well as a few other random services, resulting in an end-to-end containerized application utilizing these AWS services:
IAM ( for creating accounts/roles for various services )
ELB ( alb load balancer )
EKS ( Elastic Kubernetes Service using Fargate )
EFS ( Elastic File Services )
The full script and supporting IAM policy definitions aren’t published in a public repo yet — reach out if you’d like a walkthrough for your own environment.
So fill in the variables to match your local environment and then launch it to create your complete services.
Why This Architecture
The private/public subnet split keeps worker nodes and application traffic off the public internet entirely, while a load balancer in the public subnet handles inbound requests — a standard, defensible security posture for anything holding real data. Running EKS on Fargate removes the need to patch and scale EC2 worker nodes yourself; you pay per pod, and AWS handles the underlying compute. EFS fills the gap Kubernetes’ ephemeral pod storage leaves open — any pod that needs to read or write data that survives a restart or gets shared across replicas needs a persistent volume, and EFS’s NFS-backed, multi-AZ design handles that without you standing up and managing your own file server.
Before You Run It
Check your AWS account’s service quotas ahead of time — EKS clusters, NAT gateways, and EIPs all have default limits that a fresh account can hit unexpectedly. Also confirm which IAM permissions the executing user/role needs; creating VPCs, IAM roles, and an EKS cluster in one script means the identity running it needs fairly broad (though scoped) permissions across all four services. Run it in a sandbox or dev account first if you haven’t reviewed the script end-to-end — it’s far easier to tear down a throwaway account than to unwind partially-created production infrastructure.
Once it’s running cleanly in a sandbox, promoting the same script to a production account with tightened IAM scoping is a far safer path than debugging a partially-applied change directly against live infrastructure. Treat the sandbox run as your integration test, not an optional step to skip when you’re confident the script is correct.
Feel free to comment and let me know how it goes.
Good luck!