Cross platform deploy on aws cloudformation package breaks path seperators

[pm-incyan]

Describe the bug

If you try to deploy a Lambda layer/function from a Windows computer and target a runtime which is Linux based, for example the Python3.12 runtime, the dependencies do not work, because the auto-created zip file by aws cloudformation package includes Windows path seperators in the zip file. When the layer/function is extracted to the /opt directory within the Lambda environment the files are extracted but they include the literal backslash chararacters in their filenames and are flat within /opt. Therefore the depdendencies do not load at all.

Expected Behavior

The dependencies load correctly.

Current Behavior

The zip file is built with path seperator based on the environment where the aws cloudformation package command is run, so the depdencies do not load at run time when going cross-platform.

Reproduction Steps

Generate a Lambda layer from a local path using a tempalte, e.g.

BaseLayer:
    Type: AWS::Lambda::LayerVersion
    Properties:
      LayerName: BaseLayer
      Content: lambda/layers/base/dist
      CompatibleRuntimes:
        - python3.12
      CompatibleArchitectures:
        - x86_64

Run aws cloudformation package in a Windows environment, then use this layer in a Lambda function. If you list the contents of the /opt directory, for example by running:

import os
print(os.listdir("/opt"))

You can see the incorrect paths extracted to /opt that contain backslashes.

Possible Solution

Generate the zip file in a compatible format for the target environment.

OR

Add lambda support for extracting a zipfile using Windows path seperators.

Additional Information/Context

No response

CLI version used

aws-cli/2.15.6 Python/3.11.6 Windows/10 exe/AMD64 prompt/off

Environment details (OS name and version, etc.)

Windows 11 Pro / Lambda Python3.12

[tim-finnigan]

Thanks for reporting this issue and your patience here. I was having some trouble reproducing this, could you provide the full command used and debug logs (with sensitive info redacted) by adding --debug to the command? That could help give us more insight into the issue. Have you also tried using the SAM CLI / sam deploy command as an alternative?