How ECS Service CPU Utilisation is calculated when Task CPU is not given and Container CPU is 0



For my ECS Service, the task cpu is not set and both the containers in the task have 0 vcpu set. Based on the documentation the CPU Utilisation is calculated based on the below equation

                                      (Total CPU units used by tasks in service) x 100
Service CPU utilization =  ----------------------------------------------------------------------------
                           (Total CPU units specified in task definition) x (number of tasks in service)

Since CPU Units are zero, I was thinking the utilization won't be reported altogether. but I'm seeing CPU Utilisation for my ECS Service. I'm now trying to understand the meaning of values given in the CPU Utilisation. current average is 20%, now what does 20% mean? because 100% is unclear, I'm unable to understand the meaning of 20%

Enter image description here

2 Answers


Thank you for your question.

Let's review what does the value of 0 CPU means.

In the "new ECS experience" console, if you click on the info section for container size, you will see the below:

Container Size - Info

CPU - The number of CPU units the Amazon ECS container agent will **reserve** for the container.

So it means that the 0 value for cpu is just telling the ecs agent to not reserve any cpu at the start of the container(can be thought of as soft limit). This does not mean though that the container won't be able to access any cpu during runtime.

Having said that, please also check what in reality happens at the backend when you mention the value of cpu as 0 (or less than 2). If you check this link for task definition parameter , you can see under Environment --> cpu (translates to where this value used to be in the old ECS console) the following:

On Linux container instances, the Docker daemon on the container instance uses the CPU value to calculate the relative CPU share ratios for running containers. For more information, see CPU share constraint

in the Docker documentation. The minimum valid CPU share value that the Linux kernel allows is 2. However, the CPU parameter isn't required, and you can use CPU values below two in your container definitions. For CPU values below two (including null), the behavior varies based on your Amazon ECS container agent version:

    Agent versions <= 1.1.0: Null and zero CPU values are passed to Docker as 0, which Docker then converts to 1,024 CPU shares. CPU values of one are passed to Docker as one, which the Linux kernel converts to two CPU shares.

    Agent versions >= 1.2.0: Null, zero, and CPU values of one are passed to Docker as two CPU shares.

Now, for your usecase, where there is no task definition resources mentions, let's see what will happen when you mention just the container resources cpu (this translates to soft limit) and memory (this translates to hard limit for container, i.e. container won't be able to use more than the memory mentioned here. Please note that the old ecs console had an option to mention memoryReservation which is not yet supported in the new console ).

So if you look at this link which describes how ecs manages cpu and memory resources, you will find that, for your use-case, the container has hard limits for memory and hence limited by the resource mentioned by you, i.e. the containers will have guaranteed reservation of 1.366 and .586 GB memory at all times and also they will be able to use only upto 1.366 and .586 GB respectively. If you were using the old ECS console, you could have also mentioned memoryReservation such that your containers when started are guaranteed say 256 MB of memory in the host and then can scale upto memory parameter you have mentioned, if available in the host(1.366 and .586 GB). This would have helped if you are trying to fit more containers in the instance, as when your containers are not using all 1.366GB of memory, the remaining memory could be used to accommodate other containers.

In the link above you will find various scenarios of how your cpu and memory boundaries are defined for containers. Important point to note will be that if containers have a memory limit(either at container level, task level or restricted at host level) this will be killed by OOM. Whereas the cpu limit at the container level is soft limit and when there is contention between different process(containers) running on the host for the CPU, the processes(containers) rather than getting killed get throttled(based on the ratio of the soft limit defined either explicitly or the default value or overall task limit, if defined).

Hope this have helped you understand your scenario better.

profile picture
answered a year ago
  • I'm still unable to understand the meaning of 20% cpu utilisation. does it mean the task is using 0.2vcpu or it is using 0.0004 vcpu (20% of 2 shares comes approximately to 0.0004 vcpu)?

  • Based on your use case, you have 2 containers per tasks with 2 cpu units container each, i.e 4 CPU unit per task definition. Let's say you are running service with 1 task, it would mean that if you see 20% cpu utilisation at the service level, the service is using 0.8 CPU which translates to 0.00078125 vcpu (1 vCPU being 1024 CPU).

  • 0.00078125 vCPU for a value of 20% CPU Utilisation ... doesn't seem right... According to that, 100% would be just 0.0039 vCPU...


It's not well documented how CPU Utilisation is calculated when CPU reservation is not set in the task definition...

Could 20% CPU Utilisation represent (Total CPU units used by tasks in service x 100) / (Total CPU units of the EC2 instances where these tasks are running)?

Jorge A
answered 9 months ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions