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\
Create an EKS cluster that works the first time: avoid IAM lockouts with access entries vs aws-auth, tag subnets correctly and plan for the VPC CNI IP limit.
Run EKS worker nodes : managed node groups vs Fargate, why Karpenter beats Cluster Autoscaler, taints, Spot interruptions and nodes that will not join.
Understand AWS CloudFormation: template anatomy, deploying stacks, change sets, drift detection and stuck stacks, plus CloudFormation vs Terraform.