Open adamjkeller opened 1 month ago
Absolutely! Making it p2 for now. Please help us prioritize with 👍
Let us hide the unnecessary complexity of FunctionURLs and let's make the API similar to the new S3 origins! Lambda functions support just one function URL. Therefore, instead of
// Old way
const functionUrl = lambdaFunction.addFunctionUrl();
const functionUrlDomainName = Fn.parseDomainName(functionUrl.url);
const lambdaOrigin = new origins.LambdaOrigin(functionUrlDomainName, config);
I would like to propose, similar to https://github.com/aws/aws-cdk-rfcs/issues/617
const lambdaOrigin = origins.LambdaOrigin.withFunctionDefaults(lambdaFunction);
// and
const lambdaOrigin = origins.LambdaOrigin.withOriginAccessControl(lambdaFunction);
cc @gracelu0
@piotrekwitkowski Thank you for your suggestion - while I agree it would be nice to abstract away the addFunctionUrl
line, this would reduce flexibility for users who want to use an existing function url or customize their function url. Additionally, there is an existing FunctionUrlOrigin
construct already which expects a IFunctionUrl
so changing this API would be a breaking change for existing users. I believe the setup using the existing origin class is just
const functionUrl = fn.addFunctionUrl();
const origin = new origins.FunctionUrlOrigin(fnUrl);
so no need to parse the domain name. Hope that makes sense!
Describe the feature
In April 2024, the Cloudfront team announced support for Origin Access Control (OAC) for Lambda function URL origins. Add a new construct that will support this as an origin.
Use Case
Exposing Lambda Function URL's on the public internet has a lot of risk, but there are use cases where customers need to expose these lambda functions on the public internet, but would prefer to have the protections that come with CloudFront (ie, DDoS protection, Web Application Firewall, etc).
Proposed Solution
No response
Other Information
No response
Acknowledgements
CDK version used
N/A
Environment details (OS name and version, etc.)
N/A