It's a question many of us grapple with when architecting cloud solutions: how exactly do we get billed for running code? Especially when we're talking about serverless functions, the 'pay-as-you-go' model sounds fantastic, but the nuances can sometimes feel like deciphering a secret code. Today, let's pull back the curtain on AWS Lambda and its edge-computing sibling, Lambda@Edge, specifically focusing on how those per-request charges stack up.
At its heart, AWS Lambda is designed to let you focus on your code, not the servers. You write it, upload it, and Lambda handles the rest – scaling, availability, security. The billing model reflects this simplicity: you're charged based on the number of requests your function receives and the duration your code runs, measured in milliseconds. It's a pretty straightforward concept. Think of it like paying for electricity – you only pay for what you consume. The reference material highlights that duration is calculated from when your code starts executing until it finishes, and this includes initialization code too. And here's a neat trick: opting for Arm-based Graviton2 processors can offer a significant cost-benefit, sometimes up to 34% better value than x86.
Now, Lambda@Edge is where things get a bit more geographically distributed. It's a feature of Amazon CloudFront, AWS's Content Delivery Network (CDN). The magic here is that your code runs closer to your end-users, drastically reducing latency and improving performance. And guess what? The billing philosophy is remarkably similar to standard Lambda. You pay for the compute time your code uses, and crucially, when your code isn't running, you don't pay a dime. This is a huge win for efficiency. Lambda@Edge is triggered by events from CloudFront, and AWS Lambda takes care of running and scaling your code across global AWS sites. This means you don't need to worry about provisioning or managing servers in multiple locations; it's all handled for you.
So, how do the per-request charges specifically compare?
AWS Lambda (Standard):
- Requests: You're billed for each time your function is invoked. For asynchronous events (like those from S3 or EventBridge), each event counts as one request, with additional charges if the event size exceeds 256KB, up to 1MB. For synchronous invocations (like via API Gateway), each call is a request.
- Duration: This is calculated based on the memory allocated to your function. More memory means more CPU power, and the price per millisecond varies based on this allocation. The duration includes code execution and initialization.
Lambda@Edge:
- Requests: Similar to standard Lambda, you're charged per request. The key difference is that these requests are tied to CloudFront events.
- Duration: The billing for duration is also based on compute time. However, Lambda@Edge has specific pricing tiers and considerations that might differ slightly from standard Lambda due to its edge deployment. The reference material doesn't detail specific per-millisecond rates for Lambda@Edge directly, but the principle of paying for compute time remains.
Key Takeaways for Billing:
Both services offer a pay-per-use model, which is fantastic for cost optimization. The core components of billing are requests and compute duration. The primary distinction in how you're billed per request often boils down to the triggering event source: standard Lambda handles a broader range of AWS service integrations and direct invocations, while Lambda@Edge is specifically tied to CloudFront events. For both, understanding your function's memory allocation and execution time is crucial for accurate cost forecasting.
It's also worth noting that AWS offers a generous free tier for Lambda, which can cover a significant portion of your initial usage. Beyond that, services like Compute Savings Plans can offer substantial discounts if you commit to a certain level of usage over one or three years. For Lambda Managed Instances, a different pricing model applies, combining request fees, a compute management fee, and EC2 instance costs, which is geared towards high-volume, steady-state workloads. But for the typical serverless use case, the per-request and per-millisecond duration billing for both standard Lambda and Lambda@Edge provides a clear, consumption-based cost structure.
