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\
Write, package and deploy Lambda functions: handler signatures, zip vs container image packaging, layers, versions and aliases, and testing locally.
Compare ECS and EKS on cost, complexity, portability and ecosystem, see where Fargate and App Runner fit, and get a short decision rule for your team.
Understand ECS task definitions and services: task role vs execution role, networking modes, health checks, deployments and fixing a task that will not start.