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 between ALB, NLB and GWLB, then set up target groups, listener rules, health checks and TLS, and debug 502 and 503 errors from the load balancer.
Create an Application Load Balancer, set up target group health checks and priority-ordered listener rules, read 502 and 503 errors and compare ALB with NLB.
Set up a Network Load Balancer for layer 4 traffic: static IPs, client IP preservation, the hairpin problem, cross-zone charges, TLS listeners and NLB vs ALB.