What does 'cpu' parameter mean in aws container service?

Question

I'm going to register a new task in container service for t2.medium. I saw examples where CPU parameter is equal to 0. I'm trying to find out what is it and how many I need to put here for one task.

All that I was able to find according to this question: http://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html?shortFooter=true http://docs.aws.amazon.com/AmazonECS/latest/developerguide/example_task_definitions.html

Answer 1

"The number of CPU units to reserve for the container. A container instance has 1,024 CPU units for every CPU core. This parameter specifies the minimum amount of CPU to reserve for a container, and containers share unallocated CPU units with other containers on the instance with the same ratio as their allocated amount. This parameter maps to CpuShares in the Create a container section of the Docker Remote API and the --CPU-shares option to docker run."

A t2.medium has 2 vCPUs, so it has 2,048 available CPU units to schedule out. If you would like only one container running on the host you'll budget all 2,048 CPU units, but no other containers will ever be placed on that host.

Containers are always guaranteed to get a minimum of their budgeted CPU when they need it. Additionally, a neat thing about CPU units is that a container can burst above its allocated units if no other containers are taking up the resource. For instance, if you have two tasks running on a t2.medium, each with 1,024 budgeted CPU units, each task could individually burst up to 2,048 given that the other task was completely idle. When you begin sharing hosts this way, you can really squeeze the cost savings out of using ECS.

Additionally, if all of the CPU units are not budgeted out, ECS will automatically divvy up the remaining CPU units to each container at the ratio of their budgeted CPU units. So if you've got 2 tasks running on a t2.medium each with 0 CPU units, each container will effectively get 1,024 CPU units since no other container has reserved them.

One thing to note here is that memory works a bit differently; it is a hard limit. If the container ever tries to assign more memory than it's budgeted, the task/container will exit. You can underprovision CPU units and usually get away with it (because containers can burst higher than their provision), however, you would like to make sure you stay within your Memory constraints.

---

Example: If you set it to 0, it will take a proportionate amount of the unreserved CPU. Assume these scenarios are on t2.mediums with 2,048 CPU units:

Task #1 - 0 CPU units, Task #2 - 0 CPU units: In this situation, both Task#1 and Task#2 will be given 1,024 CPU units, since there are 2,048 unreserved units. Since the tasks are 1:1 for CPU unit reservations, they will both get an equal share of the available CPU units.

Task #1 - 0 CPU units, Task #2 - 1,024 CPU units: Task #2 will be given 2,048 CPU units and Task#1 will be given 0 since it is trying to divvy up 1,024 unused CPU units at a ratio of 0:1,024.

Task #1 - 0 CPU units: If only one task is on the machine, it will be given all 2,048 CPU units since all units are unused, they are split among the containers at a ratio of their reservation.