My journey to AWS Solution Architect Exam — Part 8- Amazon Elastic Compute Cloud EC2 (4/4)
In the context of preparing for the Solution Architect exam, it is crucial to delve into some advanced concepts related to Amazon EC2 that are not covered in the Cloud Practitioner exam.
Among these, Elastic IP (EIP) Solutions usage is significant, allowing for the maintenance of a static IP address for an EC2 instance, ensuring address persistence during instance restarts.
Additionally, understanding Placement Groups is essential for optimizing the performance of EC2 instances strategically placed within groups, favoring latency and connectivity.
Elastic Network Interfaces (ENIs) provide advanced flexibility in managing network traffic for EC2 instances.
Lastly, the EC2 Hibernate concept enables the suspension and resumption of instances while maintaining application states, reducing startup times, and enhancing resource efficiency. Mastery of these advanced aspects will enrich your preparation as a Solution Architect, providing a comprehensive understanding of EC2 functionalities.
Elastic IP (EIP) Solution
When you stop and then start an EC2 instance in AWS, its public IP address can change.This dynamic allocation is part of AWS’s design for EC2 instances to manage resources efficiently.
In some cases, applications or services may require a fixed, unchanging public IP address to function properly or for ease of management; to address the need for a fixed public IP, AWS provides Elastic IP (EIP) addresses.
An Elastic IP is a static, public IPv4 address that you can allocate and associate with your AWS account. As long as you retain the Elastic IP and it’s associated with an EC2 instance, it remains fixed.
You own an Elastic IP as long as you don’t release or disassociate it. This means that even if the associated EC2 instance is stopped or terminated, the EIP remains under your ownership. An EIP can be associated with one EC2 instance at a time. If you associate an EIP with a running instance, the instance’s public IP is replaced by the EIP.
If you disassociate the EIP, the EC2 instance will revert to a dynamic public IP upon the next restart.
Best practices and considerations for AWS architecture
EIPs can be a useful tool for achieving high availability in your architecture; by associating an EIP with a specific instance, you can rapidly remap the IP to another instance in the event of a failure, effectively masking the failure and minimizing downtime.
Limitations: AWS imposes a limit of 5 EIP addresses per account by default. However, it’s possible to request an increase in this limit by contacting AWS support.
Caution on EIP Usage: overreliance on Elastic IPs can sometimes indicate poor architectural decisions, as they might be used as a workaround for issues that could be better addressed through other means.
Alternative Approaches:
- Random Public IP with DNS: Instead of using Elastic IPs, one suggestion is to use a random public IP and register a DNS name to it. This can provide a level of abstraction and flexibility while avoiding the constraints of Elastic IPs.
- Load Balancer Usage: Another alternative mentioned is using a load balancer. Load balancers can distribute incoming traffic across multiple instances, providing high availability without the need for a public IP on individual instances.
In summary, while Elastic IPs offer benefits in certain scenarios, it’s important to be mindful of their usage and not to overly rely on them. Considering alternatives like DNS registration or leveraging load balancers can often lead to more robust and scalable architectures. The goal is to design systems that can gracefully handle failures and changes in infrastructure while maintaining availability and performance.
Placement Groups
Placement Groups in Amazon EC2 provide a way to influence the placement of instances within the AWS infrastructure, allowing you to control the strategy for how instances are distributed across the underlying hardware. P.G are useful when you have specific requirements or preferences for the physical placement of instances within an Availability Zone. When creating a p.g, you specify one of the following strategies.
Cluster
This strategy clusters instances into a low-latency group within a single Availability Zone. It aims to provide high network throughput and low-latency communication between instances. This is particularly beneficial for applications that require extremely fast and predictable network performance.
- Use Case: real-time analytics or applications with high-performance networking requirements.
Spread
The spread strategy spreads instances across underlying hardware to reduce the risk of correlated failures. Instances within a spread placement group are placed on distinct racks and power sources. This strategy is suitable for applications that require high availability.
- Use Case: applications that require high availability and need to minimize the risk of correlated failures.
Partition
The partition strategy spreads instances across different partitions, each relying on different sets of racks within an Availability Zone. This strategy scales well and is suitable for distributed applications that can benefit from increased fault tolerance and isolation. Examples include big data processing frameworks like Hadoop, distributed databases like Cassandra, and stream processing systems like Kafka.
- Use Case: distributed applications that benefit from increased fault tolerance and isolation, such as big data processing or distributed databases.
There are limits to the number of instances that can be added to a placement group based on the chosen strategy. For example, the spread strategy allows a maximum of 7 instances per group per Availability Zone.
In summary, placement groups offer a way to control the physical placement of EC2 instances within the AWS infrastructure. The choice of strategy depends on the specific requirements of your application, ranging from low-latency communication to high availability or fault tolerance for distributed workloads.
Elastic Network Interfaces
ENIs in AWS are logical components within a Virtual Private Cloud (VPC) that represent virtual network cards.
Attributes of ENIs:
- Primary Private IPv4: each ENI has a primary private IPv4 address associated with it.
- Secondary IPv4 Addresses: an ENI can have one or more secondary private IPv4 addresses.
- Elastic IP (IPv4): an ENI can be associated with one Elastic IP (IPv4) per private IPv4 address, providing a static public IP address.
- Public IPv4: ENIs can also have a Public IPv4 address associated with them for communication over the internet.
- Security Groups: ENIs can be associated with one or more security groups, which control inbound and outbound traffic.
- MAC Address: each ENI is assigned a MAC address, which is a unique identifier for the network interface.
ENIs can be created independently of EC2 instances and attached to instances on the fly. This ability to attach ENIs on the fly allows for dynamic network configurations, such as failover scenarios:
ENIs are often used in failover scenarios where an additional ENI is attached to an EC2 instance. In the event of a failure or maintenance, the secondary ENI can be detached and moved to another EC2 instance.
Each ENI is bound to a specific Availability Zone (AZ) within a VPC. It cannot be moved across AZs.
EC2 Hibernate
EC2 instances can be stopped or terminated, each with its implications, and EC2 Hibernate introduces another option for managing instances with some unique characteristics.
Stop an Instance:
- Effect: The instance is moved to a stopped state, preserving the data on its EBS volumes (root and additional volumes).
- Data Preservation: EBS volumes retain their data, and on the next start, the instance can resume its operation from where it left off.
- Boot Process: On the first start after stopping, the OS boots, and the EC2 User Data script (if provided) is executed.
Terminate an Instance:
- Effect: The instance is permanently removed, and any EBS volumes (if set to be deleted on termination) associated with it are lost.
- Data Loss: If the root volume is set up to be deleted on termination, the OS and all data on that root volume are lost.
- New Instance: If you need a replacement, you’ll have to launch a new instance.
EC2 Hibernate:
- Effect: The EC2 Hibernate feature allows you to stop an instance, but instead of fully powering it down, it hibernates the instance.
- Data Preservation: Similar to stopping an instance, the data on EBS volumes is preserved.
- State Preservation: The in-memory state of the instance, including the contents of RAM, is saved to the EBS root volume.
- Faster Resume: On the next start, the instance can resume more quickly as it doesn’t have to go through a full boot process.
This is particularly beneficial for instances with large amounts of in-memory data or applications with long startup times.
Boot Process with EC2 Hibernate:
- First Start: After the first hibernation, the OS boots, and the EC2 User Data script is executed.
- Following Hibernated Starts: The OS boots, but the EC2 User Data script is not rerun. Instead, the instance resumes from its hibernated state.
Using EC2 Hibernate is advantageous when you want to preserve the in-memory state of an instance across stops, reducing the startup time and maintaining the state of your applications. It’s particularly useful for instances hosting applications with long warm-up times or large caches.
Good to know
- Instance RAM Size — must be less than 150 GB.
- Instance Size — not supported for bare metal instances.
- AMI — Amazon Linux 2, Linux AMI, Ubuntu, RHEL, CentOS & Windows…
- Root Volume — must be EBS, encrypted, not instance store, and large
- Available for On-Demand, Reserved and Spot Instances
- An instance can NOT be hibernated more than 60 days
