There are several options for code and application deployment in the AWS ecosystem. Two of the most popular options for AWS application deployment are:
- Elastic Container Service (ECS)
- AWS Lambda
Today, let’s look at ECS and Lambda, explaining what each option does and discuss some critical considerations for deploying one option over another.
(This article is part of our AWS Guide. Use the right-hand menu to navigate.)
Elastic Container Services (ECS): Container orchestration
ECS is used to manage and deploy Docker containers at scale (container orchestration).
ECS uses the following AWS components to store and run ECS applications:
- AWS ECR
- ECS cluster
- Task definitions
- ECS service scheduler
- Other AWS services
Let’s take a look.
The AWS Elastic Container Repository (ECR)
ECR manages, stores, compresses, secures, and controls access to container images. Alternatively, you can use Docker Hub for storing and accessing container images.
An AWS ECS cluster for running containerized applications
A cluster is a logical grouping of tasks and containers that use several different launch types (infrastructure) to run. Clusters can contain:
- Elastic Cloud Compute (EC2) instances
- Amazon-managed instances using AWS Fargate
- External servers outside the Amazon ecosystem using Amazon ECS Anywhere
When adding EC2 instances to an ECS cluster, you will need to manage the EC2 servers in that cluster, including locking down EC2 security, access, patching their operating systems, and performing maintenance.
AWS Fargate is a serverless computing environment that works with ECS. When adding Fargate tasks to an ECS cluster, AWS provisions and manages the EC2 servers your containers run in, relieving you from administering a separate EC2 infrastructure.
Amazon ECS Anywhere is an ECS extension that allows you to run containerized applications on servers outside the AWS ecosystem. ECS Anywhere loads an agent onto customer managed operating systems, making them managed instances and allowing those instances to register into an ECS cluster.
Task definitions
Task definitions that describe 1-10 containers (and parameters) that define an ECS application. Task definitions are stored as JSON files.
The AWS ECS service scheduler
This service schedules tasks (instantiations of the task definitions) to run inside your ECS cluster infrastructure. It executes tasks on a cron-like schedule or your own custom schedule.
The task scheduler also:
- Ensures that tasks are registered against AWS Elastic Load Balancers (ELBs) for load balancing among clustered servers.
- Handles all task placement strategies.
Other services
AWS is also integrated with other AWS services.
How ECS works
Putting it together, the ECS service scheduler launches tasks into ECS clusters using task definitions that reference and use Docker containers stored in the Elastic Container Repository or Docker Hub.
Using ECS is notable in that you can define your own EC2 server cluster, let AWS manage and deploy EC2 servers (AWS Fargate), use external servers (ECS Anywhere), or a combination of the three. Clusters and ECS tasks run inside specified AWS Virtual Private Clouds (VPCs) and subnets.
AWS Lambda: Serverless function deployment
AWS Lambda excels at running smaller on-demand applications that are triggered by new events and information.
Lambda is an AWS service that runs code without the need to provision and manage infrastructure. There is no EC2 provisioning or clusters to define. Lambda totally controls the EC2 instances your code runs on, and it auto-scales as needed. Lambda operates at the function and code level in the following way:
You create the code you want to run
Lambda supports many languages through Lambda runtimes, including nodeJS, Python, Go, Java, Ruby, .Net, and C#.
You package and upload your code
Package your code in a zip or jar deployment package, and upload it using the Lambda console or AWS CLI.
You designate the file and function name that serves as your entry point. Once uploaded, Lambda provides an Amazon Resource Name (ARN), which serves as an ID for the function you just created.
Your Lambda function is invoked and runs on EC2 instances
Lambda functions can be invoked several ways, including:
- Directly from the Lambda console, the Lambda API, the AWS software development kit (AWS SDK), AWS CLI, and AWS toolkits.
- From triggers in a Lambda resource or another resource.
- From a Lambda event source mapping that invokes a Lambda function. Lambda reads events from several AWS services such as Amazon DynamoDB, Amazon Simple Queue Service (SQS), etc. Event sources are created in AWS CLI or AWS SDK.
- From AWS services that invoke Lambda directly, including AWS ELB, AWS Simple Notification Service (SNS), Amazon API Gateway, and several others.
Functions can be invoked either:
- Synchronously, where Lambda waits for a response after running the function and returns the response code with additional data to the client, allowing for retries and error responses
- Asynchronously, where the client hands the event off to Lambda and doesn’t wait for response code and data.
After the function’s initial call, Lambda can scale by an additional 500 instances per minute when traffic spikes, until there are enough instances to handle the traffic. Scaling continues until a Lambda concurrency limit is reached or requests come in faster than your function can scale. You can also contract for provisioned concurrency to prevent Lambda scaling waits. As traffic dies down, Lambda stops unused instances.
How Lambda works
Lambda provisions serverless application deployment, including:
- EC2 instance setup
- Load balancing
- Target groups
- Auto-scaling
Your main responsibility is setting up your functions and invocation configurations. Lambda does the rest. Lambda functions are easy to set up and worry-free as far as infrastructure goes.
ECS vs Lambda: which is right for you?
Now that we’ve looked at what each application deployment option does and how it works, here are some considerations in choosing one option over the other.
Consider Lambda over ECS when…
- You have a smaller application that runs on-demand in 15 minutes or less. Lambda functions are limited by a timeout value that can be configured from 3 seconds to 900 seconds (15 minutes). Lambda automatically terminates functions running longer than its time-out value.
- You don’t care or need advanced EC2 instance configuration. Lambda manages, provisions, and secures EC2 instances for you, along with providing target groups, load balancing, and auto-scaling. It eliminates the complexity of managing EC2 instances.
- You want to pay only for capacity used. Lambda charges are metered by milliseconds used and the number of times your code is triggered. Costs are correlated to usage. Lambda also has a free usage tier.
Consider ECS over Lambda when…
- You are running Docker containers. While Lambda now has Container Image Support, ECS is a better choice for a Docker ecosystem, especially if you are already creating Docker containers.
- You want flexibility to run in a managed EC2 environment or in a serverless environment. You can provision your own EC2 instances or Amazon can provision them for you. You have several options.
- You have tasks or batch jobs running longer than 15 minutes. Choose ECS when dealing with longer-running jobs, as it avoids the Lambda timeout limit above.
- You need to schedule jobs. ECS provides a service scheduler for long running tasks and applications, along with the ability to run tasks manually.
Generally, ECS is best used for running a Docker environment on AWS using clustered instances. Lambda is best used for quickly deploying small, on-demand applications in a serverless environment.
