Two failure modes show up when you need to add an app to an account that already runs something important. The first is the cowboy move: drop the new thing into the existing stack, share the load balancer, share the filesystem, and discover six months later that you can’t touch one app without risking the other. The second is the overreaction: spin up a whole new VPC with its own peering, its own NAT, its own everything, and hand yourself a second full network to maintain for one small service.
There’s a boring middle path, and it’s almost always the right one. Keep the shared VPC. Give the new app its own lane inside it. Isolation is about the resources that carry state and traffic, not about drawing a fresh network diagram from scratch.
What “its own lane” actually means
The VPC is shared plumbing: subnets, route tables, the internet gateway. That’s fine to share; it’s just where packets flow. What you do not share is anything that couples the two apps’ blast radius. Concretely, the new app gets its own:
- Application Load Balancer. Its own listener, its own TLS certificate, its
own target group. A bad deploy or a traffic spike on one app never touches the other’s front door.
- ECS service and task definition. Its own containers, its own scaling, its
own IAM task role. It cannot assume the other app’s permissions because it literally has a different role.
- EFS filesystem and access point. This is the big one. Shared storage is
the coupling people regret most. Separate filesystem, separate access point, separate mount. One app’s data is physically not reachable from the other.
- Secrets. Its own namespace in Secrets Manager or Parameter Store, its own
read policy. No accidental cross-reads.
Everything on that list is cheap to duplicate and expensive to untangle later. That asymmetry is the whole argument.
The isolation that matters is IAM, not network
The instinct is to reach for security groups and subnets to keep apps apart. Those help, but the isolation that actually holds is identity. Each ECS task runs under its own task role, and each role can read only its own secrets and mount only its own access point. Even if the two apps sit on the same subnet and can technically route to each other, neither can read the other’s data or assume the other’s rights.
# app A's task role can read only app A's secrets
{
"Effect": "Allow",
"Action": "secretsmanager:GetSecretValue",
"Resource": "arn:aws:secretsmanager:ap-southeast-2:111122223333:secret:appA/*"
}Scope the resource ARNs tightly and the boundary enforces itself. This is worth more than any amount of subnet gymnastics, and it’s easier to reason about when someone asks “can app A read app B’s data”, you point at the policy and the answer is right there.
EFS access points are the underrated part
If both apps genuinely need persistent files, resist the urge to carve out two directories on one filesystem. Give each its own filesystem with its own access point. An access point pins a POSIX user, group, and root directory, so the app sees a clean root and can’t wander. Separate filesystems also mean separate backup selections, separate throughput, and separate deletion. When you eventually retire one app, you delete its filesystem without a second thought about the other.
What you keep sharing, guilt-free
Sharing the VPC itself, the NAT gateway, and the internet gateway is fine and often smart: NAT gateways aren’t cheap, and running a second one for a single small app is the kind of waste that shows up on the bill later. Shared plumbing, separate lanes. The rule of thumb: share the things that only move packets, duplicate the things that hold state or grant access.
The boring conclusion
You don’t need a new VPC to isolate a new app, and you shouldn’t glue it into the existing stack either. Give it its own load balancer, service, task role, filesystem, and secrets inside the VPC you already run. The network stays simple, the blast radius stays contained, and the day you need to change or retire one app, you do it without holding your breath about the other. Isolation is an IAM and state-ownership problem wearing a networking costume.
Leave a Reply