Providing your own Lambda@edge for OAC edge signing does not work

[masterFlippy]

When providing my own edge function I get a error saying a lambda@edge can not have environment variables. I guess its because sst is injecting some env vars to sst.aws.Function.

    protection: {
        mode: "oac-with-edge-signing",
        edgeFunction: {
            arn: edgeFunction.nodes.function.apply(
                (fn) => fn.qualifiedArn,
            ) as $util.Output<sst.aws.FunctionArn>,
        },
    },

Will this be fixed or should i just use the transform as I am doing now to bypass it?

    $transform(sst.aws.Function, (args, opts, name) => {
        if (name.includes("EdgeFunction")) {
            args.environment = {};
        }
    });

EDIT:

this did not work:
$transform(sst.aws.Function, (args, opts, name) => {
if (name.includes("EdgeFunction")) {
args.environment = {};
}
});

[vimtor]

@MrHertal care to take a look at this one?

[MrHertal]

@masterFlippy

How did you create the edge function — using sst.aws.Function or aws.lambda.Function?

If you used sst.aws.Function, that's the issue. It always injects internal env vars (SST_RESOURCE_App, SST_KEY, etc.) in an .apply() that runs after any $transform on the component args — so clearing args.environment has no effect.

The $transform would need to target the raw Pulumi resource instead:

$transform(aws.lambda.Function, (args, opts, name) => {
  if (name.includes("EdgeFunction")) {
    args.environment = { variables: {} };
  }
});

But the cleanest solution is to skip sst.aws.Function entirely and use aws.lambda.Function directly — which is also what SST does internally in createLambdaEdgeFunction():

const edgeRole = new aws.iam.Role("EdgeSigningRole", {
  assumeRolePolicy: JSON.stringify({
    Version: "2012-10-17",
    Statement: [{
      Effect: "Allow",
      Principal: {
        Service: ["lambda.amazonaws.com", "edgelambda.amazonaws.com"],
      },
      Action: "sts:AssumeRole",
    }],
  }),
  managedPolicyArns: [
    "arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole",
  ],
});

const edgeFn = new aws.lambda.Function("EdgeFunction", {
  code: $asset("path/to/handler"),
  handler: "index.handler",
  runtime: "nodejs22.x",
  architectures: ["x86_64"],
  role: edgeRole.arn,
  publish: true,
  memorySize: 128,
  timeout: 5,
});

// Then in your config:
protection: {
  mode: "oac-with-edge-signing",
  edgeFunction: {
    arn: edgeFn.qualifiedArn.apply((arn) => arn as sst.aws.FunctionArn),
  },
},

[masterFlippy]

Alright. Thanks I'll try with the aws.lambda.Function directly

[masterFlippy]

Which means i have to handle the TS -> JS myself? It happens by itself when using sst.aws.Function

[vimtor]

@masterFlippy what's your use case for a custom edge function? also ts → js you'll need to handle it yourself atm, maybe inline the js if the function's small

@MrHertal adding support for sst.aws.Function would be nearly impossible right? maybe we should document this limitation, maybe deprecate the custom arn and only allow sst.aws.Function

happy to hear your thoughts

[MrHertal]

I tested oac-with-edge-signing with a BYO Lambda@Edge using aws.lambda.Function (raw Pulumi) and it works fine. The key is to avoid sst.aws.Function entirely since it injects SST_RESOURCE_App, SST_KEY, etc. in an internal .apply() that can't be intercepted by $transform.

@vimtor I think supporting sst.aws.Function for edge would require adding an "edge mode" that skips env var injection.

Fun fact: I asked the Doc AI chatbot "Can I create a Lambda@Edge with SST?" and it suggested using protection: { mode: "oac-with-edge-signing", edgeFunction: { arn: ... } } as the way to attach a Lambda@Edge — which technically works but misuses the signing option for general-purpose edge logic.

Then I asked "How can I attach a Lambda@Edge to the router?" and finally got this:

The docs do not show a way to attach a general-purpose Lambda@Edge to Router beyond the signing function used by protection: "oac-with-edge-signing".

So I think there might be a gap: anyone needing Lambda@Edge for header manipulation, redirects, A/B testing, etc. has to misuse the protection option ^^

[vimtor]

interesting

i have to say that my first intention would have been to use sst.aws.Function as @masterFlippy since i want to use regular ts files and get all the benefits of sst

it's tricky because i would have expected env and links to work too

maybe we can add an example of a redirect and link to it from the jsdocs until we figure out a better solution?

[masterFlippy]

I got the transform to work when i provided:

    $transform(aws.lambda.Function, (args, opts, name) => {
        if (name.includes("edge-function")) {
            args.environment = {};
        }
    });

So I am able to use sst.aws.function now.

[masterFlippy]

@masterFlippy what's your use case for a custom edge function? also ts → js you'll need to handle it yourself atm, maybe inline the js if the function's small

My case is that I want to use the edgefunction for more things. For example i will use it for validating jwts.