Copilot-cli: Adding more than 1 copilot environment for an existing VPC fails

[kunteng]

Hi, I'm trying to initialize 2 copilot environments in the same existing VPC and I receive an error during the creation of the second one. Here is what the CloudFormation Error looks like:

From my understanding, it comes from the fact that copilot activates ServiceDiscovery using the namespace format {app name}.local, hence the conflict when trying to create a second environment. I managed to bypass the problem by updating the CF templates of my environments to use the format ${AppName}-${EnvironmentName}.local.

I am wondering :

• would it make sense to include the EnvironmentName in the default format of the ServiceDiscovery domain as I did ?
• does copilot rely on the {app name}.local format meaning that I might experience troubles in the future ?
• would it make sense to propose the ServiceDiscovery implementation optional in copilot (in my case, I don't plan to make my services communicate with each other) ?

Thank you for your work, help & advices,

Regards,

[efekarakus]

Oooh this is interesting, thanks for sharing your workaround!

You should be safe with the change you've made. Copilot doesn't depend on the {app name}.local format, it was done mostly for convenience.

Would you mind sharing why you prefer having multiple environments share the same VPC instead of having separate VPCs? Our idea of an "environment" as a concept is for it to be a completely independent resource stack. So that resource limits in "prod" doesn't affect "dev" and vice-versa.

[kunteng]

Thank you for you answer.

It's actually a legacy constraint rather than a preference: we have several "production" environments of a service existing in the same VPC that we are progressively migrating to ECS.

That said, I totally agree with the resource stack independence for each environment and the current behavior can even be seen as a protection to avoid configuration mistakes.

I'm very fine with the changes I've made as you consider them safe, so should I close the issue ?

Thank you.

[efekarakus]

Thanks for the clarification! Yeah, we can close the issue but feel free to re-open it if you have any other questions!

[gdamjan]

Would you mind sharing why you prefer having multiple environments share the same VPC instead of having separate VPCs? Our idea of an "environment" as a concept is for it to be a completely independent resource stack. So that resource limits in "prod" doesn't affect "dev" and vice-versa.

for smaller apps/deployments a single cluster and VPC is fine enough and is an option when configuring an environment in aws-copilot.

[chmurson]

I had exactly the same situation as @kunteng.

The solution I've chosen was to work with forked copilot-cli where I've applied @kunteng's workaround:

https://github.com/Tipser/copilot-cli/commit/ce4f56abb899dc0f329fc173545857dedc09ef1d

btw: I also forked the GitHub action for setting up the copilot, that uses mentioned forked instead the original one Tipser/setup-aws-copilot@v3

[srbartlett]

Thanks for the fork @kunteng. I ran into the same issue. I planned to use a single VPC for non-prods environments for other legacy reasons and to avoid hitting the Max VPC limit.