Maintenance: `compatibleArchitectures` field not available in all AWS Regions

[dreamorosi]

Summary

In #1372 we have introduced two new fields to our public layers: compatibleArchitectures and license. This new field however caused the release process to fail due to one of the fields not being accepted in some regions.

To proceed with the release I have applied an hot-fix, however we should dedicate time to understand what are the implication of this field not being supported.

Why is this needed?

Because the compatibleArchitectures is not supported in some AWS regions (eu-south-2, eu-central-2, ap-southeast-4) and we are unsure of what are the implications.

Which area does this relate to?

Automation

Solution

No response

Acknowledgment

• [X] This request meets Lambda Powertools Tenets
• [ ] Should this be considered in other Lambda Powertools languages? i.e. Python, Java, and .NET

Future readers

Please react with 👍 and your use case to help us understand customer demand.

[dreamorosi]

As the commits linked above show, I ended up temporarily commenting out the parameter in the layer stack.

Let's discuss options in the coming weeks.

[am29d]

Python folks had similar problems with my recent changes here. They used aspects to traverse the nodes and fix the compatibleArchitectures field based on the region.

I will apply same fix to our layer package.

[dreamorosi]

Aside from the immediate fix, do we have a reliable way of keeping track of when the field will be available? Or do we have to keep our eyes peeled on the what's new channel to see when it gets announced?

[am29d]

We will revisit the issue once we start working on #1374. I will block it for now.

[dreamorosi]

The Python team has worked around this limitation by modifying the region matrix from this:

matrix:
  region:
    [
      "af-south-1",
      "eu-central-1"
    ]

to this:

matrix:
  include:
    - region: "af-south-1"
       has_arm64_support: "true"
    - region: "ap-east-1"
       has_arm64_support: "true"

With the new has_arm64_support key passed as a parameter like this:

npx cdk deploy --app cdk.out --context region=${{ matrix.region }} --parameters HasARM64Support=${{ matrix.has_arm64_support }} ...

Then, in the CDK application, the parameter is converted to a set of CfnConditions which are in turn used to modify the construct in charge of publishing the layer using Aspects. See here for example.

We should look into adopting the same solution so we can forget about the issue for good.