<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Containers on 🏠</title><link>https://tofl.github.io/docs/10-containers-ecs-ecr-fargate/</link><description>Recent content in Containers on 🏠</description><generator>Hugo</generator><language>en-us</language><atom:link href="https://tofl.github.io/docs/10-containers-ecs-ecr-fargate/index.xml" rel="self" type="application/rss+xml"/><item><title>32. ECS</title><link>https://tofl.github.io/docs/10-containers-ecs-ecr-fargate/ecs/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tofl.github.io/docs/10-containers-ecs-ecr-fargate/ecs/</guid><description>&lt;h2 id="ecs-elastic-container-service"&gt;ECS (Elastic Container Service)&lt;a class="anchor" href="#ecs-elastic-container-service"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;Modern applications are increasingly built as collections of small, independent services packaged in containers. Containers are lightweight, portable, and consistent across environments — but running them reliably at scale introduces real operational complexity: Where do containers run? How do you restart failed ones? How do you distribute traffic? ECS is AWS&amp;rsquo;s answer to these questions. It is a fully managed &lt;strong&gt;container orchestration service&lt;/strong&gt; that handles scheduling, placement, scaling, and lifecycle management of Docker containers on your behalf — without requiring you to operate Kubernetes.&lt;/p&gt;</description></item><item><title>33. ECR</title><link>https://tofl.github.io/docs/10-containers-ecs-ecr-fargate/ecr/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tofl.github.io/docs/10-containers-ecs-ecr-fargate/ecr/</guid><description>&lt;h2 id="ecr-elastic-container-registry"&gt;ECR (Elastic Container Registry)&lt;a class="anchor" href="#ecr-elastic-container-registry"&gt;#&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;When you containerize applications, you need somewhere reliable to store, version, and distribute your Docker images. ECR is AWS&amp;rsquo;s fully managed container registry that solves exactly this: it gives you a private, secure, and highly available place to push images from your CI/CD pipeline and pull them into ECS, Fargate, or EKS at deploy time. Because ECR lives inside AWS, image pulls stay on the AWS network — no egress costs, lower latency, and no dependency on Docker Hub availability. &lt;a href="https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html"&gt;🔗&lt;/a&gt;&lt;/p&gt;</description></item><item><title>34. Fargate</title><link>https://tofl.github.io/docs/10-containers-ecs-ecr-fargate/fargate/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tofl.github.io/docs/10-containers-ecs-ecr-fargate/fargate/</guid><description>&lt;h1 id="fargate"&gt;Fargate&lt;a class="anchor" href="#fargate"&gt;#&lt;/a&gt;&lt;/h1&gt;
&lt;p&gt;AWS Fargate is a serverless compute engine for containers that works with both ECS and EKS. It eliminates the need to provision, configure, or manage EC2 instances for running containers — you define what your container needs (CPU, memory, networking), and AWS handles everything underneath. Fargate exists to solve a very specific operational burden: cluster capacity management. With EC2 launch type, you&amp;rsquo;re responsible for the EC2 instances that form your cluster — choosing instance types, managing scaling of the underlying fleet, patching the OS, and ensuring there&amp;rsquo;s always enough capacity. Fargate removes that entirely. You pay per task, per second, for exactly the resources your container consumes. &lt;a href="https://docs.aws.amazon.com/AmazonECS/latest/developerguide/AWS_Fargate.html"&gt;🔗&lt;/a&gt;&lt;/p&gt;</description></item></channel></rss>