What is EC2 placement group ?

Amazon EC2 placement groups are a logical grouping of instances in one of three configurations.

To understand placement group, we need to understand what is AWS Regions and Availability Zones.

AWS Regions and Availability Zones

Amazon has all of the hardware data center resources which support their services spread over geographically isolated areas called AWS regions. There are AWS regions in North America, Europe, Asia, and South America, with more regions being implemented soon. Each one of these regions is independent and isolated from the others. Resources are not replicated from one region to the other unless you specify that preference, which comes at an additional charge. This, of course, achieves fault tolerance and stability as, in the event that a whole region fails, it wouldn’t affect the services provided by another region.

Presently, every district is made out of different segregated Availability Zones (AZ). There are 66 Availability Zones inside 21 geographic districts. Every Availability Zone is a completely confined segment of the AWS provincial foundation. A solitary AZ might be housed in more than one server farm office with every individual server farm having repetitive force, systems administration, and availability, in addition to excess organization joins between every server farm. Every AZ is found away from some other AZ in a similar district by an extensive geological distance. These Availability Zones speak with one another over low-inertness, high-data transfer capacity, repetitive metro fiber joins. This is completely worked to kill the AZ as a solitary mark of disappointment and increment unwavering quality.

For example, with regards to significant traffic, like venture information bases — regardless of whether facilitated on Amazon EC2 occasions or on Amazon local data set administrations (like Amazon RDS) — a multi-AZ appropriation model gives you high accessibility on the off chance that a significant disappointment happens in a whole Availability Zone. Basic creation applications that can’t manage even a moderate measure of vacation profit by this model and need to think about this sort of broad disappointment as a genuine chance. The equivalent goes for the upper levels that this application might be made out of. In the event that the web administrations of an application are completely facilitated in one AZ, having the basic data sets in a HA multi-AZ design will not assistance much if the web level is facilitated in just a single AZ. From this high accessibility viewpoint, in a solitary AZ arrangement, if the AZ goes down everything goes down and the Recovery Time Objective goes way higher. This also the information misfortune that will occur in the middle.

Other important benefits from having multi-AZ deployments include:

• No I/O delays during backups, as backups are taken from the standby instance.
• No interruptions to I/O when applying patches or performing upgrades for maintenance purposes.
• Increase in responsiveness when load balancing is used. If one AZ is constrained, the instances in other zones can digest the traffic.

Of course, not all application use cases require a multi-AZ deployment. Temporary tests, dev deployments, or any use case that is not critical can get hosted in a single AZ and avoid the additional costs that come with running a multi-AZ. There are even high-intensive, extreme-low-latency use cases that fit the single-AZ model better.

AWS Placement Groups

Simply put, a Placement Group is a configuration option that AWS offers which lets you place a group of interdependent instances in a certain way across the underlying hardware on which those instances reside. The instances could be placed close together, spread through different racks, or spread through different Availability Zones. Let’s take a closer look at each one of the Placement Group types you can choose from and types of workloads that would best fit into each distribution option:

1. Cluster Placement Groups

The cluster placement group configuration allows you to place your group of interrelated instances close together in order to achieve the best throughput and low latency results possible. This option only lets you pack the instances together inside the same Availability Zone, either in the same VPC or between peered VPCs.

The benefit with bunch position bunches is that the correspondence between those occurrences isn’t restricted to single-stream traffic of 5 Gbps however to 10 Gbps single-stream (highlight point) traffic and a sum of 25 Gbps for total traffic. HPC (High Performance Computing) network-bound applications are the best use cases for this arrangement model. Computational designing, live occasion streaming, genomics sequencing, cosmology models, and earth-environment figure models are instances of utilization cases for this sort of collection in the cloud.

2. Partition Placement Groups

With partition placement groups, you can group your instances in separate logical partitions that form the placement group. The idea of this is to have each one of the logical partitions built on top of separate hardware racks in order to avoid common hardware failures. If one rack fails, it will only affect the instances residing on this logical partition. Each logical partition is composed of multiple instances. The partition placement group option allows you to place those partitions within a single AZ or in a multi-AZ setup within the same region.

So, what type of loads would best fit this model? Big data stores which need to be distributed and replicated are good examples. Big file systems such as HDFS or Cassandra are also great fits. Partition placement groups allow you to see which instances are placed into which partitions so you can make Hadoop or Cassandra topology aware and configure data replication properly. Any use case needing big data analysis, data reporting, or large-scale indexing would also be a good fit for partition placement groups.

3. Spread Placement Groups

With spread placement groups, each single instance runs on separate physical HW racks. So, if you deploy five instances and put them into this type of placement group, each one of those five instances will reside on a different rack with its own network access and power, either within a single AZ or in multi-AZ architecture.

The spread placement group setup may be similar to partition placement groups, but the main difference is that partition placement groups are made of several instances on each partition, while spread groups are just single individual instances spread through different racks or AZs.

This model is suggested for few basic occurrences for your business. You could possibly have a limited quantity of SQL data set occurrences running here or your web application level. This arrangement is an ideal use case for repetition since there is less necessity for the bulky computational force offered by segment and bunch situation gatherings.