Containers and serverless compute: Amazon ECS, Amazon EKS, AWS Fargate and AWS Lambda

Why this matters

Lesson 14 dealt with Amazon EC2, where you rent a virtual server and look after everything on it. Many modern applications are not built that way. They are packaged as containers and run by an orchestration service, or written as small functions that run only when something happens. Both approaches move work off the customer's plate, and both change what the customer pays for.

For a manager, the difference shows up in staffing and cost. A team running hundreds of servers spends a lot of its time patching and scaling them. A team running serverless functions spends that time on the product, and pays nothing while no requests arrive. For a salesperson or a newcomer, the service names are easy to mix up: ECS, EKS, ECR and Fargate sound alike and do different jobs. For a junior engineer, knowing which is which is the first step to reading any modern architecture diagram.

On the exam these services appear as short scenarios with one deciding detail: "already uses Kubernetes", "does not want to manage servers", "runs code when a file is uploaded", "must control the operating system". Each detail points to one service.

The lesson

Container options: Amazon ECS and Amazon EKS

A container is a package that holds an application's code together with everything it needs to run: libraries, settings and runtime. Because the package is complete, the application behaves the same on a developer's laptop, a test server and in production. Containers are lighter than virtual machines because they share the host's operating system rather than each carrying a full one, so many can run on one server and they start quickly. Docker is the most widely used tool for building and running them.

A container starts from a container image, a read-only template of the package. Images are kept in a registry. On AWS that is Amazon Elastic Container Registry (Amazon ECR), a managed registry that stores, manages and shares container images. ECR does not run containers; the services below pull images from it and run them.

Running one container is easy. Running hundreds across a fleet of servers needs orchestration: deciding which server each container runs on, starting replacements when one fails, scaling the number up and down, and connecting containers to load balancers. AWS offers two orchestration services.

Amazon Elastic Container Service (Amazon ECS) is the fully managed container orchestration service built by AWS. It works closely with other AWS services such as Elastic Load Balancing, IAM and Amazon CloudWatch, and it has no separate orchestration software for the customer to install or learn. A unit of work in ECS is called a task, one or more containers run together, and a service keeps a chosen number of tasks running. Choose ECS when you want to run Docker containers on AWS in the simplest way and have no need for Kubernetes.

Amazon Elastic Kubernetes Service (Amazon EKS) is a managed Kubernetes service. Kubernetes is a widely used open-source orchestration system that runs in many environments, on premises and in other clouds as well as AWS. With EKS, AWS runs and maintains the Kubernetes control plane, the part that makes the scheduling decisions, so the customer does not have to. Choose EKS when an organisation already runs Kubernetes, for example in its own data centre, and wants to keep the same tools, skills and workload definitions on AWS.

The deciding question between the two is simple. "AWS-native", "simplest" or "does not want to operate Kubernetes" points to ECS. "Kubernetes", "existing Kubernetes tools" or "open-source orchestration" points to EKS. A question about where images are stored points to ECR, which is neither.

Both ECS and EKS need somewhere for the containers to run. There are two broad choices. You can run them on Amazon EC2 instances in your account, in which case you choose, provision, scale and patch those instances yourself. Or you can run them on AWS Fargate, described next, and manage no instances at all.

Serverless compute options: AWS Fargate and AWS Lambda

Serverless does not mean there are no servers. It means AWS provisions, scales, patches and maintains the servers, and the customer never sees or manages them. The customer supplies code or containers, and pays for what is actually used rather than for servers sitting ready. Scaling and availability across Availability Zones are built in. Serverless options also shift more of the shared responsibility model, described in lesson 6, to AWS.

AWS Fargate is a serverless compute engine for containers. It works with both Amazon ECS and Amazon EKS. Instead of building a cluster of EC2 instances and fitting containers onto them, you say how much processor and memory each task needs, and Fargate runs it. You pay for the processor and memory your tasks ask for, for as long as they run. The customer no longer provisions, scales or patches the hosts underneath. A team already running containers on ECS that is tired of looking after the EC2 instances beneath them should move those tasks to Fargate, not rewrite them as Lambda functions. Fargate runs containers; it does not store their images, which stay in ECR.

AWS Lambda runs code without servers, in units called functions. A function runs in response to an event, something that happens, such as:

• a file being uploaded to an Amazon S3 bucket;
• a request arriving through Amazon API Gateway, the AWS service for creating and publishing APIs;
• a message arriving in a queue, or a change in a database table;
• a schedule, such as every night at midnight.

Lambda starts the function when the event arrives, runs many copies at once when events arrive together, up to the account's concurrency quota, and stops when the work is done. You are charged for the number of requests and the compute time your code uses, and nothing while it is idle. Check the Lambda pricing page for current rates.

Lambda suits short, event-driven tasks: resizing each image as it lands in S3, handling a web or mobile request, processing a stream of records, running a scheduled clean-up. It does not suit everything. Each function invocation has a maximum run time, so a process that must stay running for days or weeks belongs on EC2 or in containers. You cannot reach the underlying host, so you cannot install custom kernel modules or drivers, or change the host operating system.

Responsibility with Lambda. Moving a task from EC2 to Lambda moves the servers, their operating systems and the language runtime to AWS, so patching the operating system becomes AWS's job. The customer still owns the function's code and its security, the IAM permissions the function is given, and the data it handles, including how that data is classified and protected. Serverless removes server work, not security work.

Choosing between them. Arrange the options by how much the customer manages, from most to least:

1. Amazon EC2: you manage the operating system and everything above it. Choose it when you need full control, such as custom kernel modules, special software on the host or a long-running process.
2. Containers on EC2 with ECS or EKS: you manage the instances; the orchestrator manages the containers.
3. Containers on Fargate with ECS or EKS: AWS manages the hosts; you manage the containers and their settings.
4. AWS Lambda: AWS manages everything except your code, its permissions and your data.

The further down the list, the less operational work and the less control. Scenarios that stress "full control of the operating system" sit at the top. Scenarios that stress "no servers to manage", "pay only for compute time used" or "runs when an event happens" sit at the bottom.

A worked scenario

A retailer has three jobs to place. The first is an image service: whenever a supplier uploads a product photo to S3, a thumbnail must be made. Nothing happens for hours, then hundreds of photos arrive at once. That is short, event-driven work with an S3 trigger, so it is AWS Lambda.

The second is the shop's main web application, already packaged as Docker containers. The team has no Kubernetes experience and wants the least possible operations work. That is Amazon ECS, running on AWS Fargate so the team manages no servers, with the images kept in Amazon ECR.

The third belongs to an acquired company that runs everything on Kubernetes in its own data centre and wants to keep its tooling. That is Amazon EKS, which can also run on Fargate if that team later wants to stop managing nodes.

What the exam is really asking

Find the deciding phrase. Kubernetes means EKS. Containers without Kubernetes means ECS. Storing images means ECR. Containers without managing servers means Fargate. Code that runs on an event, with no servers and payment only for compute time, means Lambda. Full control of the host means EC2. If two answers both orchestrate containers, the word "Kubernetes" in the question, or its absence, separates them.