[Feature Request] environment should be able to span across multiple regions

[chriskuech]

Copilot envs are not normal environments

• They do not support spanning multiple regions
• They do not support managing "global" resources that are shared by multiple clusters.

Copilot envs are really ECS clusters

• They are 1:1 with ECS clusters.
• They only support a single region.
• You may deploy multiple envs side-by-side in the same environment for higher availability.

It would be clearer to use the ECS terminology here, especially when current terminology has different implications. If you end up supporting actual multi-cluster environments, what would you call them considering "env" is already taken?

[iamhopaul123]

Hello @chriskuech the Copilot environment right now is more like a 1:1 with VPC instead of ECS cluster. I think overall the question can be concluded as "multi-region" support.

If you end up supporting actual multi-cluster environments, what would you call them considering "env" is already taken?

The reason why we don't have multi-region support for our env is because no one asks for that before (I could be wrong). But if there are a lot of asks, we'll extend the environment to multiple regions. Like when you run env init if you want it to span multiple regions, we'll just deploy multiple copies of env stack concurrently.

[chriskuech]

we'll extend the environment to multiple regions. Like when you run env init if you want it to span multiple regions, we'll just deploy multiple copies of env stack concurrently.

This sounds amazing. Currently it is a non-trivial amount of work to circumvent this issue, as users must support an entire secondary infra deployment system/process, and orchestrate granting permissions to each copilot environment. Any progress you can make towards this goal will be extremely helpful, especially if I can avoid having separate IAM resources per region.

[daroot]

I would definitely like to register my support for this issue.

Being able to deploy to an environment that spanned multiple regions would fit my use case exactly. I'm currently looking at some very hacky solutions like using multiple GitHub Actions to manually deploy to multiple regions in a rolling fashion.

As an additional point, #1972 would be an excellent thing to do at the same time, allowing for all regions to be fronted by the same global accelerator, for true multi-region failover capability, another thing I was looking to have to build manually.

[iamhopaul123]

Hello @daroot. Thank you for your use case. They totally make sense to me. In the meantime, could you give thumb-ups to both issues so as to help us prioritize our tasks?

[neekey]

We have similar use case here.

We are building a product with global audiences, which requires our services to be replicated in multiple regions. Our previous version of the application was using Beanstalk, what we did was on Route53 we create multiple A record with alias point to the beanstalk endpoint and setup latency policy based on region

With copilot I'm trying to do the same thing atm but struggling with how to setup this route53 record while copilot is already managing my domain and ALB is using domain to do the routing and also with the SSL certificate issue... I basically need multiple environment for a service to share the same alias 😢

[iamhopaul123]

Hello @neekey. Since you are building a product with global audiences, do you think CloudFront would help in this scenario instead of making an env spanning across multiple regions? We have https://github.com/aws/copilot-cli/issues/1313 tracking this feature and we are currently actively working on that.

[neekey]

@iamhopaul123 the multi region endpoint i'm building is a backend API service and is not to be cached on a CDN, so dont think CloudFront suits this use case. also we are replicating database using dynamoDB global table as well, as even you can put your API endpoint on services like CloudFront edge, the connection to database across region will still cause significant latency, so replicate resources across regions sound the way to go for us.

a little comment on #1313: definitely love that feature for front end side of the application (we use React), but isnt that gonna cannibalizing Amplify's audience? (personally I think Copilot is much easier to use btw as a managed service solution and cli tool)

[iamhopaul123]

Hello @neekey. That totally makes sense to me. I agree CDN can't substitute multi-region environments in many scenarios. Thank you for describing your use case and reasoning why you need multi-region environments. It is very helpful for us!

definitely love that feature for front end side of the application (we use React), but isnt that gonna cannibalizing Amplify's audience? (personally I think Copilot is much easier to use btw as a managed service solution and cli tool)

Under the hood we use different providers and focus on containerized applications. Also, the reason why you like Copilot is exactly one of the main reason why we build it ❤️

[efekarakus]

Hi @neekey !

Sorry to jump into the middle of the conversation, I was trying to think of a short-term solution to your problem:

Our previous version of the application was using Beanstalk, what we did was on Route53 we create multiple A record with alias point to the beanstalk endpoint and setup latency policy based on region

With copilot I'm trying to do the same thing atm but struggling with how to setup this route53 record while copilot is already managing my domain and ALB is using domain

I saw earlier that @iamhopaul123 suggested using the certificate import feature: https://github.com/aws/copilot-cli/issues/3588#issuecomment-1134243072

In that scenario Copilot won't manage the route53 records, I wonder if that could be a route to mitigate your concern?

1. Create the ACM certificate outside of copilot for *.account.service.holly.com
2. Run copilot env init--import-cert-arns while initializing the environment
3. Go to the route53 hosted zone for service.holly.com add the A-records to the load balancer DNS name

Let me know if this helps! Thank you 🙇

[neekey]

@efekarakus will that ended up using NLB instead ALB? As one of the issue i'm facing the by default the Load Balanced Web service in Copilot is using ALB and the ALB is using domain names to route traffic.

Btw your approach sounds like a way to do, i will have to give it a test, thanks

[cristobalmackenzie]

Hi, just here to pitch in regarding the need/use for Multi region deployments. There are some use cases (financial services, etc), where disaster recovery requirements are really strict. (i.e. this but with ecs fargate clusters, would be awesome !!).

Right now I'm thinking of setting up an additional 'prod' copilot environment in another region ('prod-secondary' or something like that). That sounds like it might work and should be very flexible (different use of resources in second env, to use it more in a 'standby' kind of way, etc...)

Using the CDK for the whole stack or writing CloudFormation to set this whole thing up is really not in my plans, copilot is great.

[jetaggart]

Hey everyone, curious if there's any further best practice or movement on this. Not quite sure the best way to approach a multi-region deployment, especially with a global rds aurora cluster. Any tips/help would be appreciated. Thanks!

[h5aaimtron]

Bumping this as multi-region support would be huge. I think this is one of the drawbacks of copilot at the moment is the lack of support. It keeps copilot from being used at significant scale.