By using AWS re:Post, you agree to the AWS re:Post Terms of Use
AWS re:Postre:Post

Lambda@edge replication service is creating resources like function replicas, log-groups, versions without consistency

0

My overall solution is that I'm using the lambda@edge function triggered at Origin-request cloudfront event to get signedCookies by accessing the private key from secrets. I notice that the replication services is not quite working consistently for e.g., my function name is abc-url-sign and lambda being centered out of us-east-1, the arn is arn:aws:lambda:us-east-1:123456789012:function:abc-url-sign:version and the log-group I configured in the same region as aws/lmbda/abc-url-sign then the replication service is creating a function with arn of arn:aws:lambda:us-east-1:123456789012:function:**us-east-1.**abc-url-sign:version and log-group of /aws/lambda/us-east-1.abc-url-sign. Obviously with such mismatch the edge location functions are not getting invoked. And I'm using iam policy that is AWS Managed policy of AWSServiceRoleForLambdaReplication ad AWSServiceRoleForCloudfrontLogger. Is anyone else facing this problem. Is this a known issue of some sort?

Topics
ServerlessComputeNetworking & Content Delivery
Tags
AWS LambdaLambda@Edge
Language
English
Plugrapid Support
asked 8 months ago389 views
1 Answer
0

This inconsistent naming behavior between the Lambda function and its replicas created by the replication service does sound like a bug. Typically the function name and log group should match between the origin and replicas.

A few things to try:

  • Double check that the Lambda function name itself does not contain the region prefix. The replication service should strip this out, but any inconsistencies could cause issues.

  • Try deleting the existing function/log group and redeploying with a simple name like "test" without the region. See if replicas get created correctly.

  • Open a support ticket with AWS to report the issue. They may be able to check if there are any known bugs causing naming mismatches.

  • For a temporary workaround, you could handle the mismatch in names by looking up the replicated function versions after creation and finding the log groups programmatically. Not ideal but could unblock you.

  • Consider using Lambda@Edge blueprints which can help manage all the replicated resources: https://github.com/aws-samples/lambda-edge-blueprints

Definitely seems like a bug since the naming and consistency between origins and replicas should be handled transparently. I'd suggest opening a support ticket for best results getting the issue escalated and resolved.

AWS
Saad
answered 8 months ago
  • Plugrapid Support
    8 months ago

    So it seems that such naming of the function names and log groups is possible in the edge locations based on this: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/edge-functions-logs.html And I can see from cloudtrail logs that the EnableReplication permission is leading to a replicated function in being created at the edge location3 . The log stops there and I'm guessing the step after that should be the Invocation of the edge function. The lambda:InvokeFunction is granted to cloudfront principal as the trusted entity and I even modified the Resource arn to be arn:aws:lambda::123456789012:function: for the region and function name values to be wildcards based on the above documentation. So I have the lambda:GetFunction in the resource policy that brings the lambda function to the EnableReplication/DisableReplication permissions that create and deploy replicas to the edge locations with arn:aws:lambda:eu-west-2:9999999999:function:myFunction-url-sign:version . The iam:CreateServiceLinkedRole and iam:PassRole manages the iam role and its assumption by the cloudfront and lambda@edge services. Finally the logs:CreateLogGroup and the logs:CreateLogStream and logs:PutlogEvents that are required for CloudWatch Logs. The trusted identity policy makes sure that the lambsa@edge, cloudfromt and the logger services get to sts:assumeRole. If all of tis is not enough, what am I missing that is not invoking the function in runtime (cli invokes fine)

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions

Relevant content