Now let's talk
about a few solution architectures
you can encounter with Amazon ECS.
So the first one are ECS task invoked by EventBridge.
So for example,
say we have an Amazon ECS cluster it's backed by fargates
and with the S3 buckets.
Our users are going to upload objects into S3 buckets.
And these S3 buckets can be for example
integrated with Amazon EventBridge
to send all the events to it.
And Amazon EventBridge can have a rule to run
ECS tasks on the go.
Now ECS tasks are going to be created.
They will have an ECS task role associated with them.
And from the task itself,
what it can do is that it can get the objects, process it
and then send the results into Amazon DynamoDB.
And that is thanks to the fact
that we have an ECS task role associated with it.
And so effectively here, what we've done is
that we've created a serverless architecture
to process images or to process objects
from your S3 buckets using a Docker container.
And that is using Amazon EventBridge,
ECS find the fargate mode,
as well as an ECS task role to talk to Amazon S3
and Amazon DynamoDB.
Another architecture using again EventBridge
is to use an EventBridge schedule.
So we have an Amazon ECS cluster backed by fargates
and Amazon EventBridge.
And we schedule a rule to be triggered every one hour.
Now this rule is going to run ECS tasks for us in fargates.
And so that means that everyone hour
a new task will be created in our fargate cluster.
And the tasking can do whatever we want.
For example, we can create an ECS task role
with access to Amazon S3
and therefore our task, our Docker container,
our program can for example, do every one hour
some batch processing against some files in Amazon S3.
And again, all of that architecture is fully serverless.
Our last example is using ECS-SQS Queue.
So we could have a service on ECS with two ECS tasks
and message are being sent into an SQS Queue
and the service itself is polling
for messages from the SQS Queue and processing them.
We can enable ECS service auto scaling
on top of this service.
That means that for example,
the more messages we have in our SQS Queue,
the more tasks we're going to have into our ECS service,
thanks auto scaling.
Okay, that was it for some architectures on ECS.
I hope that makes sense.
And I will see you in the next lecture.