aws-cdk: (lambda-python): arm64 architecture is not respected

@ryparker shouldn’t this actually be p1. Not familiar with assessment process but based on other issues I do feel like cdk-team prioritizes issues when something that used to work stopped with p1 which means higher prio and someone from core team looking at this?

fn := awslambdapython.NewPythonFunction(stack, jsii.String("ddb-to-opensearch"), &awslambdapython.PythonFunctionProps{
	Architecture: awslambda.Architecture_ARM_64(),
	Runtime:      awslambda.NewRuntime(jsii.String("python3.9:latest-arm64"), awslambda.RuntimeFamily_PYTHON, nil),
	Entry:        jsii.String(codeDir),
	LogRetention: awslogs.RetentionDays_ONE_MONTH,
})

We solved this problem by setting “Bundling”.

fn := awslambdapython.NewPythonFunction(stack, jsii.String("ddb-to-opensearch"), &awslambdapython.PythonFunctionProps{
	Architecture: awslambda.Architecture_ARM_64(),
	Runtime: awslambda.Runtime_PYTHON_3_9(),
	Entry:        jsii.String(codeDir),
	LogRetention: awslogs.RetentionDays_ONE_MONTH,

	// We solved this problem by setting "Bundling"
	Bundling: &awslambdapython.BundlingOptions{
		Image: awscdk.DockerImage_FromRegistry(jsii.String("public.ecr.aws/sam/build-python3.9:latest-arm64")),
	},

	……
})

I believe I had a similar issue recently, using typescript, I have a CDK Pipeline with a CodeBuild synth step running aws/codebuild/amazonlinux2-aarch64-standard:3.0 to bundle a PythonLambda with a target ARM64 architecture from @aws-cdk/aws-lambda-python-alpha@2.103.1-alpha.0.

The docs (https://docs.aws.amazon.com/cdk/api/v2/docs/aws-lambda-python-alpha-readme.html) say:

…and with the Docker platform based on the target architecture of the Lambda function.

This doesn’t seem to be the case looking at the code and from my experiments, the CodeBuild image while bundling outputs:

[Warning] The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested

When executing the ARG and ENV commands from this Dockerfile, then the RUN command fails (as expected if the platform is wrong):

exec /bin/sh: exec format error
The command '/bin/sh -c python -m venv /usr/app/venv &&     mkdir /tmp/pip-cache &&     chmod -R 777 /tmp/pip-cache &&     pip install --upgrade pip &&     mkdir /tmp/poetry-cache &&     chmod -R 777 /tmp/poetry-cache &&     pip install pipenv==2022.4.8 poetry==$POETRY_VERSION &&     rm -rf /tmp/pip-cache/* /tmp/poetry-cache/*' returned a non-zero code: 1

And I can actually see the docker build command was executed with the wrong platform:

Command: docker build -t cdk-redacted-id --platform "linux/amd64" --build-arg "IMAGE=public.ecr.aws/sam/build-python3.11" "/codebuild/output..."

In the contract of PythonFunction we get BundlingOptions however when bundling BundlingProps is used and it accepts an architecture attribute.

Creating the Lambda specifying the platform in bundling options is ignored completely, the output is as above.

super(scope, id, {
      runtime: Runtime.PYTHON_3_11,
      bundling: {
        platform: 'linux/arm64',
      },
      architecture: Architecture.ARM_64,
      ...

But if I force the architecture (note the use of as any, since I can’t technically pass in architecture through BundlingOption, only with BundlingProps):

super(scope, id, {
      runtime: Runtime.PYTHON_3_11,
      bundling: {
          architecture: Architecture.ARM_64,
      } as any,
      architecture: Architecture.ARM_64,
      ...

This works, because the code that decides on the platform is here platform: architecture.dockerPlatform,, architecture is defined above architecture = Architecture.X86_64,.

I think the contract should change, architecture should be an attribute of BundlingOptions (since it is possible in some situations to want to target one architecture while building in another), regardless, the current behaviour is not what the docs describe and so I would call it a bug.

To me it seems like making some small changes here would fix the bug, then there could be a feature request to move architecture to BundlingOptions, here is the change:

code: Bundling.bundle({
        entry,
        runtime,
        skip: !Stack.of(scope).bundlingRequired,
        architecture: props.architecture,  // define architecture based on the target architecture of the function
        ...props.bundling,
      }),

If the Docker image is built on an M1 chip and uploaded to be deployed by Fargate or another similar AWS service then you’ll notice this container error:

standard_init_linux.go:228: exec user process caused: exec format error

There’s a couple ways to work around this. You can either:

• Build your docker image using:

docker buildx build --platform=linux/amd64 -t image-name:version .

• Update your Dockerfile’s FROM statements with

FROM --platform=linux/amd64 BASE_IMAGE:VERSION

@ryparker

Ok I was able to reproduce your issue and found a solution:

Try updating the PythonFunction’s runtime to use ARM 64 Python.

i.g.

 fn_python.PythonFunction(
            self,
            'ARM',
            entry='lambda',
            runtime=fn.Runtime('python3.9:latest-arm64', fn.RuntimeFamily.PYTHON), # <-- specify custom runtime
            architecture=fn.Architecture.ARM_64,
        )

@ryparker Could you help me with this problem? The following error occurs:

Resource handler returned message: “Value python3.9:latest-arm64 at ‘runtime’ failed to satisfy constraint: Member must satisfy enum value set: [nodejs12.x, python3.6, provided, nodejs14.x, ruby2.7, java11, dotnet6, go1.x, provided.al2, java8, java8.al2, dotnetcore3.1, python3.7, python3.8, python3.9] or be a valid ARN (Service: Lambda, Status Code: 400, Request ID: 3d9ba725-5e91-4195-b289-5c44e4f7d0c2, Extended Request ID: null)” (RequestToken: 2571186d-8ab7-c79a-8b05-4870981b5b74, HandlerErrorCode: InvalidRequest)

fn := awslambdapython.NewPythonFunction(stack, jsii.String("ddb-to-opensearch"), &awslambdapython.PythonFunctionProps{
	Architecture: awslambda.Architecture_ARM_64(),
	Runtime:      awslambda.NewRuntime(jsii.String("python3.9:latest-arm64"), awslambda.RuntimeFamily_PYTHON, nil),
	Entry:        jsii.String(codeDir),
	LogRetention: awslogs.RetentionDays_ONE_MONTH,
})

Oh gotcha. Let me try to reproduce this on my end. I’ll get back to you soon.