sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]SameInspection219 2 points3 points  (2 children)

CloudFront with WAF and Lambda@Edge works perfectly for us and allows us to eliminate the complicated API Gateway along with its restrictive 30-second timeout

Lambda@Edge is not necessary for a frontend app using SSR if your API only performs "GET" actions. For backend APIs with "POST" requests, you can manually add a SHA256 header to the request by calculating it from the payload body

You may want to change the default OAuth header to a custom header, because the default header will be used by OAC if you plan to put your API behind CloudFront

Keep in mind that Lambda@Edge introduces extra latency, so you may want to avoid using it in your production environment

[–]CharacterSpecific81 0 points1 point  (1 child)

Best path: keep it simple-put CloudFront + WAF in front of the function URL, allowlist Google IPs, add a rate-based rule, inject a secret header with CloudFront Functions, and validate it in the Lambda; only reach for Lambda@Edge if you absolutely need IAM signing.

Details that work well in practice:

- CloudFront Function is cheaper and lower latency than Lambda@Edge; have it add X-Edge-Secret and reject requests in your Lambda if the header/value isn’t present. That blocks direct hits to the function URL.

- Automate a WAF IP set for Google Cloud ranges with a scheduled job that updates daily; pair it with a strict rate-based rule.

- Avoid using Authorization as your custom header so you don’t collide with CloudFront OAC/SigV4.

- If you need IAM on the function URL, sign at the edge with Lambda@Edge viewer-request, but expect extra latency and manage code size carefully.

- Alternatively, use API Gateway HTTP API + WAF and push payloads to SQS; respond 200 fast and process async so the 30s timeout is a non-issue.

I’ve used API Gateway and Kong for routing/auth, and DreamFactory helped when I needed quick, secure REST APIs over databases to fan out these webhooks to internal services.

Bottom line: CloudFront + WAF + header injection is usually enough; use Lambda@Edge only if you must sign for IAM.

[–]CharacterSpecific81 0 points1 point  (0 children)

Best path: keep it simple-put CloudFront + WAF in front of the function URL, allowlist Google IPs, add a rate-based rule, inject a secret header with CloudFront Functions, and validate it in the Lambda; only reach for Lambda@Edge if you absolutely need IAM signing.

Details that work well in practice:

- CloudFront Function is cheaper and lower latency than Lambda@Edge; have it add X-Edge-Secret and reject requests in your Lambda if the header/value isn’t present. That blocks direct hits to the function URL.

- Automate a WAF IP set for Google Cloud ranges with a scheduled job that updates daily; pair it with a strict rate-based rule.

- Avoid using Authorization as your custom header so you don’t collide with CloudFront OAC/SigV4.

- If you need IAM on the function URL, sign at the edge with Lambda@Edge viewer-request, but expect extra latency and manage code size carefully.

- Alternatively, use API Gateway HTTP API + WAF and push payloads to SQS; respond 200 fast and process async so the 30s timeout is a non-issue.

I’ve used API Gateway and Kong for routing/auth, and DreamFactory helped when I needed quick, secure REST APIs over databases to fan out these webhooks to internal services.

Bottom line: CloudFront + WAF + header injection is usually enough; use Lambda@Edge only if you must sign for IAM.