An introduction to AWS Fargate
What’s Fargate?
Introduced at re:Invent in 2017, Fargate is, according to AWS, a “technology that allows you to use containers as a fundamental compute primitive without having to manage the underlying instances.” So what exactly does this mean?
Essentially, Fargate is just a different way to launch your containers. Previously, the only option was ECS, which meant launching the container on EC2 instances in your VPC that you manage.
ECS (EC2 Container Service) has been around for a few years now, but it can sometimes carry a larger administrative burden than it’s worth. It’s much much more than just “docker in AWS”. To launch a container, which AWS refers to as a “Task Definition”, you have to publish your container to a container repository (AWS offers a managed repo known as ECR), and then build a complicated JSON file to define where the container should run, how much vCPU and RAM it can allocate for itself, what ports it needs, how it should interact with the host from a networking perspective, and so on and so forth. But wait! There’s more! In addition to configuring the containers themselves, you’re also required to deploy an ECS cluster to host the containers. An ECS cluster is simply a group of EC2s configured to run a version of docker, managed via Amazon’s ECS agent.
Even if all you want to do is launch a single ephemeral container to run a quick cron job every now and then, you’re still required to configure an ECS cluster. That means another EC2 instance (or several) to manage and, more importantly, the added costs to keep the entire ECS cluster running 24/7. Considering the current On-Demand prices in us-east-1, a single m5.large instance (2 vCPU, 8GB of RAM) will run you almost $72 a month to run full time. That’s significant sticker shock for running an ephemeral workload that’s probably just doing an occasional rsync.
To be fair, an m5.large is probably overkill to host cron jobs. But it’s somewhat irritating to resize in ECS if there are tasks running, so I always wind up oversizing my hardware anyway. For simple tasks, it’s not worth the expense or the hassle. Why not just leverage a normal m5.large running Amazon Linux without the ceremony of containerization layered on top of it? That’s where Fargate comes in.
Where’s my stuff?
Fargate is a new “Launch Type” for a Task Definition. Tasks are still built out the same cumbersome way with JSON (or in the web GUI which I find simpler), but instead of launching them onto your own ECS cluster on your own EC2s in your own VPC, the AWS gremlins whisk them away to run them elsewhere. Aside from references in the ECS GUI, a Fargate container will not appear in your AWS infrastructure.
What’s happening on the backend is that your Task Definition is shipped off to another chunk of AWS hardware under the hood, and at launch your container is pulled down and deployed. This adds the interesting requirement of a needing a Security Group with a mandatory port 80 open to 0.0.0.0/0 so the container can be pulled from the remote repository. (Fun pitfall: if you do not specify to use the same Security Group, Fargate will create a new one every time you launch a container. Even if it’s the same container repeatedly. Boo!)
How does this help?
Remember the $72/month cost to run a single m5.large instance to host your single cron job? With Fargate, you pay only for execution time. Because the hardware is not in your account, you are not responsible for the costs of running it. The flip side is, due to the intended use case of short lived tasks, Fargate is approximately 5x more expensive than EC2 per hour. However, prices are based off the vCPU and RAM requirements of the container, so there’s no need to “buy ahead” with over-provisioned thick instances. Instead of deploying an “always-on” m5.large at $72/mo, you might pay $0.06/hour to run a Fargate task. And that’s per hour. A cron job may only take a few minutes, or even a few seconds, making this an essentially free service when leveraged properly.
To be clear: Fargate is NOT cost effective for permanent, always-on services. With microservices architectures becoming more prevalent, it’s trendy to leverage containers for APIs, web apps, etc. Do NOT run NGINX on Fargate, it will be extremely expensive. Fargate pricing for the same m5.large hardware (2 vCPU and 8GB of RAM) costs $150/mo, almost double the price of an m5.large.
Is this a disingenuous comparison? Absolutely. An NGINX container can happily run with far less resources and if that’s the only container, costs will likely be less or with negligible differences than running a thick ECS cluster on your own EC2s. However, at scale, the choice between Fargate and EC2 Launch Types becomes crucial when considering the TCO of your containerized workload.
What’s the catch?
Fargate is an excellent platform for ephemeral workloads on AWS. There are certain limitations to keep in mind when using a Fargate Launch Type for your containers, notably:
- Spin up time: Because resources must be deployed elsewhere to host the workloads, there is a delay between when the service is requested, and actually launched (generally a few seconds, but noticeable). There is significantly less latency hosting your own ECS cluster on EC2.
- Volume sizes: Again, due to the remote launch, Fargate can only address local volumes up to 10GB in size. Anything larger must be hosted locally, or pulled from elsewhere like S3.
Scheduling: As of this writing, Fargate containers cannot be scheduled with the native ECS tools. To launch on a schedule, you must leverage Lambda and CloudWatch.
Use Fargate whenever there’s a need for some kind of ephemeral service (a cron job, or a short lived app), but leverage ECS on EC2 for longer running tasks and always-on services.
Edit: As of 8/28/18, Fargate now has the ability to natively schedule tasks. See the full post from AWS
