Containers on AWS Overview: ECS | EKS | Fargate | ECR

Summary

This video provides a high-level overview of container services on AWS, discussing ECS (Elastic Container Service), EKS (Elastic Kubernetes Service), EC2, AWS Fargate, and ECR (Elastic Container Registry). It explores how each service manages containerized applications, comparing ECS and EKS in terms of flexibility, orchestration, and scalability. It also covers AWS Fargate’s serverless infrastructure management and how ECR integrates with other AWS services. The video is designed to help users choose the right AWS container service based on their application requirements and infrastructure needs.

Takeaways

• 🚢 AWS offers multiple container services depending on application requirements, including ECS, EKS, EC2, Fargate, and ECR.
• 📦 ECS (Elastic Container Service) is a container orchestration service that manages the lifecycle of containers, including scheduling, restarting, and load balancing.
• 🔄 EC2 instances with Docker installed can host containers, but require manual management of infrastructure, including operating systems and resource allocation.
• ⚙️ Fargate provides a serverless way to run containers on AWS, automatically provisioning the necessary infrastructure for each container and scaling resources as needed.
• 💸 Fargate offers a cost-efficient option since users only pay for the resources consumed by the containers, unlike EC2 where you pay for the entire server.
• 🔧 EKS (Elastic Kubernetes Service) allows users to run Kubernetes clusters on AWS, giving them the flexibility to manage infrastructure with Kubernetes tools and easily migrate clusters to other platforms if necessary.
• ☁️ ECS is ideal for simpler applications, while EKS is more suitable for complex applications that require Kubernetes and its ecosystem of plugins and tools.
• 🌍 AWS services, including CloudWatch, ELB, IAM, and VPC, integrate well with ECS, EKS, and Fargate, providing robust options for monitoring, networking, and permissions.
• 🔑 ECR (Elastic Container Registry) is a container image repository that integrates with AWS services, making it easier to manage Docker images and automate deployment workflows.
• 🚀 AWS infrastructure management with ECS, EKS, Fargate, and ECR simplifies the deployment and scaling of containerized applications, with various options depending on the level of control and automation needed.

Q & A

What is Amazon ECS, and how does it help manage containers?

Amazon ECS (Elastic Container Service) is a container orchestration service that manages the lifecycle of containers, including scheduling, load balancing, and restarting them. It helps manage container clusters by automating processes and reducing manual efforts when dealing with large numbers of containers.

What are the advantages of using AWS Fargate compared to EC2 instances in ECS?

AWS Fargate is a serverless way to run containers without provisioning or managing EC2 instances. It automatically provisions server resources based on container needs and scales on demand, reducing costs by only charging for the resources used. Unlike EC2, where you manage the servers, Fargate handles the infrastructure, simplifying operations.

How does Kubernetes differ from ECS in terms of portability and ecosystem tools?

Kubernetes (EKS) is an open-source container orchestration tool that can be used across multiple platforms, not just AWS, making it more portable than ECS. EKS allows users to access Kubernetes' wide range of plugins and tools, such as Helm, while ECS is more tightly integrated with AWS-specific services and does not offer the same portability.

What role does ECR play in AWS container services?

ECR (Elastic Container Registry) is a container image repository service that integrates with other AWS services like ECS and EKS. It serves as a private registry for Docker images and simplifies the process of pushing, pulling, and managing container images. It also offers features like automated image updates within AWS container clusters.

What is the difference between fully managed and semi-managed EC2 instances in EKS?

Fully managed EC2 instances are managed entirely by AWS, where AWS handles the provisioning and management of the worker nodes. In semi-managed EC2 instances, users still need to manage the operating system, runtime, and scaling configurations. Node groups help simplify some management tasks, but auto-scaling and other configurations remain the user's responsibility.

How does Fargate work with Kubernetes (EKS) compared to ECS?

Fargate can be used with both ECS and EKS to eliminate the need to manage EC2 instances. In both services, Fargate automatically provisions resources for each container. For EKS, it allows for fully managed Kubernetes worker nodes, offering the same benefits of not having to manage infrastructure as it does with ECS.

When should you choose ECS over EKS for container orchestration on AWS?

ECS is best suited for less complex containerized applications that don't require the full feature set of Kubernetes. It offers deep integration with AWS services and is generally easier to set up for simpler tasks. EKS is ideal when you need portability, are already using Kubernetes, or require the advanced features of the Kubernetes ecosystem.

What are the cost differences between using EC2 and Fargate for container hosting?

With EC2, you pay for the entire server, even if you are not fully utilizing it. With Fargate, you only pay for the CPU, memory, and storage resources that your containers consume, making it a more cost-efficient option when scaling or handling dynamic workloads.

What are the main benefits of using AWS Fargate for containerized applications?

Fargate simplifies operations by automating the provisioning and scaling of resources needed to run containers, allowing developers to focus on their applications rather than managing infrastructure. It ensures that you only pay for the resources consumed, and it scales automatically to match container demand.

How does ECS handle container scheduling and resource management?

In ECS, the control plane manages container scheduling and ensures that containers are allocated to EC2 instances with sufficient resources. The ECS control plane automates the distribution of containers across available instances and can restart failed containers, reschedule them, or manage replicas as needed.

Outlines

00:00

🚀 Overview of AWS Container Services

This introduction gives a high-level overview of container services available on AWS. It explores various options for running containerized applications, such as ECS (Elastic Container Service), EKS (Elastic Kubernetes Service), and Fargate. The video aims to help developers choose the right service for their microservice architecture by comparing these services and explaining their features.

05:02

⚙️ Managing Containers on EC2 with ECS

This section dives into managing containerized applications with ECS on EC2 instances. It outlines how microservices can lead to an increasing number of containers, and the complexities of managing resources, scheduling, and monitoring containers across a distributed infrastructure. The need for container orchestration tools like Kubernetes, Docker Swarm, and AWS ECS is highlighted as a way to automate container management tasks.

10:03

🔄 Introduction to Fargate for Serverless Containers

This paragraph explains AWS Fargate, a serverless alternative to EC2 for running containers. Fargate automatically provisions the required resources (CPU, memory, etc.) for running a container without needing to manage virtual machines. This service scales effortlessly, and users only pay for the resources consumed by their containers, making it a flexible and cost-effective solution compared to traditional EC2-based deployment.

15:04

📊 Cost Efficiency and Scaling with Fargate

Fargate offers advantages in terms of cost efficiency and scalability. Unlike EC2, where users pay for entire servers, Fargate charges only for the exact resources consumed by each container. The automatic scaling of infrastructure ensures users only allocate the necessary resources for running their applications, reducing waste and operational overhead.

20:06

🔗 EKS: Using Kubernetes on AWS

EKS allows developers to manage Kubernetes clusters on AWS infrastructure. This section compares EKS to ECS, noting that EKS supports Kubernetes’ portability across platforms. While ECS is AWS-specific, EKS enables easier migration to other cloud providers or on-premise environments, making it a flexible choice for Kubernetes users looking to avoid vendor lock-in.

⚡ Differences Between EKS and ECS

While ECS integrates tightly with the AWS ecosystem, EKS supports Kubernetes’ broader toolset and allows easier migration. EKS gives access to Kubernetes’ vast array of tools, plugins, and third-party integrations, while ECS might be better for simpler applications. It also touches on the replication and backup features of Kubernetes master nodes managed by AWS.

🖥️ EKS Cluster Configuration and Worker Nodes

EKS provisions and manages Kubernetes master nodes across multiple availability zones. Users create worker nodes using EC2 instances, which are grouped in node groups to simplify management. The section discusses the semi-managed node group option, allowing users to automate some of the worker node setup while still managing aspects like auto-scaling manually.

🛠️ Options for Worker Node Management

This part explains the options for managing worker nodes in EKS: fully managed Fargate instances, semi-managed EC2 instances through node groups, or fully self-managed EC2 instances. It encourages the use of node groups to streamline operations and provides the flexibility to combine EC2 and Fargate within the same EKS cluster for greater control.

📦 Elastic Container Registry (ECR) Overview

ECR (Elastic Container Registry) is introduced as AWS’s solution for storing container images, functioning as an alternative to Docker Hub. Its tight integration with other AWS services, such as ECS and EKS, allows for seamless updates, image management, and deployment workflows within the AWS ecosystem.

🔄 Combining AWS Services for Container Management

This final part summarizes the three key container services on AWS: ECR for image storage, ECS for orchestration, and EKS for Kubernetes management. It emphasizes the ability to integrate these services into a CI/CD pipeline to streamline building, pushing, and deploying containers in an automated fashion.

Keywords

💡Elastic Container Service (ECS)

ECS is a container orchestration service provided by AWS that helps manage the lifecycle of containers. It allows users to automate tasks like starting, stopping, and scaling containers, making it easier to run containerized applications. In the video, ECS is described as a key service that allows users to manage containers running on EC2 instances, delegating container management tasks to AWS while still requiring users to manage the infrastructure.

💡Elastic Kubernetes Service (EKS)

EKS is AWS’s managed service for running Kubernetes, an open-source container orchestration platform. The video explains that EKS allows users who prefer Kubernetes to manage their container clusters on AWS infrastructure. A significant benefit of using EKS is the ability to migrate workloads more easily to other platforms, as Kubernetes is not exclusive to AWS.

💡Amazon EC2

Amazon EC2 refers to the virtual machines (instances) provided by AWS to run workloads, including containers. The video discusses how EC2 instances are used to host and run containers in both ECS and EKS setups, requiring users to manage aspects like operating systems and available resources for scheduling containers.

💡AWS Fargate

Fargate is a serverless option for running containers without having to provision or manage EC2 instances. The video emphasizes that Fargate simplifies container deployment by automatically provisioning the necessary server resources based on container requirements, allowing users to focus solely on managing their application without worrying about the underlying infrastructure.

💡Elastic Container Registry (ECR)

ECR is AWS's managed container image registry, which stores and retrieves Docker images. In the video, ECR is described as a repository that integrates with other AWS services like ECS and EKS, simplifying the deployment process by allowing seamless access to container images for AWS-based container services.

💡Container Orchestration

Container orchestration refers to the automated management of containerized applications, including deployment, scaling, networking, and lifecycle management. The video focuses on the role of ECS and EKS as container orchestrators that automate the running of containers across EC2 instances or through Fargate.

💡Microservices

Microservices are an architectural style where applications are composed of small, independent services, each running in its own container. The video highlights microservices as a typical use case for container services like ECS and EKS, where different containers are deployed for various parts of a microservices application, requiring orchestration and scaling.

💡Control Plane

The control plane is the part of a container orchestration system responsible for managing container deployments, scheduling, and scaling. The video explains that in both ECS and EKS, AWS provides a control plane that users interact with to manage their containerized applications, while AWS manages the control plane infrastructure.

💡Kubernetes

Kubernetes is a popular open-source platform for automating the deployment, scaling, and operation of containerized applications. The video contrasts AWS’s ECS service with Kubernetes-based EKS, explaining that Kubernetes is widely used across different platforms and offers flexibility and portability, which is beneficial for users who may want to migrate away from AWS.

💡Serverless

Serverless computing allows users to run applications without managing the underlying infrastructure. In the video, AWS Fargate is described as a serverless option for running containers, where users don't have to provision or manage EC2 instances, and AWS automatically allocates the necessary compute resources for containers.

Highlights

AWS offers multiple container services depending on application requirements, including ECS (Elastic Container Service), EKS (Elastic Kubernetes Service), and AWS Fargate.

ECS is a container orchestration tool that manages the entire container lifecycle, such as scheduling, restarting, and load balancing.

When using ECS with EC2 instances, users must still manage the underlying virtual machines, including provisioning, operating systems, and Docker runtime.

AWS Fargate provides a serverless option for running containers, automatically provisioning resources without the need to manage EC2 instances.

Fargate only charges for the resources that containers consume, offering better scalability and cost management compared to pre-provisioned EC2 instances.

EKS allows users to deploy Kubernetes clusters on AWS infrastructure, offering the flexibility of using Kubernetes, a more popular container orchestration tool.

One advantage of EKS over ECS is that Kubernetes is platform-agnostic, making it easier to migrate workloads across different platforms or on-premise infrastructure.

While EKS manages Kubernetes master nodes, users still need to manage worker nodes, though AWS offers semi-managed EC2 node groups to simplify this process.

Fargate can also be used with EKS to manage worker nodes, offering a fully managed infrastructure solution for Kubernetes clusters.

AWS Fargate eliminates the need to manually scale EC2 instances and provides on-demand scaling based on container needs.

Elastic Container Registry (ECR) integrates with ECS and EKS, serving as a private repository for container images, offering features like automatic image updates.

ECR simplifies container management by tightly integrating with other AWS services, allowing seamless interaction with the AWS ecosystem.

ECR supports versioning and tagging of container images, making it easier to manage different application versions and stages of development.

AWS offers extensive integration with services like CloudWatch for monitoring, Elastic Load Balancer for traffic distribution, and IAM for security when using containers.

EKS supports Kubernetes tools and plugins, such as Helm, enhancing the Kubernetes ecosystem with rich functionality for managing containerized applications.

Transcripts

in this video i will give you a high

level overview of all the different

container services you can use on aws

so if you want to run a containerized

application on aws you have multiple

options to choose from depending on your

application requirements

so we'll go through all of these options

one by one we will see what ecs elastic

container service is and what it's used

for

then we'll compare it and talk about eks

which is elastic kubernetes service

we will also see different ways of

running containers with ec2 or aws far

gate and finally we will see the ecr

service which stands for elastic

container registry

now think about a micro service

application scenario

if you're developing microservices

you would need containers for each and

containers scale pretty quickly

maybe you create replicas you have

different third-party

services and applications for your micro

service application this could be

messaging systems authentication

services etc so you end up with a bunch

of containers

that you need to deploy on some

environment in this case we're talking

about aws virtual service

so let's say we have created

10 containers for each our 10 micro

services plus we have five other

containers that our micro services use

which run different applications and

let's say we deploy all of those

on our ec2 instances

which have docker installed on them now

once you have deployed them how do you

manage them so you have an

infrastructure of all these virtual

servers that are running all your docker

containers how do you know how much

resources you still have remaining on

these machines how do you know where to

schedule the next container how do you

know by looking across your

infrastructure whether some of your

docker containers are not running

anymore whether servers ran out of

resources and

when you see that some containers have

died do you manually restart each

container if you have maybe five

replicas of

one application container you don't need

any more how do you get rid of all those

containers do you stop them and remove

them one by one and these are all

things

that you need to manage when you have

tens of containers maybe hundreds of

containers that you need to manage on

your infrastructure so obviously you

need some kind of automation some kind

of tool that can help you with all these

issues

and all these things that i just

mentioned are features of a container

orchestration tool so you probably

already know one of them which is the

most popular orchestration tool

kubernetes but of course there are

multiple orchestration tools out there

docker swarm is one of them which is

for less complex a bit smaller

containerized applications you also have

mesos apache mesos you also have

hashicorp

nomad and you also have an aws service

called amazon elastic container service

ecs so ecs is one of the container

services that aws offers and it is

essentially a container orchestration

service

so ecs being an orchestrator for

containers will manage the whole life

cycle of a container when you start the

container if it needs to get rescheduled

somewhere if it needs to get restarted

load balanced etc

so how does this service actually work

on aws if you wanted to create a cluster

a container cluster basically that is

managed by aws ecs service you would

create an ecs cluster

and that ecs cluster will basically

contain all the services

that are necessary for managing the

individual containers so ecs cluster

basically represents a control plane for

all your

virtual machines that are running

containers

and that control plane and the services

the managing services

in that control plane then can manage

these individual containers

and essentially managing the whole life

cycle of a container from being started

scheduled to being removed when you

create ecs cluster as i said you have

the control plane but the containers

need to run somewhere right so

containers need to run on actual

machines on virtual machines so where do

these virtual machines come from these

virtual machines

will be the ec2 instances we would

create an ec2 instance that will

basically host the containers the ec2

will not be isolated and managed by us

completely but ec2 instance will be

connected to this ecs cluster that we

created and on those ec2 instances you

will have the docker runtime or

container runtime generally

so that containers can run and also

you're going to have ecs agents

installed and this way the control plane

or ecs processes can communicate with

each individual ec2 instance and manage

them

so at the end it means that you have a

control plane that helps you

manage all your containers and automate

some of these

complex things that you don't want to do

manually and repeatedly so you have

delegated the management of your

containers to an aws service so you

don't have to worry about that however

you still have to

manage

the actual virtual machines

the ec2 instances

meaning you have to create the ec2

instances you have to join them to the

ecs cluster and when you schedule a new

container you have to make sure that you

have enough ec2 instances and resources

to schedule the next container you also

have to manage the server operating

system

and you also have docker runtime and the

ecs agent as i mentioned so all these

are basically part of

a virtual machine that you have to still

manage

on the upside of course you

have

full access to your infrastructure which

is an advantage if you need full

configuration access and power of the

infrastructure that's running your

containers

so now you have delegated the management

of your containerized application or

your containers basically to the aws

service which of course makes your

operations easier however you still have

the infrastructure to manage the virtual

servers

now what if you wanted to delegate

management of the infrastructure also to

aws

so you want the container lifecycle to

be managed by aws and you want the

hosting infrastructure to also be

managed by aws now there is an option

for that and it is called

aws far gate so far gate is basically an

alternative to ec2 instances so instead

of creating a provisioning ec2 instances

and connecting that to the ecs cluster

you don't need to provision any virtual

machines you use fargate interface and

fargate will take care of spinning up

the vm to run your container

so how does fargate work

fargate is a serverless way to launch

containers so you take a container that

you want to deploy on aws

and you tell aws here's my container

please run it and you hand it over to

fargate now at this point you don't have

any virtual machine that will run your

container you haven't provisioned

anything

or any server yet you just have the

control plane of ecs and you have the

far gate interface so you give your

container to fargate and you say please

schedule this fargate will then take

your container

it will analyze by looking at your

container how much resources your

container needs to run how much cpu how

much ram how much storage it needs to be

deployed and to run

and then fargate will itself

automatically provision a server

resources for that specific container

and then it will deploy and run that

container on the provisioned server

resources so this happens automatically

and every time you add or you hand over

a new container to deploy to fargate

fargate will do the same you go and

provision server resources to run that

specific container

so advantages are obviously you don't

need to worry about having enough ec2

instances and resources to schedule a

new container because you don't have to

provision anything beforehand and

because you don't have to provision the

infrastructure before you deploy

containers you always have

only the amount of infrastructure

resources needed to run your containers

and that means

you pay only for the resources that your

containers are actually consuming

and also

it really easily scales without fixed

set of ec2 resources defined beforehand

since every new container gets new

resources the pricing is based on how

long the container

runs

and how much cpu and memory was

requested for that container

so for comparison for ec2 you obviously

pay for the whole server even though you

might not be running any containers on

it or just a few maybe

and for fargate you only pay for the

resources that container is consuming

so now you have your

infrastructure managed by aws using the

fargate service and the containers that

are running that were scheduled through

fargate are now also managed by ecs so

you have multiple levels of your

infrastructure and the application on it

being managed by aws services now the

only thing that you have to worry about

and manage

is the actual application itself so

you develop the application you create

containers and that's it and then you

just deploy the containers on aws

infrastructure

which obviously is a great thing however

again if you need

more access to the underlying

infrastructure you need access to the

actual infrastructure

running your containers then you have

the flexibility and access with ec2

instances

and of course when you run your

containerized application on aws

infrastructure using the aws services

you have advantage of using

any other aws services from the aws

ecosystem right so

both ec2 and fargate and ecs and all

these services obviously fully integrate

with

the whole aws ecosystem right so this

could be cloud watch for monitoring

elastic load balancer for load balancing

iam for permissions and users vpc for

networking and so on

now this is how you can let aws manage

your containerized applications using

ecs

now what if

you want to use kubernetes as you know

kubernetes is the most popular container

orchestration tool currently so a lot of

projects a lot of companies actually use

kubernetes so can you still use aws

infrastructure

if you want to use kubernetes and how

can you use that aws actually has

another service which is for

managing kubernetes cluster on aws

infrastructure so alternative to ecs you

have a service called eks which stands

for elastic kubernetes service that lets

you manage kubernetes cluster

so the difference or advantage of using

eks is the first thing that i just

mentioned which is if you're using

kubernetes already and your project

wants to deploy their kubernetes cluster

on aws

infrastructure obviously you want to be

able to keep your kubernetes tool and

not use

a proprietary container orchestration

of aws you have an option of doing that

using eks

so that's the first obvious reason

another reason if you

do not necessarily think about using

kubernetes or you don't already use

kubernetes in your project making

decision between ecs and eks is

basically ecs is specific to aws right

so if you decide at some later point to

migrate to another platform you will not

be able to move that cluster to another

platform because it is really integrated

and based on aws with eks though because

it's managing the kubernetes cluster you

can easily migrate kubernetes because

it's not specific to aws right it's an

independent tool which you can use

anywhere so you can migrate or much

easily migrate kubernetes cluster on

another platform or maybe even on

premise right if you have your own

infrastructure in your company then

you can use the same configuration same

tools across multiple platforms so

that's a major advantage of using eks

versus ecs now i have to mention here

that even though kubernetes is an

independent tool if you're using it on

aws and you use a lot of additional

tools and services from the aws

ecosystem in your kubernetes cluster

then of course when you migrate your

kubernetes cluster you'll have to

replace those services with some other

tools because they will not be available

on another platform right because these

services are again specific to aws so

just know that it's not 100

easily migratable especially if you're

using aws specific services in your

cluster so that's maybe one thing to

consider another also important reason

for using eks versus ecs is

that if you use kubernetes which is

again a much more popular orchestration

tool than ecs you also have access to

all the kubernetes tools and plugins and

things are developing in the kubernetes

ecosystem like helm and some other tools

that integrate well with kubernetes now

on the side of ecs a more suitable

use case for ecs

is if you have less complex

containerized applications that maybe

don't need this full-fledged kubernetes

cluster to run in in this case you can

actually deploy it on ecs cluster and

also you don't pay for the ecs control

plane compared to eks cluster control

plane

but generally i think eks is much better

choice

for managing and orchestrating your

cluster on aws infrastructure now how

does eks work it's actually pretty

similar to how ecs works with eks you

create a cluster

which represents the control plane in

kubernetes world these are going to be

the masternodes so when you create an

eks service or eks cluster aws will

provision in the background kubernetes

masternodes

that already have all the kubernetes

master services installed on them so all

of that is managed and provisioned for

you you don't have to worry about

masternodes for your kubernetes cluster

also because it's managed by aws

these master nodes it will automatically

replicate the master nodes across

multiple availability zones so if you're

creating eks in region

eu west 3 that has three availability

zones then you will get automatic

replication of your masternodes on all

those azs and of course then you have

the storage which is the lcd part of the

master processes which stores

the whole configuration

the current state basically of

kubernetes cluster and that storage

needs to be replicated and needs to be

backed up because you shouldn't or you

can't lose the data otherwise you lose

all your cluster configuration and again

because it's a managed service aws will

also take care of storing the data

replicating it and

backing it up properly so basically

masternodes of kubernetes is not your

worry anymore so with eks you have the

master nodes control plane configured

now you need the worker nodes right you

need infrastructure that actually runs

your containers again same way as in the

ecs you will create ec2 instances the

so-called compute fleet of multiple

virtual servers and then connect them to

the eks

and now you have the masternodes and

worker node group connected and that

gives you a complete kubernetes cluster

and once that's done you can simply

connect to the cluster using cubectl

command and start deploying containers

inside that cluster in the example of

ecs we saw that these ec2 instances this

compute fleet each server had the ecs

agent installed this way the control

plane could communicate with the

individual nodes in this case we're in

the kubernetes world so worker nodes

will have kubernetes processes so this

way control plane or kubernetes

masternodes can communicate with worker

nodes just like they do on any platform

right it's not specific to aws in this

case so you have the worker nodes made

out of ec2 instances

that are connected to the eks

cluster

however in this case also you need to

manage the ec2 instances yourself you

have to manage the operating system and

the process is running on them in eks

cluster however you have a possibility

to choose a semi-managed ec2 instances

for your cluster so basically you can

group your worker nodes into node groups

and that node group can actually handle

some of the heavy lifting for you and

basically make it easier for you to

configure new worker nodes for your

cluster for example worker nodes or ec2

instances manage my node group will get

all the processes

necessary installed on them so you don't

have to worry about installing container

runtime kubernetes worker processes

etc for them to make it into worker

nodes so that means you have an

alternative between completely

self-managed ec2 instances and

semi-managed ec2 instances through node

groups

and when working with eks cluster

it is actually a good practice to use

node groups because they make a lot of

things simpler and you can also

create multiple node groups to group

your worker nodes in different logical

groups but as i said it is still

semi-managed you still have to take care

of some other stuff for example auto

scaling right you don't have the auto

scaling configuration out of the box you

still need to configure things in

kubernetes and on the aws side to make

auto scaling possible so you have to

take care of

creating new ec2 instances removing them

etc

however if that's also something you

want to delegate to aws if you don't

want to worry about that you can also

for eks cluster use fargate instead and

in that case you would have fully

managed worker nodes in addition to

fully managed control plane so these are

the three steps of

worker node

infrastructure management you have

available in aws

or you can even use both ec2 and fargate

at the same time for the same eks

cluster

so basically from the hosting

perspective of where your containers are

running having ec2 and fargate as

alternatives this part is pretty much

the same whether you use ecs or eks

and this basically gives you the

combination of the services that you

have as an option if you want to run a

containerized application

on aws

using a container orchestration tool to

manage them

now we just saw two of the services

on aws that are specifically for

containers and there is one more

container service on aws and that is

amazon ecr which stands for elastic

container registry so basically this is

just

a repository for container images

alternative to docker hub or

nexus docker repository where you can

store your docker images for example

advantage

of using elastic container registry is

of course

because it's part of the whole aws

ecosystem it integrates well with other

services so for example if you use eks

with ec2 instances for example

then it will be easier to connect it and

configure

your cluster

with

ecr to fetch the instances but also to

do some other stuff like automatically

get notified when a new version of the

image gets pushed to the registry and

then automatically download that into

your cluster and also some other

additional features and of course you

have all those abilities because these

are all aws services so they are tightly

integrated with each other

and ecr is pretty easy and

straightforward to use

you basically create your private

repositories for your different

application images or docker images and

you can start pushing different versions

or different tags of that image to those

registries and then of course use that

endpoint

to download the images from the cluster

so to summarize on aws you have three

container services

first for storing container images in

private container repository and the

other two for orchestrating or managing

your complex containerized application

on aws infrastructure

and in this part we're gonna look at ecr

and ek services and use them in our ci

cd pipeline

to build and push

images to ecr and deploy them to elastic

kubernetes service

[Music]