Thanks for this - any hints as to the best way to store {secretAccessKey: 'FIXME', accessKeyId: 'FIXME'} for CloudFront Functions? With Lambda I normally would store secrets in SSM as encrypted values and fetch them at runtime with a Lambda layer, but I don't think anything like this is possible with CF Functions...

Bonus question: does this run fast enough in your testing? My understanding is CloudFront Functions are supposed to be like.. 10ms or something? Wondering if you've had any issues with limits?

@kevin-mitchell To answer your questions:

1. For the credentials, you could store them in cloudfront kvstore and scope down the permissions to just lambda invokefunctionurl on the function if you want to limit blast radius.
2. It did run fast enough to sign get requests, but the Authorization header gets stripped by the time it hits Lambda so it doesn't work. Here's the thread on this gist

With that said, I wrote this before Lambda OAC support with CloudFront. Now that that exists, doing it yourself is no longer necessary (and actually works, unlike the above). If you're interested here's a couple of bonus posts about my adventures in CloudFront functions:

Using CloudFront Functions as a REST API
Using CloudFront functions as a lightweight proxy

edit: I just re-read the titles of your posts at least and realize now you're specifically talking about the CloudFront Functions being used as an API - I have slower functionality that I'd like to run in Lambda ideally, not CloudFront Functions most likely, so that's the disconnect - I suppose the CloudFront Functions would work perfectly fine with POST and PUT data, my hangup is still on getting OAC to work with Lambda and POST / PUT body signing which as far as I can tell, does not work without you doing it manually?

@perpil wow this is gold, thank you! I will carefully read through these later tonight - again, thanks a ton! That said, you mentioned Lambda OAC support, but they say this in the link you provided:

If you use PUT or POST methods with your Lambda function URL, your users must include the payload hash value in the x-amz-content-sha256 header when sending the request to CloudFront. Lambda doesn't support unsigned payloads.

I assumed this meant "it's on you to figure out how to do this if you want to support POST / PUT payloads", which is how I ended up on this gist originally.

With the caveat out of the way that I haven't read all of your links yet, the reason I originally found this snippet is specifically because I am using what I thought was the AWS blessed mechanism for safely calling Lambda from CloudFront. If you'll forgive the CDK, I have something like (note specifically the use of FunctionUrlOrigin.withOriginAccessControl):

..rest of the Distribution definition...
additionalBehaviors: {
          "config/obscure.json": {
            allowedMethods: AllowedMethods.ALLOW_ALL,
            origin: FunctionUrlOrigin.withOriginAccessControl(
              props.requestHandlers.apiHandlerFunctionURL
            ),
            cachedMethods: CachedMethods.CACHE_GET_HEAD,
            cachePolicy,
            originRequestPolicy:
              OriginRequestPolicy.ALL_VIEWER_EXCEPT_HOST_HEADER,
            responseHeadersPolicy,
          },
....

This just doesn't appear to work with PUT or POST requests with body.

Ah ok, so CloudFront functions don't have access to the payload so the hash can't be added in a CloudFront function. For POST/PUT requests, the manual work you need to do is calculate the sha256 hash of the payload from the client and set the x-amz-content-sha256 header to it.

Thank you! I actually was overthinking this, I knew I had to set the hash of the payload in the header you mentioned but in my head I was thinking I had to SIGN the payload, i.e. get a secret / key / whatever and use it to sign the payload.

(I'm mainly posting this in case anybody similar to me finds this in the future)

It turns out that all you have to do, which again you already knew it sounds like, is hash the payload without any sort of secrets - I assume that the reason for this is that the infra in place that's doing the OAC signing stuff maybe doesn't have the actual body on hand to sign, or perhaps there is more to it, but I imagine (though don't know) it's "easier" for AWS to use this x-amz-content-sha256 head as a stand-in for actually looking at the request body and hashing it as part of the signing process.

Regardless of exactly how this works, using CDK I was able to get everything working without requiring client side (i.e. in browser) work by using a Lambda@Edge function to hash the content and stick it in the header. Looking at this now, for my use case it wouldn't actually be that bad to just do this on the actual client side, again originally I came to this thinking I would need to do something more complicated. There is a cost associated with Lambda@Edge so it's not ideal. That said, this is for a small personal project and I'm expecting, literally, a 10-20 requests a month here.

CDK

This code I copy / pasted from a different gist, which I didn't find until much after this one: https://gist.github.com/antonbabenko/f9eee9603a525d55c3ae1abba1a561f5 - this is using inline because i'm not concerned about changing the code and it's more about infra. I imagine aws_cloudfront.experimental.EdgeFunction is subject to change at some point.

    const edgeFunction = new aws_cloudfront.experimental.EdgeFunction(
      this,
      "lambda-edge-poc",
      {
        code: Code.fromInline(`
        "use strict";
        
        const crypto = require("crypto");
        
        exports.handler = (event, context, callback) => {
          const request = event.Records[0].cf.request;
          const headers = request.headers;
          const method = request.method;
          const body = Buffer.from(request.body.data, "base64").toString();
        
          if (method != "POST" && method != "PUT") {
            return callback(null, request);
          }
        
          const hash = crypto.createHash("sha256").update(body).digest("hex");
        
          if (!headers["x-amz-content-sha256"]) {
            headers["x-amz-content-sha256"] = [
              { key: "x-amz-content-sha256", value: hash },
            ];
          }
        
          return callback(null, request);
        };
        
        `),
        handler: "index.handler",
        runtime: Runtime.NODEJS_22_X,
      }
    );

Then inside of my distribution with the specific behavior I want this to sit in front of (note the edgeLambdas property is where the above EdgeFunction goes):

....
additionalBehaviors: {
          "config.json": {
            allowedMethods: AllowedMethods.ALLOW_ALL,
            origin: FunctionUrlOrigin.withOriginAccessControl(
              props.requestHandlers.apiHandlerFunctionURL
            ),
            cachedMethods: CachedMethods.CACHE_GET_HEAD,
            cachePolicy,
            originRequestPolicy:
              OriginRequestPolicy.ALL_VIEWER_EXCEPT_HOST_HEADER,
            responseHeadersPolicy,
            edgeLambdas: [
              {
                includeBody: true,
                functionVersion: edgeFunction.currentVersion,
                eventType: LambdaEdgeEventType.VIEWER_REQUEST,
              },
            ],
          },
......

I've updated the description to note that it doesn't work so future readers don't get fooled.

Using an edge lambda is a valid way of calculating the x-amz-content-sha256 so you don't need to do it on the client. The use case where it makes sense is that you need a custom url for your furl or you need to add WAF. If you don't need either of those, you'll get lower latency by turning off IAM on your furl and using it directly. Without doing additional authentication in your edge lambda, the threat profile is similar to having a wide open lambda.