Search code examples
amazon-web-servicesdockeramazon-ecs

Rule of Thumb for AWS ECS Service Memory or CPU requirements

I am using AWS ECS for deploying my website. Now I want to know -

  1. If there is any rule of thumb or any way to determine the memory or cpu size for the services?
  2. Or any way to determine the family instance of EC2 for cluster?
  3. Is it better to use Fargate over EC2 for cost saving?
  4. What is the better way to use autoscaling in AWS ECS?

I have two task definitions -

  1. Web server to serve html, css, JS (Frontend Server)
  2. Microservices (Backend Server)
Solution

    1. Actually run the services with some representative load. Watch with a tool like top(1) which can tell you the actual memory use (in top, look for an rss or rsz column) and CPU utilization. The resource utilization of any given service is incredibly dependent on language choice, runtime, load, concurrency, algorithmic decisions, database constraints, .... and there really is no rule of thumb.

    2. Match up your actual measured resource utilization, some hypothetical deployment plan, and the AWS EC2 instance types listing. If you have 4 services that each require 1 full CPU core and 1 GB of RAM, and you want to run 3 replicas of each, then you need a total of 12 cores and 12 GB of RAM; if you want this spread across 3 hosts, then 3x c5.xlarge instances gives you 12 cores and 24 GB of RAM.

    3. In general the managed AWS services are not cheaper than running the same service yourself on bare EC2 instances. In the case of Fargate, it's priced by the CPU-hour and GB-hour for scheduled tasks. As of this writing the hypothetical workload I described above would cost about US$0.54 per hour in us-east-1; for EC2 on-demand usage the 3x c5.xlarge instances would cost US$0.51 per hour (and this gets cheaper if you're able to commit to buying reserved instances). If your workload is very bursty it might be easier to schedule and unschedule ECS tasks than EC2 instances, and the Fargate pricing model might work better for you.

    4. The ECS documentation has a tutorial on setting up CloudWatch and an auto-scaling group to automatically expand a cluster. Scaling down is a little trickier (you need to set the instance to drain, wait for tasks to actually move, and then deprovision it).

    5. If you're in an all-AWS environment anyways, consider hosting static content directly in S3. This will probably be cheaper and easier to manage than running a dedicated server.