Across EC2, ECS on Fargate, and AWS Lambda, who is responsible for patching the operating system, and which capacity decisions remain yours in each case?

## The question behind the question Interviewers open AWS rounds with this because it separates people who have only used one compute model from people who understand the *shape* of the menu. The three options are not three unrelated products; they are three points on a single axis — how much of the running system AWS operates on your behalf. ## EC2: you rent a virtual machine EC2 gives you a virtual server. You choose an instance family and size, choose an AMI (the disk image the instance boots from), and from that moment on the guest operating system is yours: kernel and package patching, OS-level users, agents, log rotation, host metrics. Capacity is explicit — you decide how many instances run and how big they are, usually by putting them behind an Auto Scaling group so the count follows a metric. What you buy for that work is total control. You can run any process, any protocol, any port, keep data on local disk, install licensed software, use GPUs, and tune the kernel. What you pay is a permanent operational surface: an instance that exists is an instance somebody must patch, monitor and eventually replace. ## ECS on Fargate: you rent a place to run a container Fargate removes the instance from your world. You still build a container image and still declare, in the task definition, how much vCPU and memory each task gets — that part has not disappeared, and candidates who claim "serverless means no capacity decisions" get caught here. What has disappeared is the host: there is no EC2 instance in your account to SSH into, no AMI to bake, no OS to patch. AWS provisions the isolation boundary the task runs in and keeps it current. You still own scaling policy (how many copies of the task should be running), the container image and everything inside it — your base image's packages are still your responsibility, because AWS patches the host, not your image. ## Lambda: you rent execution of a function Lambda is the far rung. You upload code, choose a memory setting, and AWS decides everything else: how many execution environments exist at any moment, where they run, when they are created and destroyed. Concurrency is elastic by default rather than something you provision. Your sizing knob is memory, and CPU is allocated in proportion to it, so "make it faster" and "give it more memory" are the same lever. The price of that is the shape of what you can run. A Lambda function runs in response to an invocation and finishes; it is not a long-lived server you can hold state in or keep a socket open on. ## The shared-responsibility framing AWS describes this as the shared responsibility model: AWS is responsible for the security *of* the cloud, you are responsible for security *in* the cloud — and the boundary between the two moves as you go up the ladder. ```text EC2 Fargate Lambda host hardware AWS AWS AWS hypervisor AWS AWS AWS guest OS / patching YOU AWS AWS runtime YOU YOU (image) AWS application code YOU YOU YOU CPU/memory sizing YOU YOU YOU (memory) how many run YOU YOU (policy) AWS ``` Notice that two rows never move: your code and your data are always yours, and some form of sizing is always yours. Notice also what does move — the guest OS row is the single biggest chunk of routine operational work in most organisations, and it is the row that disappears between EC2 and Fargate. ## Why this matters in a real decision Operational burden is a real cost, paid in engineer-hours rather than on the invoice, and it is one of the axes you weigh when choosing a compute model. A three-person team with no dedicated platform engineers is buying something real when it gives up kernel access. A team that needs a specific kernel module, a GPU, or a licensed agent on the host is buying something equally real by keeping it. Neither answer is universally right — but "who patches this at 3 a.m." belongs in the comparison alongside price.