“The number of processor units reserved for the container. The instance container has 1024 bytes for each CPU core. This parameter specifies the minimum amount of CPU to reserve for the container and the containers share unallocated CPU blocks with other containers on with the same ratio as their allocated amount. This map option in CpuShares is in the Create Docker Container Remote API section and the -cpu-shares option to launch dockers. "
A t2.medium has 2 vCPUs, so it has 2048 available CPU blocks for the schedule. If you want only one container per host, you can save all 2048 CPU units, but no other containers will be hosted on this host.
Containers are always guaranteed to get at least their budget processor when they need it. In addition, the neat thing about CPU blocks is that a container can burst above its allocated units if other containers do not occupy this resource. For example, if you have two tasks running on t2.medium, each of which has 1024 CPU blocks, each task can be played separately until 2048, provided that the other task was completely inactive. When you start sharing hosts this way, you can really squeeze the cost savings from using ECS.
In addition, if all CPU units are not included in the budget, ECS will automatically distribute the remaining CPU units in each container with respect to their budget CPU units. Therefore, if you have two tasks running on t2.medium, each of which has 0 CPU blocks, each container will effectively receive 1024 CPU blocks, since no other container has reserved them.
It should be noted here that memory works differently; This is a hard limit. If the container ever tries to allocate more memory than budgeted, the task / container will exit. You can underestimate CPU units and usually move away from it (because containers may burst above their supply), but you need to make sure that you stay within your memory limits.
Example: If you set the value to 0, it will take a proportional amount of unsupported CPU. Suppose these scenarios are on t2.mediums with 2048 CPU units:
Task No. 1 - 0 CPU, Task No. 2 - 0 CPU: In this situation, tasks No. 1 and Task No. 2 will be given 1024 CPU blocks, since there are 2048 units without support. Since the tasks for reserving a CPU block are 1: 1, they will both receive an equal share of the available CPU blocks.
Task No. 1 - 0 CPU, Task No. 2 - 1024 CPU blocks: Task No. 2 will be provided 2048 CPU units, and Task No. 1 will be given 0, since it is trying to split 1024 unused CPU blocks in a ratio of 0: 1,024.
Task No. 1 - 0 CPU: If there is only one task on the machine, it will be provided with all 2048 CPU units, since all units are not used, they are divided between containers in terms of their reservation.