All language subtitles for 10 - SAA EC2 Placement Groups English

So now let's talk about Placement Groups.

Placement groups are a little bit more advanced

and we wanna use them once we want to have control

over how our EC2 instances are going to be placed

within the AWS infrastructure.

So that strategy can be defined using

these placement groups.

So we don't get direct interaction with the hardware of AWS,

but we let AWS know how we would like our EC2 instance

to be placed compared to one another.

So when you create a placement group,

you have three strategies available for you.

You have the cluster placement group

in which your instances will be grouped together

in a low-latency hardware setup

within a single availability zone.

This is going to give you high performance, but high risk.

We'll see this in details in a second.

Spread, means that your instances

are going to be spread across different hardware.

And that is a restriction on this,

that means you can only have seven EC2 instance

per placement group that's spread per AZ.

So you would use a spread placement group

when you have critical applications.

Finally, the last one is a new kind of placement group

that is really helpful, it's called partition.

It's similar to the spread,

meaning that you want to spread your instances

but here they're spread across many different partitions.

And these partitions rely on different

sets of racks of hardware within an AZ.

What does that mean is that, they're still spread,

but they're not isolated one from another failure,

but a partition should be isolated

from another partition of failure.

The idea with this, is that you can scale

through hundreds of EC2 instances per group

and that allows you to run applications

such as Hadoop, Cassandra, or Kafka.

Now let's have a look into

each of these placement groups in details.

For cluster, that means that's all our EC2 instances

are on the same rack, which means same hardware

and it's in the same availability zone.

So as you can see, all these instances

are on the same hardware.

And so what would we do this?

Well basically, we would place them on the same rack

because we want to have a cluster,

we want to have super low latency,

and want to have maybe a 10 gigabytes speed network.

So that means that we have an amazing network, right?

But as a drawback of this great network that we get,

we get the con that if the rack fails,

if there's a failure on the hardware

then all the EC2 instances will fail at the same time.

So we have increased our risk

to have a failure that's gonna be propagated

across our entire stack.

So when would we even use this?

What's the benefit you're getting this increased risk.

Well, we get great network.

And so for this, that means that we can have

a big data job that will need to complete very fast.

Or maybe we have a requirement

to have an application that needs extremely low latency

and high network throughputs,

and we're willing to take on the risk to have this failure.

And so this is something you have to realize,

it's not for every kind of application

but if your application needs

super high bandwidth and low latency,

placement groups is kind of a nice

the cluster placement group

is kind of a nice way of doing it.

Now spread is the complete opposites.

In spread we want to minimize the failure risk.

And so in this case,

when we asked for a spread placement group,

all the EC2 instances are going to be located

on different hardware.

So as you can see here,

we have three AZ and we have six EC2

and each EC2 instance is on a different hardware.

So what does that mean?

Well what we get, is that's we can span across multiple AZ

and there is a reduced risk of simultaneous failure.

Why? Well because if my hardware one fails,

I'm pretty sure my hardware two will not fail.

And so we've separated the risk of my two instances

in the Us-east-1a, to fail at the same time.

And so that's the benefit from it.

The con is that from this configuration,

we're limited to seven instances per AZ,

per placement group.

So there's a limit to how big your placement group can be.

And so you need to have a application

that's gonna be of good size, but not too big.

The use case would be an application

that needs to maximize high availability

and reduce the risk.

And in general, for critical applications

where your instance failures

must be isolated from one another.

Remember here, we have a limitation of seven instances

per AZ per placement group.

Now for the partition placement group,

we can have instances spread across partitions

in multiple availability zones.

So we can have up to seven partitions per AZ.

So in this example, we have partition one

and partition two in us-east-1a,

and partitioner three in us-east-1b.

And on each partition, you could have many EC2 instances.

So in the first one, I have four

and the second one I have four

and the third one I have four as well.

So why do we use a partition placement group?

Well, each partition represents a rack in AWS.

And so by having many partitions

you're making sure that your instances

are distributed across many hardware racks,

and so therefore,

they're safe from a rack failure from one another.

So you can have up to seven partitions per AZ

and these partitions can span

across multiple availability zones in the same region.

You can get up to hundreds of EC2 instances with a setup.

So this is the difference

versus the spread type of placement group.

And as I said, the instances and the partition

do not share the same hardware physical rack

with the instances in the other partitions,

and therefore, each partition is isolated from failure.

So that means that's, yes if one goes down,

if partition goes down, the partition number two,

then partition number one should be fine.

And to know which partition these EC2 instances are on,

there is an option to access this information

with using the metadata service.

So when would you use a partition placement group?

Well, when you have an application

that it can be partition aware to distribute the data

and your servers across partitions.

And usually, the use cases are going to be

big data applications, which are partition aware,

such using HDFS, Hbase, Cassandra and Apache Kafka.