Copilot on shared VPC

[kajamhercules]

Hi, trying to use copilot in an environment with shared VPC. From what I could see, currently copilot does not support shared VPC. For the environment it is trying to create servicediscavery namespace association and it is failing due to shared VPC (account has to own VPC in order to create association). I'm missing something? Any chance to include support for shared VPC in future releases?

[efekarakus]

Hi @kajamhercules !

Which version of Copilot are you using? Starting with v1.9 Copilot supported sharing the same VPC creating environments.

account has to own VPC in order to create association
But from your message it looks like that's not the issue exactly. At the moment you would need to create environments in the same accounts as the VPC to use it, it's not possible to import a cross-account VPC. Is that the feature request just to make sure?

[kajamhercules]

Sorry, I didn't explain my issue properly. My environment has a central account where all VPC defined. This central account shares VPC with workloads accounts. Workload account would be used to create the copilot app and environment. Copilot will be creating service discovery namespace in the workload account, but it will not be possible due to the workload account using shared VPC from the central account. Namespace can't be created on a shared VPC from an account it has been shared with. A way to do it, create a namespace in the workload account on temp VPC and associate it with the central account (central account would need to accept association). Or namespace could be created in cloudmap manually and provided as a parameter to the copilot.

[efekarakus]

That makes sense to me, thank you for the clarification!

Out of curiosity how do you share your central account VPC to the workload accounts? For example, is this the tutorial that you followed: https://docs.aws.amazon.com/vpc/latest/userguide/vpc-sharing.html with AWS organizations or is there a different method?

I'll try to recap the issue here:

• A central accountA is used to create all VPCs.
• Applications and environments are defined in other accounts accountB, accountC...
• You try importing the VPCs in accountA to environments in accountB but this step fails because the service discovery namespace cannot be created using the imported VPC from accountA

[kajamhercules]

@efekarakus, the link from your replay covers how VPC and subnets are shared. And it is done within AWS org, but AWS org is not critical here.
Here is what have been done:

1. have got account A where VPC A and subnets aza and azb has been defined.
2. VPC A has been shared to account B. Account B got access to VPC A and subnets aza and azb. Now account B can deploy resources on VPC A and subnets. This is done that account A has full control on what is happening in account B from network perspective. And SCP for AWS org not allowing to create any network resources that will compromise the network, therefore Account B will not be able to change networking.
3. in account B:
   • copilot app init mytest --domain mytest.app.domain - runs successfully, creates required roles
   • copilot init - runs successfully, creates repository, cluster and etc. on provided VPC and subnets. in our case it would be VPC A and subnets aza and azb.
   • copilot env init --name dev --profile accountB --app myfirstapp - not able to finish successfully
     error from Cloudformation stack for logicalID: ServiceDiscoveryNamespace:
     The VPC: vpc-xxxxxxxxxx in region xxxxxxx that you provided is not authorized to make the association. (Service:
     AmazonRoute53; Status Code: 400; Error Code: InvalidVPCId; Request ID: xxxxxxxxxx; Proxy: null)
     As it been specified before, the reason for this error is that service discovery namespace can't be created on VPC that has been shared with account B. You have to specify VPC in order for Route53 to create namespace. In our case, account B do not have (owns) VPC, route53 will not be able to use shared VPC A to create namespace.
     Network architecture change is not an option in my case. Was hoping to use copilot to automate ECS depoloyments. I think copilot is a cool solution, otherwise I would need to come up with similar( not so cool :) ) solution. I think shared network deployment model could be useful feature as in a lot of cases enterprises would prefer to control networking centrally. Thank you for looking into this!

[efekarakus]

Thank you for the steps! I'll convert this into a feature request: #3541

[iamhopaul123]

Hello @kajamhercules. Other than VPC could you please tell us if there's any other resource that the workload accounts cannot create?

[kajamhercules]

Hi @iamhopaul123 , maybe I do not understand the question, workload uses shared VPC from another AWS account therefore workload not able to create anything that would recquire VPC. For example, service discovery namespace will not be possible to create since VPC doesn't belong to workload account. As a way around it, new temp VPC could be created, service descavery namespace created for the temp VPC, service descavery will need to be associated with shared VPC by creating association request and request will need to be accepted from AWS account that shares VPC with workload account. Hope this helps.

[iamhopaul123]

Sorry I @kajamhercules I might not put my question clearly but basically, if we allow cross-account VPC import, will workload account be able to (have permissions to) create the other resources like LB, cluster, ECS services? From your reply it seems like VPC is the only blocker right now.

[kajamhercules]

Yes, other then restrictions for VPC described above , workload will be able to create any AWS resources.

[iamhopaul123]

Thank you for the quick reply. This is very helpful to us!