Containers, serverless, auto scaling and load balancing

Serverless means somebody else has the server

AWS Lambda runs a function in response to an event — an object arriving in a bucket, a message on a queue, an HTTP request — and scales out to run many invocations concurrently without being asked. You supply the code and AWS supplies everything under it, there is a maximum run time per invocation of fifteen minutes, and you are billed only for the time the code actually runs.

That last property is the whole economics, and it cuts both ways. Nothing happening costs nothing, which makes Lambda excellent for work that arrives in unpredictable bursts: five thousand photo uploads in a minute and then an hour of silence. A process that is busy all day is usually cheaper on a container or an instance, so "serverless is cheaper" is not the fit test. Short, event-driven and stateless is.

Two questions hide inside every container question

The first is who orchestrates: Amazon ECS is AWS's own container orchestrator, and Amazon EKS is managed Kubernetes, which is the answer when a team already has Kubernetes skills or manifests it wants to keep. The second is who owns the servers: with an EC2 capacity provider the container instances are yours to choose, patch and count, while AWS Fargate runs the tasks on capacity AWS owns and you declare only the vCPU and memory each task needs.

The two questions are independent, which is why "ECS on Fargate" and "EKS on EC2" are both perfectly ordinary sentences and why a question has to be read for which half it is really about. A requirement that says the team does not want to choose, patch or pay for instances is answering the second question and says nothing about the first. Container images themselves live in Amazon ECR.

Load balancing, separated by how deep the request is read

Elastic Load Balancing spreads requests across healthy targets in several Availability Zones and stops sending traffic to anything failing its health check. The three types differ in what they can see. Only the Application Load Balancer parses HTTP, so only it can send requests whose path begins with /api to one target group and everything else to another; that content-based routing is what a question about one hostname and two back ends is asking for.

A Network Load Balancer forwards connections by port at very high throughput and never sees a path, because it does not parse HTTP at all. A Gateway Load Balancer exists to put security appliances transparently in the traffic path. And Amazon Route 53 is not a load balancer in this sense: DNS resolves a name before the request is made, so the resolver cannot know a URL path, and weighted records split traffic by proportion rather than by content.

Scaling on a clock, on a metric, or on a forecast

EC2 Auto Scaling can be driven manually, on a schedule, dynamically from a metric such as average processor use or request count, or predictively from a forecast. The distinction the exam leans on is that a dynamic policy is by definition a REACTION: the alarm fires after the load appears, and the new instances still need minutes to boot and pass health checks, so the earliest arrivals get the slow application anyway.

When the pattern is known in advance — idle overnight, hammered between 08:00 and 10:00 every weekday for three years — a scheduled action puts the capacity in service before the users arrive and removes it afterwards. A mature configuration usually runs both: the scheduled action for the pattern you know and a dynamic policy as the safety net. The point of all of it is elasticity in both directions, and the second direction is where the money is.