How fast can ECS fargate boot a container?

Question

What the the minimum/average time for AWS ECS Fargate to boot and run a docker image?
For arguments sake, the 45MB anapsix/alpine-java image.

I would like to investigate using ECS Fargate to speed up the process of building software locally on a slow laptop/pc, by having the software built on a faster remote server.
As such the boot up time of the image is crucial in making the endevour worth while.

Weylin

Answer 1

I would disagree with the accepted answer given my experience with Fargate.

I have launched 1000's of containers on Fargate, and was even featured in an AWS architecture blog for our usage of Fargate. https://aws.amazon.com/blogs/architecture/building-real-time-ai-with-aws-fargate/

Private subnets, behind a NAT gateway have no different launch times for us than containers behind an IGW. If you use single NAT instances sure, your mileage may vary.

Container launch times in Fargate are entirely determined by how large your container is. Fargate does not cache containers, so every run task results in a docker pull happening. If your images are based on Ubuntu, you will have a bad time.

We have a mix of GO from scratch containers and Alpine node containers.

On average based on the metrics we have aggregated from 1000's of launches, From scratch containers start and are healthy in the target group in 10-15 seconds.

Alpine containers take on average 30-40 seconds to launch and become healthy.

Anything longer than that and your containers are likely too large for Fargate to make any sense until they offer pre cached ecr or something similar.

For your specific example, we have similar sized containers, if your entrypoint is healthy quickly (Ie not a 60 second java start time), your container of 45mb should launch and be ready to go in 30-60 seconds.

Lowgrade

Ive changed the accepted answer to yours, given that the performance characteristics of fargate are likely to continue to change, im happy to accept newer more up to date answers. – Weylin

Huh. Our containers still take ~4 mins but they include Chrome, Java, Node JS, etc. as well as our code, build, npm repo and so on. I don't think a 45 MB container is realistic for my purposes, honestly. Our code base alone, with all libraries, is around 850 MB. Our total container as reported by ECS is ~1.7 GB. – Rolanda

This is an interesting comparison of docker container sizes: brianchristner.io/docker-image-base-os-size-comparison – Rolanda

@RyanShillington talking to the fargate PM's they should be releasing some form of caching at some point in the near future, so you can pre-cache your specific images for a price, and it will greatly increase launch times for situations like yours. – Lowgrade

Are you able to launch 1000 fargate task on a region on a single account? The limit seems to be 100? docs.amazonaws.cn/en_us/AmazonECS/latest/developerguide/… how are you able to do so? – Dardani

@Dardani of course. The 100 limit is default limit. Just put in a request to increase (this applies to pretty much anything in AWS). – Lowgrade

Answer 2

I am still waiting for caching in Fargate that is already available in ECS+EC2. This feature request can be tracked here. It is a pain in the ass that containers take such a long time to boot on AWS Fargate. Google Cloud Platform already offers this feature as generally available with a managed Cloud Run (K8s) environment, where containers spin up on the fly (~ 2 seconds) when they receive a request. They go idle after (a configurable) 5 minutes, which causes you to only be billed for those 5 minutes.

AWS Fargate does not offer such a nice feature of "warm containers" yet, although I would highly recommend them in doing so. It is probably technically difficult in getting compute and storage close together to accomplish this, it would require an enormous amount of internal bandwidth to load those containers as fast as Google does.

Nevertheless, below is my experience with Docker containers on AWS Fargate. Boot time is highly correlated with container image size as you can see from the following sample of containers I booted (February 2019):

4000 MB ~ 5 minutes
2400 MB ~ 4 minutes
1000 MB ~ 2 minutes
350 MB   ~ 50 seconds

I would recommend building your container image on a light-weight base image, such as Minideb or Alpine. This would make your container image pretty small, ranging from a few 10MBs to a few 100MBs. But then again, when you need a JVM or Python with some additional packages and c-libs, you would easily go to 1000 MB.

Brien

Answer 3

I've launched more than 100 containers now in Fargate and on a public VPC they take about 4 mins on average, but I've seen it as long as 7-8 mins on a bad day.

If you launch it on a Private VPC then the timing can go south in a hurry. I've seen it take 2 hours to launch a Fargate container if the NAT instance is overloaded.

Hopefully AWS will speed this up over time. It shouldn't take me longer to launch a Fargate container than it does to upload my docker image to ECR.

Rolanda

Totally agree. I searched for the answer to understand, why it takes so much time to redeploy, and it seems like ´normal´ behaviour :( – Intercommunion

The bottleneck there is your NAT instance, not Fargate or ECR. Good justfication for a NAT Gateway – Nitroso

Answer 4

One could use ECS_IMAGE_PULL_BEHAVIOR = prefer-cached on EC2 launch type to reduce agent start up timings to great extent.

Flounce

Not possible with Fargate, see open issue: github.com/aws/containers-roadmap/issues/696 – Brien