AWS Lambda and Serverless — Triggers That Work and Costs Under Control

Your frontend loads, the API responds, but at the end of the month your AWS bill makes you cringe. Or you have a Lambda function that should process every file uploaded to S3, but half the time it doesn't fire. If you've worked with serverless for a while, you know the magic fades when you have to deal with unreliable triggers and exploding costs. At Meteora Web, we've seen this in real projects — sometimes a single misconfiguration multiplies the bill by ten. That's why we've built a concrete approach: start with triggers, then put costs under a microscope.

This guide is for those who already have a serverless project on AWS and want to understand how to make Lambdas work without surprises. It's not an introduction: we talk about real triggers (S3, SQS, API Gateway, DynamoDB Streams) and how to tame costs with proven techniques.

How do AWS Lambda triggers actually work in a real project?

A Lambda alone does nothing. It needs an event to wake it up. The trigger is that link between an event source and the function. AWS offers about a dozen services that can invoke a Lambda, either synchronously or asynchronously. The trigger choice changes everything: latency, reliability, and especially cost.

Synchronous triggers: API Gateway and Application Load Balancer

When a user calls your API, the Lambda must respond immediately. Here the trigger is synchronous: AWS waits for the function's response and forwards it to the client. This is the classic REST API case. The problem? If the Lambda takes 3 seconds for a simple request, you get cold start plus network latency. We solve this by setting Provisioned Concurrency on critical functions — keeping the Lambda warm even though the hourly cost increases. For a production API, the trade-off is necessary.

# Example handler for API Gateway
import json

def lambda_handler(event, context):
    nome = event.get('queryStringParameters', {}).get('nome', 'World')
    return {
        'statusCode': 200,
        'body': json.dumps({'message': f'Hello {nome}!'}),
        'headers': {'Content-Type': 'application/json'}
    }

Asynchronous triggers: S3, SQS, DynamoDB Streams

Asynchronous triggers are more interesting for batch processing, uploads, message queues. The Lambda receives the event and runs without the caller waiting. But careful: if the function fails, by default AWS retries up to 3 times. If you don't handle errors correctly, you pay for useless executions. A client we follow had a Lambda attached to an S3 bucket to resize images on upload. The trigger worked, but sometimes the image was already in webp format: the function did nothing but still paid for execution. We solved it by filtering S3 events with .png and .jpg at the trigger level, using S3 event filters. Fewer invocations, lower costs.

# S3 trigger configuration with filter (Console AWS or Terraform)
{
  "LambdaFunctionArn": "arn:aws:lambda:...",
  "Events": ["s3:ObjectCreated:*"],
  "Filter": {
    "Key": {
      "FilterRules": [
        {"Name": "suffix", "Value": ".jpg"},
        {"Name": "suffix", "Value": ".png"}
      ]
    }
  }
}

Triggers from queues and streams: SQS and DynamoDB

SQS is the cleanest way to decouple workloads. A queue accumulates messages and the Lambda consumes them in batches. The cost? Free for the first million SQS requests per month, then you pay only for traffic. But you must configure batchSize and maximumBatchingWindowInSeconds correctly. With DynamoDB Streams, every change to a table triggers the Lambda. The cost is tied to the records read from the stream. A common mistake: enabling the stream on all modifications when only INSERT and MODIFY are needed. We use native stream filters (available since late 2024) to reduce invocations by 50%.

What are the real costs of Lambda and serverless AWS?

AWS Lambda pricing is simple on paper: you pay per request and per execution duration (rounded to the nearest 0.1 second). But reality is full of traps. At Meteora Web, we regularly analyze the serverless costs of our clients. Here are the three factors that make the difference.

The cost of requests: free up to 1 million per month

The free tier includes 1 million requests per month and 400,000 GB-seconds of compute. For a small project this is sufficient. But once you cross that threshold, every million requests costs $0.20. That seems little, but if your API serves 10 million requests per month, that's $2 just for requests, plus duration. Duration is calculated in GB-seconds: 1 GB memory for 1 second = 1 GB-second. A function with 512 MB memory that takes 200 ms costs 0.0000002 GB-seconds? No: the allocated memory is what counts, not the used one. If you assign 1024 MB for a function that uses 128 MB, you pay more. So: size memory to the minimum needed using AWS Lambda Power Tuning (open source tool).

Hidden costs: data transfer, CloudWatch, VPC

The Lambda itself is only part of it. Every invocation generates logs on CloudWatch Logs. A 1 KB log per execution, with 5 million invocations, is about 5 GB of logs per month. At $0.50 per GB (first 5 GB free), the cost adds up. Solution: set a short retention period (7 days for non-production) and use conditional debug logs. Also, if the Lambda is inside a VPC, you pay for NAT Gateways or VPC Endpoints. Avoid putting all Lambdas in a VPC if not necessary: use AWS Lambda managed policy to access services like S3 and DynamoDB without VPC.

The impact of memory and duration on cost

More memory means more cost per GB-second, but often less execution time. A function that compresses images might take 5 seconds with 256 MB, but 1 second with 1024 MB. The total cost could be lower with more memory because you pay less duration. We use AWS Lambda Power Tuning to automatically test different memory configurations and find the cost-optimal point. In one real case we reduced spending by 30% by moving from 512 MB to 1024 MB on a transcoding function.

How to optimize serverless AWS Lambda costs?

Now that you know the mechanisms, let's get to concrete actions you can take today.

1. Set a budget and an alarm on Cost Explorer

AWS lets you create monthly budgets and receive notifications when spending exceeds a threshold. Set a $10 per month budget for Lambda and an alarm at $8. If you exceed it, you know something changed. We recommend enabling cost tags on functions (e.g., Environment: production) to filter in reports.

2. Use ARM64 (Graviton) instead of x86_64

ARM64 instances are 20% cheaper for the same performance. AWS offers Lambda on Graviton2 architecture. Just change the architectures value in CloudFormation or the console. Make sure your dependencies (native binaries) are compiled for ARM. For Python and Node.js it's usually fine. On many projects we reduced costs by 20% without touching a line of code.

3. Reduce invocations with filters and batching

Every invocation has a cost. So filter upstream. For S3, use event filters. For SQS, increase batchSize to 10 (default maximum) and set a maximumBatchingWindowInSeconds of 30 seconds. Instead of invoking the Lambda for each message, collect up to 10 messages per execution. The total requests drop drastically.

# Example SQS event source mapping (Terraform)
resource "aws_lambda_event_source_mapping" "sqs_trigger" {
  event_source_arn  = aws_sqs_queue.my_queue.arn
  function_name     = aws_lambda_function.my_lambda.arn
  batch_size        = 10
  maximum_batching_window_in_seconds = 30
}

4. Enable Provisioned Concurrency only for critical functions

Provisioned Concurrency keeps a fixed number of warm environments. It costs as if the function were always running (about $0.000004 per GB-second plus real duration). Use it only for high-latency APIs or production. For the rest, cold start is acceptable if under 1 second. We activate it only for functions behind API Gateway with a response SLA under 200 ms.

5. Monitor with CloudWatch and create a dashboard

Set up a CloudWatch dashboard with metrics: Invocations, Duration, Throttles, ConcurrentExecutions. Also add EstimatedCost (if you use tags). If you see a spike in invocations, check the trigger immediately. We also use AWS Lambda Insights for deeper debugging.

What to do now

Here are three actions you can take today:

• Review the triggers of every Lambda: filter S3 events, optimize SQS batching, reduce DynamoDB streams to only needed events.
• Run AWS Lambda Power Tuning on the most invoked functions. Find the optimal memory-duration trade-off.
• Set a budget on AWS Cost Explorer and an alarm for Lambda. Add tags for environment and project tracking.

Serverless promises pay-per-use, but without control costs can skyrocket. At Meteora Web, we've learned to balance efficiency and expense over years of real projects. If you have an AWS infrastructure to tune, start with our AWS pillar and then dive deeper with this guide. Every cent saved is a cent that stays in your business.

For more on the serverless ecosystem, check the official AWS Lambda documentation.