Develop Containerized Apps with AWS Fargate

© 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved.
Deep dive on AWS Fargate
#AWSSummit
Brent Langston, @brentContained
Developer Advocacy, Containers at
AWS

A little bit of intro

A container is an atomic, self-contained package of
software that includes everything it needs to run (code,
runtime, libraries, packages, etc.).
A popular, widely-used container platform is Docker.
More on that here: https://docker.com

Why are containers so popular?
• Portable
• Lightweight
• Standardized
• Easy to deploy
• Along with containers, comes the “monolith to microservices”
story: containers and microservices go hand in hand (more on
that in a second)

OK, so what are microservices?
”Service oriented architecture
composed of loosely coupled elements
that have bounded contexts.”
- Adrian Cockroft
This is Adrian

Why do containers and microservices go together?
• One job, one service → container
• Can deploy and scale containers
independently
• This means that a high traffic service, like a
messaging service, might need to be scaled
frequently, but a low traffic service, like an
internal dashboard, doesn’t need to be
scaled at the same time

Managing one container is easy (ish)

Managing many containers is much harder
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS

Enter orchestration tools

Orchestration tools help us deploy, manage, and
scale our containers, so we don’t need to do all the
heavy lifting ourselves.

There are a few options on AWS for
container orchestration

Let’s recap the container options
on AWS

What does the landscape look like all together?
Amazon ECS
(available now)
Amazon EKS
(available now)
Fargate mode for ECS
(available now)
Fargate mode for EKS
(Coming soon)

MANAGEMENT
Deployment, Scheduling, Scaling
& Management
HOSTING
Where the containers run
Amazon EC2
IMAGE REGISTRY
Container Image Repository
What are the services for?

AMAZON CONTAINER SERVICES
So you want to run a (managed) container on AWS
Choose your orchestration tool1
Choose your launch type2
ECS EKS
EC2 Fargate EC2 Fargate

OK, so let’s talk about Fargate

Your Docker
Containers
NO INSTANCES TO MANAGE
No EC2 Instances to provision, scale or manage
ELASTIC
Scale up & down seamlessly. Pay only for what you use
INTEGRATED
with the AWS ecosystem: VPC Networking,
Elastic Load Balancing, IAM Permissions, CloudWatch and
more.
AWS FARGATE

Huh?

Remember this?

S
e
r
v
e
r
G
u
e
s
t
O
S
S
e
r
v
e
r
G
u
e
s
t
O
S
S
e
r
v
e
r
G
u
e
s
t
O
S
S
e
r
v
e
r
G
u
e
s
t
O
S
S
e
r
v
e
r
G
u
e
s
t
O
S
S
e
r
v
e
r
G
u
e
s
t
O
S
S
e
r
v
e
r
G
u
e
s
t
O
S
S
e
r
v
e
r
G
u
e
s
t
O
S
S
e
r
v
e
r
G
u
e
s
t
O
S
S
e
r
v
e
r
G
u
e
s
t
O
S
S
e
r
v
e
r
G
u
e
s
t
O
S
S
e
r
v
e
r
G
u
e
s
t
O
S
S
e
r
v
e
r
G
u
e
s
t
O
S
S
e
r
v
e
r
G
u
e
s
t
O
S
S
e
r
v
e
r
G
u
e
s
t
O
S
S
e
r
v
e
r
G
u
e
s
t
O
S
S
e
r
v
e
r
G
u
e
s
t
O
S
S
e
r
v
e
r
G
u
e
s
t
O
S
S
e
r
v
e
r
G
u
e
s
t
O
S
S
e
r
v
e
r
G
u
e
s
t
O
S
S
e
r
v
e
r
G
u
e
s
t
O
S
S
e
r
v
e
r
G
u
e
s
t
O
S
S
e
r
v
e
r
G
u
e
s
t
O
S
S
e
r
v
e
r
G
u
e
s
t
O
S
S
e
r
v
e
r
G
u
e
s
t
O
S
S
e
r
v
e
r
G
u
e
s
t
O
S
S
e
r
v
e
r
G
u
e
s
t
O
S
S
e
r
v
e
r
G
u
e
s
t
O
S
S
e
r
v
e
r
G
u
e
s
t
O
S
S
e
r
v
e
r
G
u
e
s
t
O
S
S
e
r
v
e
r
G
u
e
s
t
O
S
S
e
r
v
e
r
G
u
e
s
t
O
S
S
e
r
v
e
r
G
u
e
s
t
O
S
S
e
r
v
e
r
G
u
e
s
t
O
S
S
e
r
v
e
r
G
u
e
s
t
O
S
S
e
r
v
e
r
G
u
e
s
t
O
S
S
e
r
v
e
r
G
u
e
s
t
O
S
S
e
r
v
e
r
G
u
e
s
t
O
S
S
e
r
v
e
r
G
u
e
s
t
O
S
S
e
r
v
e
r
G
u
e
s
t
O
S
S
e
r
v
e
r
G
u
e
s
t
O
S
S
e
r
v
e
r
G
u
e
s
t
O
S
S
e
r
v
e
r
G
u
e
s
t
O
S
S
e
r
v
e
r
G
u
e
s
t
O
S
S
e
r
v
e
r
G
u
e
s
t
O
S
S
e
r
v
e
r
G
u
e
s
t
O
S
S
e
r
v
e
r
G
u
e
s
t
O
S
S
e
r
v
e
r
G
u
e
s
t
O
S
S
e
r
v
e
r
G
u
e
s
t
O
S
S
e
r
v
e
r
G
u
e
s
t
O
S
S
e
r
v
e
r
G
u
e
s
t
O
S
S
e
r
v
e
r
G
u
e
s
t
O
S
S
e
r
v
e
r
G
u
e
s
t
O
S
S
e
r
v
e
r
G
u
e
s
t
O
S
S
e
r
v
e
r
G
u
e
s
t
O
S
S
e
r
v
e
r
G
u
e
s
t
O
S
S
e
r
v
e
r
G
u
e
s
t
O
S
S
e
r
v
e
r
G
u
e
s
t
O
S
S
e
r
v
e
r
G
u
e
s
t
O
S
S
e
r
v
e
r
G
u
e
s
t
O
S
Running one container is easy…
Managing many containers is hard

Scheduling and Orchestration
Cluster Manager Placement Engine
Availability Zone #1 Availability Zone #2 Availability Zone #3
ECS makes it easier

Elastic Container Service (ECS)
Easiest way to deploy and
manage containers!
Integration with entire AWS platform
ALB, Auto Scaling, Batch, Elastic Beanstalk, CloudFormation,
CloudTrail, CloudWatch Events, CloudWatch Logs, CloudWatch
Metrics, ECR, EC2 Spot, IAM, NLB, Parameter Store, Route53, and
VPC
Scales to support clusters of any size
Service integrations (like ALB and NLB) are at container
level
1
2
3

But not totally hands off

Fargate lets you focus on your application

“When someone asks you for a sandwich, they
aren’t asking you to put them in charge of a global
sandwich logistic chain. They just want a
sandwich.”
P.S., the sandwich is
Fargate

And people are using it!

Entire website runs as microservices. Ruby &
GraphQL backend with node.js frontend
Needed ability to scale quickly, schedule multi-container
workloads, network layer control
All in on AWS—Moved entire infrastructure to AWS and
Fargate in Jan 2018
Fargate scales quickly with traffic spikes, making it easy to
handle new announcements and viral campaigns

Public
Subnet
Private
Subnet
CDN
External
ALB
Backend Web External
API External
Frontend Web
External
Card/Scraper
Service
Background
Job Queues
Background
Workers
Internal
ALB Background Web
Internal

“We moved to Fargate because we need
the ability to scale quickly up from
baseline, run multi-container workloads,
and get fine-grained network control,
without having to manage our own
infrastructure.”

AWS Fargate Customers

The easiest way to think about Fargate is in
comparison to ECS in EC2 mode.

Instances: standard
EC2 boxes. Once
registered to a
Cluster, your Tasks
run here
Services: layer that
manages and
places tasks
Tasks: container wrapper
and configuration around
processes running on the
instance
How do the pieces of ECS map to traditional
workloads?

Instances Services Tasks
So what are you responsible for with ECS?

• In EC2 mode, you’re responsible for configuring all three of those pieces: instances,
services, and tasks.
• Instances are configured through the ecs-optimized AMI (or your own AMI), and/or
you can configure with EC2 user-data
• Services and Tasks (and containers) are all configured through the ECS API, which
you can either access directly, or go through the CLI. Tasks are defined through Task
Definitions, and Containers are defined through Container Definitions.
So what are you responsible for with ECS?

• Choose your own instance type, with any combination of resources
• Controlled through the Service ASG launch configuration, like with any other EC2
cluster.
• Supports GPUs, spot instances, RIs, etc.
How does compute work in ECS?

Got it? Fargate has some similarities and
differences.

Same Task
Definition schema
Use ECS APIs to
launch Fargate
Containers
Easy migration –
Run Fargate and
EC2 launch type
tasks in the same
cluster
Share primitives
like VPC,
CloudWatch, IAM
with ECS

Instances Services Tasks
So what are you responsible for with Fargate?

• In EC2 mode, you’re responsible for configuring services and tasks
• Instances are not configured by you, you can ONLY configure at the container/task
level
• Services and Tasks (and containers) are all configured through the ECS API, which you
can either access directly, or go through the CLI. Tasks are defined through Task
Definitions, and Containers are defined through Container Definitions.
What are you responsible for with Fargate?

How does compute work in Fargate?
CPU Memory
256 (.25 vCPU) 512MB, 1GB, 2GB
512 (.5 vCPU) 1GB, 2GB, 3GB, 4GB
1024 (1 vCPU) 2GB, 3GB, 4GB, 5GB, 6GB, 7GB, 8GB
2048 (2 vCPU) Between 4GB and 16GB in 1GB increments
4096 (4 vCPU) Between 8GB and 30GB in 1GB increments

How do you know what to choose?
Depends on your workload.
Fargate: if you can configure with just a Task Definition, and you’re ok with awsvpc
networking mode, try Fargate. Some caveats: can’t exec into the container, or access
the underlying host (this is also a good thing)
EC2 mode: good if you need to customize!

Let’s get more specific

We will build:
A TicTacToe game application, called Scorekeep on Fargate
Frontend Server
Container
Angular + Nginx
API Server
Container
Java
Internet
Port
8080
Port
5000
Load Balancer
Dynamo
DB
SNS
Configure it step by step : Compute, Networking, Storage, Permissions, Logging, and run it!

Fargate constructs

Define application containers: Image URL, CPU &
Memory requirements, etc.
register
Task Definition
create
Cluster
• Infrastructure Isolation boundary
• IAM Permissions boundary
run
Task
• A running instantiation of a task
definition
• Use FARGATE launch type
create
Service
Elastic Load
Balancer
• Maintain n running copies
• Integrated with ELB
• Unhealthy tasks automatically
replaced
Constructs

Task Definition
{
"family": “scorekeep",
"containerDefinitions": [
{
"name":“scorekeep-frontend",
"image":"xxx.dkr.ecr.us-east-
1.amazonaws.com/fe"
},
{
"name":“scorekeep-api",
1.amazonaws.com/api"
}
]
}
• Immutable, versioned document
• Identified by family:version
• Contains a list of up to 10 container
definitions
• All containers are co-located on the same
host
• Each container definition has:
• A name
• Image URL (ECR or Public Images)
• And more…stay tuned!
Task Definition Snippet

Registry support
Public Repositories
Amazon Elastic Container Registry (ECR)

Setting compute resources with Fargate

{
"family": "scorekeep",
"cpu": "1 vCpu",
"memory": "2 gb",
{
1.amazonaws.com/fe“,
"cpu": 256,
"memoryReservation": 512
},
{
1.amazonaws.com/api",
"cpu": 768,
}
]
}
Units
• CPU : cpu-units. 1 vCPU = 1024 cpu-units
• Memory : MB
Task Level Resources:
• Total Cpu/Memory across all containers
• Required fields
• Billing axis
Container Level Resources:
• Defines sharing of task resources among containers
• Optional fields
Task Level
Resources
Container
Level
Resources
Task Definition Snippet

Pricing
Per-second billing. 1 minute minimum
Pay for what you provision
Billed for Task level CPU and Memory

Let’s talk about networking (baby)

Traditional Docker networking
Bridge: docker0. This is the default behavior. Containers on the same
network can communicate via IP address. No automatic service discovery.
Connect containers with ---link
None: no network interface, only local loopback (which I’ll explain shortly)
Host: connect to host network (container maps to host)

VPC integration with Fargate
172.31.0.0/16
Subnet
172.31.1.0/24
Internet
Other Entities in VPC
EC2 LB DB etc.
Private IP
172.31.1.164
Launch your Fargate Tasks into subnets
Under the hood :
• We create an Elastic Network Interface (ENI)
• The ENI is allocated a private IP from your subnet
• The ENI is attached to your task
• Your task now has a private IP from your subnet!
You can assign public IPs to your tasks
Configure security groups to control inbound & outbound
traffic
ENI Fargate
TaskPublic /
208.57.73.13 /

VPC configuration
{
"cpu": "1 vCpu",
"memory": "2 gb",
"networkMode": "awsvpc",
{
"image":"xxx.dkr.ecr.us-east-1.amazonaws.com/fe",
"cpu": 256,
},
{
"image":"xxx.dkr.ecr.us-east-1.amazonaws.com/api",
"cpu": 768,
}
]
}
$ aws ecs run-task ...
-- task-definition scorekeep:1
-- network-configuration
“awsvpcConfiguration = {
subnets=[subnet1-id, subnet2-id],
securityGroups=[sg-id]
}”
Enables ENI creation &
attachment to Task Run Task
Task Definition

ELB configuration
{
"cpu": "1 vCpu",
"memory": "2 gb",
"networkMode": “awsvpc“,
{
"image":"xxx.dkr.ecr.us-east-1.amazonaws.com/fe",
"cpu": 256,
"memoryReservation": 512,
"portMappings": [
{ "containerPort": 8080 }
]
},
{
"image":"xxx.dkr.ecr.us-east-1.amazonaws.com/api",
"cpu": 768,
"memoryReservation": 512,
"portMappings": [
{ "containerPort": 5000 }
]
}
$ aws ecs create-service ...
-- task-definition scorekeep:1
-- network-configuration
“awsvpcConfiguration = {
subnets=[subnet-id],
securityGroups=[sg-id]
}”
-- load-balancers
“[
{
"targetGroupArn": “<insert arn>",
"containerName": “scorekeep-frontend",
"containerPort": 8080
}
]”
Create Service
Task Definition

Here’s an example of an internet facing ELB setup
Public subnet Private subnet
Fargate
TaskENI
Private IP
172.31.1.164
:8080
ALB
Public IP
208.57.73.13
:80
172.31.0.0/16
172.31.2.0/24 172.31.1.0/24
Internet
Task in private subnet with private IP
ALB in public subnet with public IP
Make sure the AZs of the two subnets match
ALB security group to allow inbound traffic from
internet
Task security group to allow inbound traffic
from the ALB’s security group
Task Security GroupALB Security Group
Type Port Source
HTTP 80 0.0.0.0/0
Inbound Rule
Type Port Source
Custom TCP 8080 ALB Security Group
Inbound Rule
us-east-1a us-east-1a

Storage

Disk storage
EBS backed Ephemeral storage provided in the form of:
Volume Storage
Writable Layer Storage

Layer storage
• Docker images are composed of layers
The topmost layer is the “writable” layer to
capture file changes made by the running
container
• 10GB Layer storage available per task, across all
containers, including image layers
• Writes are not visible across containers
• Ephemeral. Storage is not available after the
task stops.
Image Layers
Writable Layer
Image Layers
Writable Layer
Container 1 Container 2
10GB per Task

Volume storage
• Need writes to be visible across
containers?
• Fargate provides 4GB volume space per
task
• Configure via volume mounts in task
definition
• Can mount at different containerPaths
• Do not specify host sourcePath
• Remember this is also ephemeral, i.e. not
available after the task stops
Container 1 Container 2
4GB Volume Storage
mount
/var/container1/data /var/container2/data

IAM permissions

Types of permissions
Cluster
Permissions
Application
Permissions
Task
Housekeeping
Permissions
Cluster
Fargate Task
Cluster Permissions:
Control who can launch/describe tasks in your cluster
Application Permissions:
Allows your application containers to access AWS
resources securely
Housekeeping Permissions:
Allows us to perform housekeeping activities around your
task:
• ECR Image Pull
• CloudWatch logs pushing
• ENI creation
• Register/Deregister targets into ELB

Visibility and monitoring

Cloudwatch logs configuration
• Use the awslogs driver to send
stdout from your application to
CloudWatch logs
• Create a log group in
CloudWatch
• Configure the log driver in your
task definition
• Remember to add permissions
via the Task Execution Role
{
...
{
...
"logConfiguration": {
"logDriver": "awslogs",
"options": {
"awslogs-group": "scorekeep",
"awslogs-region": “us-east-1",
"awslogs-stream-prefix": "scorekeep/frontend“}}
},
{
...
"logConfiguration": {
"logDriver": "awslogs",
"options": {
"awslogs-group": "scorekeep",
"awslogs-region": “us-east-1",
"awslogs-stream-prefix": "scorekeep/api"}}
}
]}
Task Definition

CloudWatch logs
Logs Tab in the
Task Detail Page
View logs in the ECS or Cloudwatch Console

Other visibility tools
Service CPU/Memory utilization metrics
available in CloudWatch
CloudWatch events on task state changes

What did we learn about Fargate?

• Fargate is a new launch type within ECS to run containers without having to manage EC2 instances
• If you’re debating between EC2 v/s Fargate mode, start architecting with Fargate.
It forces good design practice by keeping your application containers truly independent
of the underlying host.
• If you think you must have access to the underlying host, think again.
• There are some good reasons : special instance type needs, EC2 dedicated instances, utilizing EC2
reserved instances
• And tell us about your use case, we want to support it on Fargate!
• Start using Fargate today!
• Fargate works with most Docker container images
• You can run existing task definitions on Fargate with only minor modifications.

ECS: can be totally managed, or can customize resource usage, networking, task placement etc. to
fit your application needs. Shared responsibility with AWS (because managed service). ecs-agent is
open source. Easy integration with other AWS services.
EKS: managed, upstream Kubernetes. Can connect to clusters through kubectl and use existing
tooling. Can opt in to managed version upgrades. Add resources to your cluster through EC2
(now), or with Fargate mode (2018).
Fargate: underlying technology for containers on demand. Pass a Task Definition or Kubernetes
Pod, set resource limits, and Fargate manages everything else. NO access to underlying host, no
managing of resources. Great if you don’t want to handle scaling, orchestration, deployments,
upgrades yourself. Not for those of you that are making changes to your infrastructure (i.e.,
bringing custom AMIs, or installing things through EC2 user-data)
tl;dr

But you don’t have to do it all alone

I get by with a little help from my
friends (CLIs).

CLIs (that I know of) for Fargate/ECS:
aws-cli: the official OG. Open source, includes most AWS services.
• More info here: https://aws.amazon.com/cli/
• Github here: https://github.com/aws/aws-cli
ecs-cli: also official, but just for ECS. Supports docker compose files.
• More info here: https://github.com/aws/amazon-ecs-cli
Some good unofficial options:
Fargate cli: https://github.com/jpignata/fargate
Coldbrew cli: https://github.com/coldbrewcloud/coldbrew-cli
Mu cli: https://github.com/stelligent/mu

What’s Next?

We want to hear from all of you!
More focus on supporting Tasks as compute primitive, more
focus on removing undifferentiated heavy lifting.
Our roadmap is driven by feedback:

How can I get started?
• To get started with Fargate: https://aws.amazon.com/fargate/
• Blogs: https://aws.amazon.com/blogs/aws/aws-fargate/
• https://aws.amazon.com/blogs/aws/amazon-elastic-container-service-for-kubernetes/
• Liz Rice from Aquasec on Fargate: https://blog.aquasec.com/securing-struts-in-aws-fargate
• Nathan Peck from AWS: https://medium.com/containers-on-aws/choosing-your-container-environment-on-
aws-with-ecs-eks-and-fargate-cfbe416ab1a
• Deepak Singh (containers GM at AWS): https://www.slideshare.net/AmazonWebServices/containers-on-
aws-state-of-the-union-con201-reinvent-2017

The awesome-ecs project:
https://github.com/nathanpeck/awesome-
ecs

Workshops!
From @brentContained
https://ecsworkshop.com

Need a little help?
Community Slack channels:
awsdevelopers.slack.com
amazon-ecs.slack.com
Or reach out to one of us directly:
@brentcontained
@abbyfuller
@nathankpeck
@paulmaddox
@ric_harvey

Go build (and tell us about it)!

Thanks!
@brentContained
N E W Y O R K

Develop Containerized Apps with AWS Fargate

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Develop Containerized Apps with AWS Fargate

Similar to Develop Containerized Apps with AWS Fargate (20)

More from Amazon Web Services

More from Amazon Web Services (20)

Develop Containerized Apps with AWS Fargate