Let me start by saying: I’m a huge fan of the services that AWS has.
Their documentation is some trickster god’s joke on developers. I already knew this but got to jump into it recently with some lambda work. Do they tell you everything they need to? No, because development in AWS is only fun if you have no clue why nothing is working!
1. Lambdas don’t have connectivity to the outside world without additional work
You can connect to whatever AWS service you want (in the same region), but if you have an external resource, like a database, you’re gonna have to create a VPC with a NAT gateway and Internet Gateway to allow the lambda to talk to the internet. I won’t detail the process here because it’s documented in a bunch of places elsewhere, but it requires some knowledge of networking that crosses over into IT and is not a place developers normally go. Git gud, scrub!
2. Lambda@Edge is almost completely different from regular lambdas
Your Lambda@Edge lambda does get to connect to the outside world at all. The purpose of Lambda@Edge is to do processing at the edge server the content is being served from. This means no VPCs; these scripts live on the Edge. This also applies to logging. Your Lambda@Edge logs are completely unavailable…unless you know the hidden secret magic of how Lambda@Edge logs work.
3. Amazon enjoys causing us pain
Since Amazon is the FromSoftware of documentation, their docs exist to make you bang your head against a wall until you either figure out which docs are good or quit and go work at McDonalds. A stunning example of this is the documentation for testing and debugging Lambda@Edge vs the Cloudwatch metrics for Lambda@Edge doc. The former tells us that log groups have the following format:/aws/cloudfront/LambdaEdge/, where DistributionIdDistributionId is your distribution’s ID
The latter tells us that log groups have the following format:/aws/lambda/us-east-1.function-name, where function-name is the name that you gave to the function when you created it.
The first is for logs that don’t provide meaningful data besides “the lambda returned something invalid”. They don’t give you what happened with the function, just that it’s not working. Useless!
The latter is our actual function logging. Hurray, we found out how to debug functions!
Just kidding; we almost forgot how much Amazon likes bringing the pain. Those logs won’t show up for you without more work.
4. Lambda@Edge functions don’t have log permission at the edge
This is one of the stupidest things that made a life of selling McNuggets seem preferable. When you go to look for the logs that Amazon says exist in their docs, they aren’t there because the execution role for Lambda@Edge needs special permission to create logs in every region because it’s deployed at the edge. Yes, they do have documentation detailing that this is necessary, but it’s AWS docs; this means it’s not at all obvious or intuitive that you’ll need to do something extra special until you find the answer on Stack Overflow. The part with the permissions you need is about halfway down that page and you’d have to read that far to know it.
5. None of this matters once you get your lambda functions working
Once everything works, you will praise the Black Box Gods of Amazon for providing you with just enough information to complete your task. Being able to show off the fact that you slogged through Amazon’s documentation and wrote code well enough to make the magic happen makes this all worth it. Just like beating a boss you’ve died to 15 times, the win is intoxicating.
