shared vpc created by copilot

[erpadmin]

are there any gotchas to this approach?
create the first app with default setup, vpc, subnets, etc
create second app, but import vpc and subnets created from the first step

intent is to have two separate copilot managed apps, their code in seperate git repos, their build process independent, but having them in the same vpc where they can communicate with common ec2 services or between each other easily

I have no concerns about over consuming IP's

I am thinking this would mainly be 2 independent Cloud Formation stacks (only one with the vpc, subnet configuration) and they wont be able to conflict because naming is different between the apps.

[Caio-Domingos]

👋 Hey there! You asked about the potential pitfalls of creating two separate Copilot managed apps in the same VPC. Here's a quick rundown:

Sharing a VPC and Subnets

• Cool Feature: Both apps can chat easily and use the same EC2 services. Super handy for direct communication.
• Keep in Mind: You'll need to think a bit about security. They're sharing space, so setting up clear access rules is a good idea.

Independent CloudFormation Stacks

• Good News: Each app gets its own stack. So, changing one app won't mess with the other. It's like having two separate play areas!
• Naming is Key: Make sure each app has a unique name. It's like naming twins - it helps to tell who's who!

Potential Concerns

• Security Checks: Since they're in the same VPC, you'll want to double-check security settings. It's like making sure both apps play nice in the sandbox.
• Watching Resources: No worries about IP addresses, but keep an eye on other resources. Just to make sure everything runs smoothly.
• Talk to Each Other: If one app needs a change in the VPC setup, it might affect the other. So, a little coordination is important.

🌟 In a Nutshell: Your plan sounds solid. It's a great way to have two separate but friendly apps. Just keep an eye on the shared space and communication!

[iamhopaul123]

Thanks @Caio-Domingos for the great answer! For the security concern, it can be mitigated by the fact that each environment gets its own security group, which ensures services deployed to one environment cannot be accessed by other envs in the shared VPC by default.

[Caio-Domingos]

Absolutely, you're spot on with the security groups. That's a great way to ensure isolation between environments in the shared VPC. Thanks for pointing that out!

And hey, I just realized it was you, not the original poster, who replied. Haha, my bad!