Lambda runs your code in response to events without you managing servers. You supply a function, AWS supplies the compute, and you pay for the time it runs rather than for an instance sitting idle.\n\nThe model is genuinely different from a server, and most Lambda problems come from carrying server assumptions into it.\n\n\u003cAwsDiagram type="lambda-flow" /\u003e\n\n## The execution model\n\nAn execution environment is a small, isolated sandbox that runs one invocation at a time. Ten simultaneous requests mean ten environments. There is no in-process concurrency to share.\n\nWhat matters operationally is that AWS reuses environments. After an invocation finishes, the environment is kept warm for a while and reused for the next request. That has two consequences:\n\nCode outside the handler runs once per environment, not once per invocation. This is the single most useful optimisation available:\n\n```python\nimport boto3\n\n# Runs once per environment. Reused across invocations\ns3 = boto3.client("s3")\n\ndef handler(event, context):\n # Runs every invocation\n return s3.get_object(Bucket="acme", Key=event["key\
Choose and tune EBS volumes: gp3 vs gp2, io2 Block Express, why the instance type caps throughput, fast snapshot restore, safe resizing and encryption.
Choose between Kinesis Data Streams, Firehose, SQS and MSK. Learn shards, hot partition keys, consumer lag, enhanced fan-out and how to reshard a busy stream.
Query S3 with SQL using Athena and keep the bill low. Learn partitioning, partition projection, why Parquet beats JSON and how to cap bytes scanned per query.