Is the function ARN of lambda@edge always equal to the one deployed in us-east-1?

DevOps AWS
1

Is the function ARN of lambda@edge always equal to the one deployed in us-east-1 (arn:aws:lambda:${local.region}:${local.account_id}:function:${local.lambda_name}) or does it change per region? (And maybe other things?) And can I use lambda:SourceFunctionArn with lambda@edge in IAM Conditions for confused deputy prevention? I’m having trouble finding anything about that in the documentation.

2

I believe the arn format should remain the same, have you seen anything to indicate otherwise?

3

Oh I see, it’s only available in us-east-1? Have you already read through this? https://dev.to/aws-builders/restric-access-to-cloudfront-distribution-using-lambdaedge-15ll

4

Not that specifically, but that also has a vulnerable policy:

"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": [
"[lambda.amazonaws.com](http://lambda.amazonaws.com)",
"[edgelambda.amazonaws.com](http://edgelambda.amazonaws.com)"
]
},
"Action": "sts:AssumeRole"
}
]
}```
Most AWS docs on most services do...
5

And the Lambda as such is deployed to us-east-1, but it’s replicated at the edge caches across the world, that’s why it’s called @edge. hence the suspicion that it might change regions, or use different ARNs entirely, such as not using the lambda partitition or using a different function identifier depending where it’s running

6

Have you had a chance to check the activity through CloudTrail?

7

It is replicated, but not in lambda, so I believe the arn remains the same always, and you can’t actually access the replicated version per region. Only the “real” one in us-East-1. The gotcha is where the logs end up - always in the closest region to the CloudFront EL where the end user ended up. Usually the suffix is the region, iirc.