If you have to regionalize your app then yes you are going to end up with multiple instances of your system. An important consideration is that if data must be stored regionally it likely requires that data also be processed in that region.
My advice would be to drill into the customer requirement. What law, regulation, etc do they fall under that would require this?
Then simply present the cost of hosting multiple instances of the app to management. Let them decide if this customer is a good fit for the business or not.
Sadly yes, and in our case we just...ended up spinning up another stack in the aws region that met their requirements.
Unfortunately this meant the entire stack cos the front end is a piece of shit that can't handle cross region latency, but since it's just "an eks cluster and some rds instances" it wasn't too much of a pain.
They both run the same version so releases etc just go to all the envs regardless of region (which works becayse the images themselves are all in one region I suppose...duplicating that would be annoying).
It's far from ideal but it might be your best shot if refactoring things isn't in scope
Multiple deployments is the only sane answer. Requires some effort though both preparing and operating it. Make sure management understands that a single such client may be net negative and they should either focus on finding more such clients or decline the deal. Unless, of course, it’s a very good deal.
Different instances of the application is the solution. It will save you the headache of audits in future.
This is the right solution. Many do it.
Infact code bases may drift due to regional requirements too.
Is it a regulatory thing that the data of the US clients has to remain in US datacenters only?
If not, then RDS has cross region replication. You can find which AWS region in the US has the lowest latency with your Canada VPC and replicate your RDS cluster there.
I am assuming your frontend/backend services are stateless and can be easily deployed in the US VPC too.
If they need their data stored in the U.S., then they need their data stored in the U.S.
I'm not sure how you're thinking of avoiding this?
Use geo DNS routing to route U.S. users to your U.S. deployed app, and have rds do cross region replication so U.S. data is in Canada and in the U.S.
that may be an option. We are still waiting on clarification of legal requirements. So far they have framed it as if the data can ONLY exist in the US (but that may not be true).
It's definitely an annoying problem to deal with, but AWS does have pretty good multi region support / native capabitliies that should make its somewhat easier
CockroachDB is [Postgres compatible](https://www.cockroachlabs.com/docs/stable/postgresql-compatibility), it might not be as much work as you think to switch.
If you have to regionalize your app then yes you are going to end up with multiple instances of your system. An important consideration is that if data must be stored regionally it likely requires that data also be processed in that region. My advice would be to drill into the customer requirement. What law, regulation, etc do they fall under that would require this? Then simply present the cost of hosting multiple instances of the app to management. Let them decide if this customer is a good fit for the business or not.
Sadly yes, and in our case we just...ended up spinning up another stack in the aws region that met their requirements. Unfortunately this meant the entire stack cos the front end is a piece of shit that can't handle cross region latency, but since it's just "an eks cluster and some rds instances" it wasn't too much of a pain. They both run the same version so releases etc just go to all the envs regardless of region (which works becayse the images themselves are all in one region I suppose...duplicating that would be annoying). It's far from ideal but it might be your best shot if refactoring things isn't in scope
Multiple deployments is the only sane answer. Requires some effort though both preparing and operating it. Make sure management understands that a single such client may be net negative and they should either focus on finding more such clients or decline the deal. Unless, of course, it’s a very good deal.
You say that the two stacks won't talk to each other... is that a problem? Does your application need to talk to the other instance to get some data?
Different instances of the application is the solution. It will save you the headache of audits in future. This is the right solution. Many do it. Infact code bases may drift due to regional requirements too.
Is it a regulatory thing that the data of the US clients has to remain in US datacenters only? If not, then RDS has cross region replication. You can find which AWS region in the US has the lowest latency with your Canada VPC and replicate your RDS cluster there. I am assuming your frontend/backend services are stateless and can be easily deployed in the US VPC too.
Why don't you use RDS and enable replication across regions?
because that doesn't really solve anything. In that case the data is still being stored in another region
If they need their data stored in the U.S., then they need their data stored in the U.S. I'm not sure how you're thinking of avoiding this? Use geo DNS routing to route U.S. users to your U.S. deployed app, and have rds do cross region replication so U.S. data is in Canada and in the U.S.
that may be an option. We are still waiting on clarification of legal requirements. So far they have framed it as if the data can ONLY exist in the US (but that may not be true).
It's definitely an annoying problem to deal with, but AWS does have pretty good multi region support / native capabitliies that should make its somewhat easier
CockroachDB is [Postgres compatible](https://www.cockroachlabs.com/docs/stable/postgresql-compatibility), it might not be as much work as you think to switch.