CDK's OAC setup for Lambda function URLs grants CloudFront one of the two permissions it needs

The new pattern changes two settings ^[3]. The function URL's authType moves from NONE to FunctionUrlAuthType.AWS_IAM, and the CloudFront origin is built with FunctionUrlOrigin.withOriginAccessControl(fnUrl) ^[3]. With both in place, only the distribution can invoke the URL, according to the tutorial ^[3]. The author wrote that this is "the production answer to the NONE auth type I warn about in the tips below" ^[4].

The gap is in the function's resource policy ^[5]. CloudFront has to be granted both lambda:InvokeFunctionUrl and lambda:InvokeFunction ^[5]. The author wrote that "at the time of this update the CDK only adds the first" ^[6]. A stack that relies on the construct alone ships with one of the two grants ^[14]. The update does not show the code for the second grant or describe what a request returns without it. We would check the synthesized template for both action names before trusting a deployment. We would also keep the extra grant explicit in code, so it is easy to find when a later CDK release adds it automatically.

The runtime change has a date attached ^[1]. The sample function pins Runtime.NODEJS_20_X ^[7]. That runtime stopped receiving security patches on 30 April 2026 ^[1]. The author's advice is scoped to new functions: use Runtime.NODEJS_24_X ^[2]. The patch cutoff belongs to the runtime, so in our view functions already deployed from the sample need the same move ^[15]. The handler streams its response through awslambda.streamifyResponse ^[12]. That streaming path is what we would retest on the new runtime.

The two changes differ in urgency. The runtime cutoff has already passed ^[1]. The auth change is the author's production recommendation for a feature CloudFront now supports ^[3][4]. The evidence supports moving runtimes now. It supports leaving NONE as a change to schedule for any stack headed to production, which is how the author frames it ^[4].

The construct itself is good engineering. When the author's friend first tried this setup, CDK had no FunctionUrlOrigin, and his attempt with HttpOrigin did not work ^[8]. The author suspected the friend had missed the cache policy ^[10]. The sample sets CACHING_DISABLED so every request reaches the function during development ^[10]. The friend's goals were custom domains and customised caching from the origin ^[9]. A production stack built from this sample still needs a real cache policy in place of CACHING_DISABLED ^[9][10].