CDK: Region validation

[pgarbe]

Describe the feature

If a region is set for a Stack, CDK should validate if the synthesized constructs match the actual supported resources of that region. As each region supports different services (or even different features) a shift-left of the validation helps developer to get early feedback if their solution will be deployable on that region.

Use Case

Whenever a new Region launches I want to verify if my code is deployable to that region. An actual deployment is not helpful as it could have side effects and fails usually on the first missing service. It does not give me an overview of which services I have in my stack that are not or only partial supported. Failing during cd synth helps to get an early feedback and to check that regularly (as available services and their features of a region changes over time).

Another use-case is related to the launch of the European Sovereign Cloud in 2025. As preparation it is useful to be able to build solutions that will be compatible with the initial supported services.

Proposed Solution

Use the same sources as the Region Comparison Tool

Other Information

No response

Acknowledgements

• I may be able to implement this feature request
• This feature might incur a breaking change

CDK version used

v2 (latest)

Environment details (OS name and version, etc.)

OSX 14.5

[pahud]

I love this idea. Will bring this up to core team for their inputs.

[otaviomacedo]

Yes, I think it's a good idea, too. We can pick this up in the future as part of a bigger shift left story, that includes improvements to the policy validation feature.

[pgarbe]

I'm not sure if it's just another validation rather than a hard compiler failure (especially when the region has been set). It will just not deploy in such a case and it's not a choice.

For validation, I see scenarios like HIPAA compliance which is more a self-imposed restriction.

[rix0rrr]

I agree that this would be useful. I'll just throw out some complicating facts here that we'll need to deal with when we go to design and ship this:

• Information grows stale quickly: resource availability data can change quickly. Not for all resources, not for all services: some are just not planned for certain regions. But if services/resources are planned for a given region, their rollout typically happens over the course of a couple of days. So if we take a snapshot of the region resource availability at a given day D, when our CDK version containing that availability finally hits a user's workspace at D+2, that information is out of date already. We will now show a resource as "not available" when it in fact is available.
  • To use this information correctly will therefore induce a lot of update pressure on users, which will feel uncomfortable.
  • What about users who want longer update cycles, on the order of months? We have enterprise customers that update software like it's 1999, and like it or not we have to account for them. Our regional availability checker will probably be unnecessarily pessimistic about the chances of an application deploying correctly with outdated versions.
  • Does that mean the information is refreshed at runtime? Then what about network-isolated customers?
• Detail will be coarse-grained, or suffer staleness even worse: this particular point is an example of "letting perfect be the enemy of good", but once we start predicting resource availability the very next request will be to do the same on a feature-by-feature basis. Remember ECR image scanning? Can we use it or not? I'd like to know in advance! While resource availability will probably stay somewhat consistent over time, feature availability will suffer from the staleness problem even worse.
• ADC regions availability is hard to come by: this question was asked in the context of ADC (Amazon Dedicated Cloud) regions. That information is currently not available, and while this page contains a couple of ADC regions on it (2 GovCloud regions), these are always somewhat special beasts and it will be hard to source the necessary ground truth information. We will need to run internal campaigns to collect and publish this information.

All of this is not to say we shouldn't do this, but it's somewhat of a huge undertaking to commit to it that we shouldn't underestimate. I'm also not clear on how large the user population is that struggles with issues like this.

To begin with, an external plugin that treats it as a policy validation issue (i.e., plain CFN template in, error messages out) disconnected from CDK core seems like the simplest approach with the least risk to get this started. And at that point, anybody could implement this validation plugin, using the same data sources that we would use.

I will commit to doing the following things right now:

• Bring this up with our product owner
• Engage with CloudFormation to request that they publish resource availability information for ADC regions

Other than that, with apologies I'm softly going to bounce this back to you @pgarbe: it really is a good idea, and yes this should be part of the product at some point in time, but I don't think this is necessarily something our team needs to spend time on in the short term, especially since this is something that could be implemented by the community as a plugin given information and features that are available already.

If and when we have a good working model of how this validation should work, and/or an overwhelming signal that this is very desirable for a large segment of the user base (crudely put: when our cost/benefit ratio changes significantly 🥸), we'll of course happily re-evaluate.

[rix0rrr]

Internal reference D188730944