Study notes for Amazon ECR + ECS + EKS.
These three services provide the basis of using serverless containers on AWS.
ECR is a fully managed Docker registry for pushing and pulling OCI images from.
EKS is a fully managed Kubernetes control plane, and ECS is Amazon’s “kubernetes clone” that has less features, but is cheaper to run.
Images, ECR, and Caching
The Elastic Container Registry (ECR) is a fully managed Docker image registry. You can push and pull images from ECR, and ECR is integrated into other AWS services such as ECS, EKS, and AWS Amplify.
Sadly, AWS Amplify can only pull images from public ECR repositories. It took me a while to figure this out, but once I switched my container to a public registry, everything worked fine.
Another limitation of ECS and EKS is that they do not cache images they pull during startup. This means that you will have to wait an additional amount of time for your ECS tasks/EKS deployments to pull the image(s) and start.
Thankfully, there is an open issue in the roadmap to add image caching to ECS and EKS which is currently (August, 2024) being worked on. There are other options such as using EC2 backed ECS, or by prefetching images on EKS by following this guide by AWS.
Amazon EKS
Amazon Elastic Kubernetes Service (EKS) is a fully managed EKS control plane in the cloud.
This can be helpful for migrating existing Kubernetes workloads into the cloud, and there are ways of using EKS on premises as well.
If your organization uses Amazon Outposts, then you can deploy EKS clusters to your outpost.
If you want to save a bit of cash, you can deploy Amazon EKS Anywhere to your own hardware, including bare metal!
EKS Anywhere is an open source solution for creating and managing an EKS cluster on your on-premises hardware, so you don’t have to pay extra.
It does mean more work for you because now you must manage upgrades and provisioning and maintaining hardware, but for smaller operations that is just fine.
EKS has a slightly more complex pricing model than ECS that comes from the managed control plane.
If your control plane is using an up to date (standard support) version of Kubernetes, then it costs an additional $0.10/hour per cluster. If your control plane falls behind on updates and runs an older version (extended support) of Kubernetes, then it costs an additional $0.60/hour per cluster.
Eventually, AWS will automatically upgrade your control plane version to the oldest extended support version if the version you are running becomes depreciated.
Recommended Reading
- AWS ECS/EKS roadmap repo
- AWS EKS Bast Practices Guides
- Understanding the Kubernetes version Lifecycle on EKS