AWS Service of the Week – Elastic Container Service
Hey there! Welcome back for another look at AWS Service of the Week. You may recall that in my last blog post I mentioned it was going to be a two part piece, due to the breadth of information to cover about Containers. I hope you enjoyed the first part of this blog, and now understand the core concepts of Containers, and Elastic Container Registry (ECR), that is offered by AWS. Now the time has come to dive into the Elastic Container Service (ECS) offering.
Elastic Container Service
The official definition about Elastic Container Service (ECS) from AWS is as follows “Amazon Elastic Container Service (Amazon ECS) is a highly scalable, high-performance container orchestration service that supports Docker containers and allows you to easily run and scale containerized applications on AWS”. There is one very important key phrase in that which is Container Orchestration, which we will discuss.
A Container Orchestrator is a tool which manages the lifecycle of containers that run on a host. It could be that a container has failed its health check for some reason, so the orchestrator will deploy a new identical copy of it and dispose of the broken container. It could monitor the health of the hosts that the containers function on, and make sure it is working as expected. If it finds a fault it could create a new host and move all containers to that host. Essentially the function of the orchestrator is to get my containers started and keep them working.
Standard ECS v Fargate ECS
ECS comes in two flavours, the Standard ECS, and the Fargate ECS. The Standard ECS, creates EC2 hosts, using an AMI (Amazon Machine Image) that has Docker installed. With the right credentials you can connect into the host and perform additional tasks for your business needs. Fargate is a further abstracted service, where you do not have access to any EC2 host or associated infrastructure, all you care about is your container, and that it runs and functions as expected.
Personally, I have found that there is more setup options and configuration with the Fargate service, however once it is running, there is much less day to day interactions required with the service. Another consideration to take into account is that the two flavours have completely different pricing models. With the standard ECS you pay the standard EC2 and EBS storage charges, however with Fargate you are paying for vCPU and memory resources on a per second charge.
Tasks in ECS
ECS has the concept of a task, which is very closely aligned to the terminology of a service in the Docker world. To create a container in ECS, you provide a Task Definition JSON file, which describes what registry the image exists in (ECR or a 3rd party), the metadata (name etc), the resource requirements (CPU and memory), shared volumes, and if this task is made up of more than one container, and how they are linked together.
One awesome feature with containers and ECS is that you can be very granular with creating least privilege access polices on IAM for each container. For example, if container A needs access to secure string A in the Systems Manager Parameter Store, and container B needs access to an S3 Bucket. You can create policies directly attached to the task, and not the host that controls these tasks. This means that your containers have the absolute limited amount of access that they need and cannot access resources that they have no need to.
Management for Windows Containers
Even if your organisation is integrated with the Windows environment, this does not pose a problem for ECS as it supports management for Windows containers, with use of a Windows AMI. It must be worth noting that whilst you can make containers based off of Windows images, they have tended to be sized in the GB’s, whereas with Linux images, they are usually in the MB’s of storage. This can have an impact when a new host is create and it needs to download the image layers from the registry, it could create significant downtime for a Windows based image if the network latency is poor. Alternatively making a shared storage option with EFS, and have the images stored there for faster access may alleviate this concern.
My thanks again for dropping by, and I really hope you have enjoyed this bumper 2 part edition dedicated to the world of containers on AWS.