Okay, so now let's talk about Amazon ECS,
and we're gonna get an overview
into all different aspects of it.
So the first thing I wanna talk to you about
is the EC2 Launch Type.
So ECS stands for Elastic Container Service.
And when you launch Docker Containers on AWS,
you are launching what's called an ECS Task on ECS Cluster.
And an ECS Cluster is made of things.
And with the EC2 Launch Type,
well these things are EC2 instances.
And in that case,
if you use an ECS Cluster with an EC2 Launch Type
you must provision and maintain the infrastructure yourself.
So that means that your Amazon ECS/ ECS Cluster
is going to be composed of multiple EC2 instances.
Now, these instances are a little bit special
because each of them must run the ECS Agent,
and then this Agent is going to register each,
EC2 Instance into the Amazon ECS service
and the specified ECS Cluster.
Now, once you have that in place
then when you start ECS tasks
then AWS is going to be starting or stopping the containers.
That means that whenever we have a new Docker container
it's going to be placed accordingly
on each EC2 Instance over time as you can see right here.
And you can start or stop the ECS task,
and it will be placed automatically.
So that's the EC2 Launch Type,
and Docker containers are placed on Amazon
EC2 instances that we provision in advance, okay?
Now, there's a second launch type called
the Fargate Launch Type.
And again, you launch Docker containers on AWS
but this time you do not provision the infrastructure
so there are no EC2 instances to manage it.
It's all serverless.
Well, because we don't manage servers
but there of course, there are servers behind.
So, in the Fargate type,
if we have an ECS Cluster
we just create task definition to define our ECS tasks.
And then AWS will run these ECS tasks for us
based on how many CPU and RAM we need.
So when we want to run a new Docker container,
simple as that, it's going to be run,
without us knowing where it's run
and without an EC2 Instance to be created
in the backend in our accounts for it to work.
So it's a little bit magic.
And then to scale, well you just need to increase
the number of tasks.
Simple, you don't need to manage any more
EC2 instances.
And the exam loves to go
and tell you to use Fargate because Fargate is serverless,
and it's way easier to manage than the EC2 Launch Type.
Okay, so we've seen the two launch types for Amazon ECS.
Now let's talk about the IAM Roles for ECS tasks.
So let's take an example of the EC2 Launch Type
in which we have an EC2 Instance
running the ECS Agent on Docker.
So in this case, we can create an EC2 Instance Profile
which is only valued of course
if you use EC2 Launch Type.
And it's going to be used by the ECS Agents only,
and then the ECS Agent will use the EC2 Instance Profile,
to make API calls to the ECS service
to restore the instance,
is going to make API calls to CloudWatch Logs
to send container logs.
It's going to use the API calls to ECR,
to pull Docker images from ECR
and also reference sensitive data
in Secrets Manager or the SSM Parameter Store.
And then our ECS tasks are going to get ECS Task Roles.
And so this is valued for both
EC2 Launch Type and Fargate.
And so here I have two tasks.
And we can create a specific role per task.
So my first Task A will have an EC2 Task A Role,
and the first Task B and second Task B
is going to have the Task B Role.
Well, why do we have different roles?
Because each role allows you to be linked
to different ECS services.
And so, for example, the EC2 Task A Role
allows you to have your Task A,
runs some API calls against Amazon S3.
Whereas Task B Role allows you to run,
again API calls against DynamoDB.
And you define the Task Role
in the task definition of your ECS service.
So remember this, the distinction between
EC2 Instance Profile Role and the ECS Task Role.
Next, Load Balancer Integrations.
So in example, I'm in the EC2 Launch Type
but it could be Fargate as well, of course,
and have multiple ECS Tasks running.
It's all in the ECS Cluster.
And we want to expose these tasks
as a HTP or HTTPS endpoint.
Therefore we can run an Application Load Balancer
in front of it and then our users will be going
to the ALB and in the back end to the ECS tasks directly.
So in that case
the ALB is supported and will support most use cases,
and that's a good choice.
The Network Load Balancer is recommended only
if you have very high throughput
or high performance use cases,
or as you learn later on in this course,
if you use it with AWS Private Link.
Or, if you want to use the
older generation Elastic Load Balancer you can,
but it's definitely not recommended
because you don't get any advanced features
and you cannot link your Elastic Load Balancer to Fargate.
Whereas if you're using the Application Load Balancer
then it works of course, with Fargate.
So what about data persistent on Amazon ECS?
For this you need Data Volume,
and they're different kinds but one of them
is noticeable and that's EFS.
So say you have an ECS cluster,
and in this case are represented both the EC2 Instance
as well as the Fargate Launch Type for my ECS Cluster.
And we want to mount a file system
onto the ECS task to share some data.
In that case, we use an Amazon EFS file system,
because it's a network file system is going to be compatible
with both EC2 and the Fargate launch types.
And it allows us to mount the file system directly
onto our ECS tasks.
Why? Well then tasks running in any
AZ linked to this Amazon EFS file system
will share the same data,
and therefore can communicate with another
via the file system if they wanted to.
So the ultimate combo,
is to use Fargate to launch ECS task
in the serverless fashion
and Amazon EFS for file system persistent,
because EFS again is also serverless,
we don't manage any servers, it's pay as you go.
It's just provisioned in advance and you're good to go.
So the use cases of using EFS with ECS
is to do persistent multi-AZ shared storage
for your containers.