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\
Read an EC2 instance type name, learn what each family is for, understand burstable credits and Graviton savings, and size instances from data, not guesses.
Learn how EC2 security groups work as stateful firewalls: rule structure, referencing groups instead of CIDRs, default outbound rules and blocked traffic.
Learn how EC2 key pairs work, create one for SSH, recover an instance after losing the key, and see why Session Manager is a better default than SSH.