EC2 Placement Groups – AWS

Rashmi Bhardwaj | Blog,Cloud & Virtualization
Advertisements

EC2 Placement Groups

EC2 instance placement groups are a group of independent instances that are placed on the underlying hardware as defined by the user to meet the need of customer workloads. When EC2 instances are created on AWS, by default it is placed spread across the underlying hardware to minimize the correlated failures but using placement groups you can tweak this behavior and place EC2 instances as per workload needs.

Related – Elastic Compute Cloud in AWS 

Advertisements

Few things to consider while creating Placement Groups:

  • Name of each placement group must be unique within your AWS account for the Region.
  • You can’t merge placement groups.
  • An instance can be launched in one placement group at a time; it cannot span multiple placement groups.
  • There are three types of Placement Group Options that are available:
  • Cluster Placement Group
  • Partitioned Placement Group
  • Spread Placement Group

 

Below, we will further explore the three types of Placement Group options –

Cluster Placement Group:

Cluster placement group is a logical grouping of the instances within a single Availability Zone.

  • It can also span peered VPCs within a single AWS region.
  • Cluster Placement Group can’t span multiple Availability Zones.
  • This grouping is supported on the selected instance types only.
  • AWS recommends to bring up all the instances within this placement group at single launch and have same instance types within a single placement group.
  • To add a new instance into the placement group :
    • Create an AMI from the existing instance, and then launch a new instance from the AMI into a placement group.
  • In order to get lowest latency within a placement group instances, choose the EC2 instance type that supports enhanced networking capability.
  • Network traffic to the internet and over an AWS Direct Connect connection to on-premises resources is limited to 5 Gbps.

Use Case:

Recommended for the application that requires high network throughput, low network latency or both

Partitioned Placement Groups:

Using this you can group EC2 instances into logically separated units called partitions. Each partition is physically distinct from the other partition i.e. the group of EC2 instances in Partition 1 won’t share the physical resources with the group of EC2 instances in Partition 2. By physical resources we mean different racks, different set of network and different power sources. This placement group hence reduces the likelihood of correlated hardware failures on your applications.

  • By default Amazon distributes the EC2 instances within a partition placement group evenly, but user can define in which partition within the Placement group he wants the instance to be in to have more control over instance placement.
  • Partitions can be in multiple AZs within a single AWS region.
  • Maximum of seven partitions can be there within a given Partition Placement Group.
  • You can see which instances are in which partitions.
  • Partition placement groups are not supported for Dedicated Hosts.

Use Case:

Used to deploy large distributed and replicated workloads, such as HDFS, HBase, and Cassandra, across distinct racks

Spread Placement Group:

In this group each instance has its distinct underlying hardware i.e. rack, network, power sources. Launching instances in a spread placement group reduces the risk of simultaneous failures that might occur when instances share the same racks.

  • This placement group is suitable if you have a mix of instance types in a group.
  • You can span multiple AZs within same region using this placement group.
  • Maximum of seven running EC2 instances are supported per AZ. For example within a region you could have two AZ and each AZ can have seven instances hence total of 14 Instances can be run.
  • Spread placement groups are not supported for Dedicated Instances or Dedicated Hosts.

Use Case:

Recommended for applications that have a small number of critical instances that should be kept separate from each other.

 

ABOUT THE AUTHOR


Leave a Comment

Your email address will not be published. Required fields are marked *

Shopping Cart