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\
Build a CI/CD pipeline with AWS CodePipeline: stages, source providers, artifacts, manual approvals and deploy actions, plus CodePipeline vs GitHub Actions.
Write a CodeBuild buildspec.yml that works: phases and failure behavior, caching, Docker image builds, VPC access, exported variables and build diagnosis.
Cut your AWS bill in a sensible order: find where the money goes, use Savings Plans, Spot and Graviton, and fix hidden data transfer and NAT gateway charges.