Amazon EC2 – Associate

1. Private versus Public IP

Networking uses two kinds of address. IPv4 looks like 1.160.10.240; IPv6 looks like 3ffe:1900:4545:3:200:f8ff:fe21:67cf. The course sticks to IPv4 throughout, because it is still the most common format online — IPv6 is newer and mainly solves problems for the Internet of Things. IPv4 is written as four numbers in the range [0-255].[0-255].[0-255].[0-255], which allows roughly 3.7 billion different addresses in the public space.

The fundamental differences

Public IP:

• The machine can be identified on the internet.
• The address must be unique across the whole web — no two machines can share a public IP.
• It can be geo-located easily.

Private IP:

• The machine can be identified only inside a private network.
• The address must be unique within that private network.
• Two different private networks can use the same addresses. Company A and Company B can both run 192.168.0.1/22 without conflict, because each sits behind its own internet gateway with its own public address.
• Machines in a private network reach the internet through a NAT plus an internet gateway, acting as a proxy.
• Only a specified range of IPs may be used as private IPs.

How this shows up on EC2

By default, an EC2 machine comes with both: a private IP for the internal AWS network, and a public IP for the internet.

That has a direct practical consequence for SSH: you cannot use the private IP, because your laptop is not on the same network — you must connect over the public IP. And the awkward part: if the instance is stopped and then started, the public IP can change.

Exam tip

The private IP stays with the instance; the public IP is the one that can be reassigned across a stop/start. When a question says “after a restart the clients could no longer reach the server by address”, that is the public IP changing, and the fix is either an Elastic IP, a DNS name, or a load balancer.

2. Elastic IPs

If you genuinely need a fixed public IP for an instance, that is what an Elastic IP provides. An Elastic IP is a public IPv4 address you own for as long as you do not delete it, and you can attach it to one instance at a time.

Its useful property is failover: the address can be pointed at a different instance in your account within moments, which hides a failed instance or a broken piece of software from whoever is calling it.

The constraints and the advice:

• You can have only 5 Elastic IPs per account — you can ask AWS to raise the limit.
• Overall, try to avoid Elastic IPs. They often reflect poor architectural decisions.
• Prefer instead: use a random public IP and register a DNS name to it, or use a Load Balancer and no public IP at all.

Exam tip

When an answer option offers an Elastic IP for a scalable, highly available design, be suspicious. The deck’s own recommendation is DNS or a load balancer. Elastic IPs are the right answer mainly when the scenario insists on a fixed, remappable address — a legacy client with a hard-coded IP, for example.

3. Placement Groups

Sometimes you want control over where AWS physically places your instances. You express that with a placement group, choosing one of three strategies when you create it.

Cluster

Clusters instances into a low-latency group in a single Availability Zone.

• Pros: excellent network — 10 Gbps bandwidth between instances when Enhanced Networking is enabled, which is recommended.
• Cons: if the AZ fails, all instances fail at the same time.
• Use cases: a big data job that has to finish fast; an application needing extremely low latency and high network throughput.

Spread

Spreads instances across distinct underlying hardware.

• Pros: can span multiple Availability Zones; reduced risk of simultaneous failure; instances sit on different physical hardware.
• Cons: limited to 7 instances per AZ per placement group.
• Use cases: applications that need to maximise high availability; critical applications where each instance must be isolated from the failure of the others.

Partition

Spreads instances across many partitions, each relying on a different set of racks within an AZ.

• Up to 7 partitions per AZ, and the group can span multiple AZs in the same Region.
• Scales to hundreds of EC2 instances per group.
• Instances in one partition do not share racks with instances in another, so a partition failure can affect many instances but will not affect the other partitions.
• EC2 instances can read their partition information from instance metadata.
• Use cases: HDFS, HBase, Cassandra, Kafka.

Comparing the three

Strategy	Placement	Scale	Trade-off
Cluster	Packed together in one AZ	Small	Best network performance, worst blast radius
Spread	Distinct hardware, can span AZs	Max 7 instances per AZ per group	Best isolation, tightest instance limit
Partition	Distinct racks grouped into partitions	Up to 7 partitions per AZ, hundreds of instances	Isolation at scale, for rack-aware distributed systems

Exam tip

Match the keyword to the strategy: “lowest latency between nodes / fastest possible HPC job” means Cluster; “each instance must be isolated from the others’ failure”, with a small instance count, means Spread; and a named big-data system such as Cassandra, Kafka or HDFS with hundreds of nodes means Partition. The number 7 appears in two places with different meanings — 7 instances per AZ for Spread, 7 partitions per AZ for Partition.

4. Elastic Network Interfaces (ENI)

An ENI is a logical component in a VPC that represents a virtual network card. An instance has a primary ENI (eth0) and can have secondary ones (eth1, and so on).

An ENI can carry:

• A primary private IPv4, plus one or more secondary IPv4 addresses.
• One Elastic IP (IPv4) per private IPv4.
• One public IPv4.
• One or more security groups.
• A MAC address.

Two properties matter architecturally: you can create an ENI independently and attach it to an instance on the fly, moving it between instances for failover; and an ENI is bound to a specific Availability Zone, so it cannot be moved outside that AZ.

Real-world example

An appliance keeps its identity — private IP, Elastic IP, security groups, MAC address — on a secondary ENI. If the instance dies, you detach that ENI and attach it to a standby instance in the same AZ. The replacement machine comes up carrying the same addresses, so clients reach it without any reconfiguration.

5. EC2 Hibernate

Start from what you already know about stopping and terminating:

• Stop — the data on the EBS disk is kept intact for the next start.
• Terminate — any EBS volume (including the root) that is set to be destroyed is lost.

And what happens on start:

• First start: the OS boots and the EC2 User Data script runs.
• Following starts: the OS just boots.
• Then your application starts, caches warm up — and that can take a long time.

What Hibernate solves

EC2 Hibernate attacks exactly that warm-up cost:

• The in-memory (RAM) state is preserved.
• The instance boot is much faster, because the OS is not stopped and restarted.
• Internally, the contents of memory are dumped into a file on the root EBS volume — which is why that root EBS volume has to be encrypted.

The instance lifecycle gains a path: Running goes to Stopping and then Stopped via Hibernate instead of Shutdown, and Start brings it back to Running with its memory intact.

Use cases:

• Long-running processing.
• Saving the RAM state.
• Services that take time to initialise.

Things to know

The constraints are specific enough to be exam material on their own:

• Supported instance families: C3, C4, C5, I3, M3, M4, R3, R4, T2, T3, and others.
• 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 and others.
• Root volume: must be EBS, encrypted, not instance store, and large enough to hold the RAM image.
• Available for On-Demand, Reserved and Spot instances.
• An instance cannot be hibernated for more than 60 days.

Exam tip

The three numbers and conditions that get tested: RAM under 150 GB, root volume EBS and encrypted, and a hibernation period of at most 60 days. If a scenario has an unencrypted root volume or an instance store root, hibernation is simply unavailable.

Quick recap

Item	What to remember for the exam
IPv4	[0-255].[0-255].[0-255].[0-255], ~3.7 billion public addresses; the course uses IPv4 only
Public IP	Identifies the machine on the internet, unique across the whole web, geo-locatable
Private IP	Only inside a private network, unique there, reusable by other networks; reaches the internet through NAT + internet gateway
EC2 addressing	An instance gets both a private and a public IP; SSH uses the public one; the public IP can change across stop/start
Elastic IP	Fixed public IPv4 you own until you delete it, one instance at a time, remappable for failover; limit 5 per account; prefer DNS or a load balancer
Cluster	One AZ, low latency, 10 Gbps with Enhanced Networking; the whole group dies with the AZ
Spread	Distinct hardware, can span AZs, max 7 instances per AZ per group, maximum isolation
Partition	Up to 7 partitions per AZ, can span AZs in a Region, hundreds of instances, partitions do not share racks, metadata exposes the partition; HDFS, HBase, Cassandra, Kafka
ENI	Virtual network card in a VPC: primary and secondary private IPv4, an Elastic IP per private IPv4, one public IPv4, security groups, a MAC address; attachable on the fly; bound to one AZ
Stop vs Terminate	Stop keeps EBS data; Terminate destroys volumes marked for deletion
Hibernate	Preserves RAM state to an encrypted root EBS volume, boots faster, skips the OS restart
Hibernate limits	RAM < 150 GB, no bare metal, root must be encrypted EBS, On-Demand / Reserved / Spot, max 60 days hibernated