Difference between Public IP and Elastic IP Address

Public IP and Elastic IP Address

a) Public IP address 

Instance with Public IP address will get an external DNS name (example, ec2-506-0-198-88.compute-1.amazonaws.com)  name. External DNS name will be able to resolve outside the network and to the private IPv4 address of the instance from within the network of the instance. The public IP address is mapped to the primary private IP address through network address translation (NAT).

Public IP address can't be manually associated or disassociated for your instance. AWS releases or assigns the public IP address  in following cases

1) When instance is  stopped or terminated. Stopped instance receives a new public IP

2) When you associate an Elastic IP address with your instance Public IP address for your instance will be released.

3) When you associate an Elastic IP address with the primary network interface (eth0) of your instance in a VPC.

4) When you disassociate the Elastic IP address from your instance, it receives a new public IP address.

Reboot of EC2 WON'T change the public IP address of your instance changes

If you require a persistent public IP address that can be associated to and from instances as use an Elastic IP address.

b) Elastic IP address 

An Elastic IP address is a static IPv4 address designed for dynamic cloud computing. Elastic IP address will be associated with your AWS account.

Elastic IP address doesn’t incur charges as long as the below conditions are met

1)  The instance associated with the Elastic IP address is running.

If above conditions are not met then you will be charged for the Elastic IP Address.

If you’ve stopped or terminated an EC2 instance with an associated Elastic IP address and you don’t need that Elastic IP address any more, consider disassociating or releasing the Elastic IP address.

Note: Once if the Elastic IP address is released, you can’t get the same Elastic IP address again, you have to get a different Elastic IP address.

EC2 Tenancy Models

Here are different types of tenancy model available which we need to select while creating the EC2. Below are the list of models with explanation

a) Shared Tenancy 

The physical Hardware where your EC2 is hosted will be shared with other customers also. Pricing is less as the Hardware is shared with other customer's. When the instance is Stopped and Started the underline physical server will change but  Reboot will not change the underline hardware.

b) Dedicated Instances 

The physical hardware is completely dedicated for you and won't be shared with other customer and only your EC2 instances will be hosted there. In Simple terms, Hardware dedicated for your account. But during start and stop of the server the underline Hardware will change and we may get new dedicated hardware. And your shared instances (same account) wont be launched in the underlying hardware only dedicated instances of particular type will be launched in the same hardware.

For example: Requesting a m4.large dedicated instance could end with your instance on a server exactly the size of an m4.large.

In addition to instance charge of per hour rate an additional of 2$ will be charged per hour per region. This 2$ will be same if it is 10 instance or 1 instance. As it will be charged per hour per region

c) Dedicated Hosts 

Only difference between Dedicated instance and Dedicated host is even after stop & start underlying hardware will not change. This method is useful when we are going for a hardware based license model. Billing will be high as we are using full host.

As we get the complete hosts, irrespective of utilization we will pay the complete charge as the host is dedicated for You. This is bit costlier than others.  

Number of instances per dedicated hosts calculation is available in AWS help page. For example if we select m4 as our dedicated hosts then we can have 22 large m4 or 11 xlarge

Linux AMI Virtualization types

Linux Amazon Machine Images use one of two types of virtualization:

a) Paravirtual (PV)

b) Hardware virtual machine (HVM).

The main difference between PV and HVM AMIs is the way in which they boot and whether they can take advantage of special hardware extensions (CPU, network, and storage) for better performance.

For the best performance, we recommend that you use current generation instance types and HVM AMIs when you launch your instances.

HVM AMIs

HVM AMIs are presented with a fully virtualized set of hardware and boot by executing the master boot record of the root block device of your image. This virtualization type provides the ability to run an operating system directly on top of a virtual machine without any modification, as if it were run on the bare-metal hardware. 

HVM guests can take advantage of hardware extensions that provide fast access to the underlying hardware on the host system. HVM AMIs can take advantage of enhanced networking and GPU processing. (In order to pass through instructions to specialized network and GPU devices, the OS needs to be able to have access to the native hardware platform; HVM virtualization provides this access)

All current generation instance types support HVM AMIs. The CC2, CR1, HI1, and HS1 previous generation instance types support HVM AMIs.

To find an HVM AMI, verify that the virtualization type of the AMI is set to HVM, using the console or the describe-images command.

PV AMIs

PV AMIs boot with a special boot loader called PV-GRUB, which starts the boot cycle and then chain loads the kernel specified in the menu.lst (menu.lst -> ./grub.conf) file on your image. Paravirtual hosts cannot take advantage of special hardware extensions such as enhanced networking or GPU processing. 

The C3 and M3 current generation instance types support PV AMIs. The C1, HI1, HS1, M1, M2, and T1 previous generation instance types support PV AMIs.

To find a PV AMI, verify that the virtualization type of the AMI is set to paravirtual, using the console or the describe-images command.

PV on HVM

Paravirtual guests traditionally performed better with storage and network operations than HVM guests because they could leverage special drivers for I/O that avoided the overhead of emulating network and disk hardware, whereas HVM guests had to translate these instructions to emulated hardware. 

Now these PV drivers are available for HVM guests, so operating systems that cannot be ported to run in a paravirtualized environment (such as Windows) can still see performance advantages in storage and network I/O by using them. With these PV on HVM drivers, HVM guests can get the same, or better, performance than paravirtual guests.

AMI Launch Permissions

Public - Launch permission to all

Explicit - Launch permission to special AWS accounts

Implicit - Only owner can launch

How are you charged AMI Launch Permissions

With Instance store AMI every time you customize  and create new one all the parts are stored in Amazon S3 for each AMI. So storage footprint for each customized AMI is full size of AMI.

For EBS backed AMI each time you customize and create new one only the changes are stored  for subsequent AMI. resulting in low storage.

We can convert instance store AMI to EBS backed AMI but lot of steps need to be followed.

Copying of AMI is not chargeable.

launch pemrission, user defined tags or s3 permission or not copied from source AMI  o new AMI.

Making AMI public will take some time and available only to that region.

You can create boot strap script to  customize your AMI  to install software on startup

Accessing internet from Private Subnet

To Access internet from Private subnet. We have two methods

a)            By using NAT Gateway

b)          By Using NAT Instance

By Using NAT Instance

1) Launch the NAT Instance using ( AMI to be used : Amazon NAT AMI ) in public Subnet

2) Launch the instance in private subnet

3) Assign EIP to the NAT Instance

4) Disable Source/Destination Check for the instance (Select Instance -> Actions -> Networking -> Uncheck Source/Destination check )

5) Update the IPTables of NAT table like below (i.e) POSTROUTING to MASQUERADE

# iptables -t nat -A POSTROUTING -o eth0 -s <privae subnet>  -j MASQUERADE

Modify the Security Group of NAT instance inbound rule to all or the port from PVT subnet

Modify the Route table of the PVT subnet for 0.0.0.0/0 to point to NAT Instance

cat <<EOF | sudo tee /etc/sysctl.d/custom_nat_tuning.conf

# for large instance types, allow keeping track of more

# connections (requires enough RAM)

net.ipv4.netfilter.ip_conntrack_max=262144

EOF

sudo sysctl -p /etc/sysctl.d/custom_nat_tuning.con

/usr/local/sbin/configure-pat.sh

By Using NAT Gateway

1) Launch the NAT Gateway in public Subnet. 

2) Launch the instance in private subnet

3) Assign EIP to the NAT Gateway

4) Modify the Route table of the PVT subnet for 0.0.0.0/0 to point to NAT Gateway

Displayed error	Reason	Remedial steps
Subnet has insufficient free addresses to create this NAT gateway	The subnet you specified does not have any free private IP addresses. The NAT gateway requires a network interface with a private IP address allocated from the subnet's range.	You can check how many IP addresses are available in your subnet by going to the Subnets page in the Amazon VPC console, and viewing the Available IPs field in the details pane for your subnet. To create free IP addresses in your subnet, you can delete unused network interfaces, or terminate instances that you do not require.
Network vpc-xxxxxxxx has no Internet gateway attached	A NAT gateway must be created in a VPC with an Internet gateway.	Create and attach an Internet gateway to your VPC. For more information, see Attaching an Internet Gateway.
Elastic IP address eipalloc-xxxxxxxxcould not be associated with this NAT gateway	The Elastic IP address that you specified does not exist or could not be found.	Check the allocation ID of the Elastic IP address to ensure that you entered it correctly. Ensure that you have specified an Elastic IP address that's in the same region in which you're creating the NAT gateway.
Elastic IP address eipalloc-xxxxxxxxis already associated	The Elastic IP address that you specified is already associated with another resource, and cannot be associated with the NAT gateway.	You can check which resource is associated with the Elastic IP address by going to the Elastic IPs page in the Amazon VPC console, and viewing the values specified for the instance ID or network interface ID. If you do not require the Elastic IP address for that resource, you can disassociate it. Alternatively, allocate a new Elastic IP address to your account. For more information, see Working with Elastic IP Addresses.
Network interface eni-xxxxxxxx, created and used internally by this NAT gateway is in an invalid state. Please try again.	There was a problem creating or using the network interface for the NAT gateway.	You cannot fix this error. Try creating a NAT gateway again.

Comparison of NAT Instances and NAT Gateways

The following is a high-level summary of the differences between NAT instances and NAT gateways.

Attribute	NAT gateway	NAT instance
Availability	Highly available. NAT gateways in each Availability Zone are implemented with redundancy. Create a NAT gateway in each Availability Zone to ensure zone-independent architecture.	Use a script to manage failover between instances.
Bandwidth	Supports bursts of up to 10Gbps.	Depends on the bandwidth of the instance type.
Maintenance	Managed by AWS.You do not need to perform any maintenance.	Managed by you, for example, by installing software updates or operating system patches on the instance.
Performance	Software is optimized for handling NAT traffic.	A generic Amazon Linux AMI that's configured to perform NAT.
Cost	Charged depending on the number of NAT gateways you use, duration of usage, and amount of data that you send through the NAT gateways.	Charged depending on the number of NAT instances that you use, duration of usage, and instance type and size.
Type and size	Uniform offering; you don’t need to decide on the type or size.	Choose a suitable instance type and size, according to your predicted workload.
Public IP addresses	Choose the Elastic IP address to associate with a NAT gateway at creation.	Use an Elastic IP address or a public IP address with a NAT instance. You can change the public IP address at any time by associating a new Elastic IP address with the instance.
Private IP addresses	Automatically selected from the subnet's IP address range when you create the gateway.	Assign a specific private IP address from the subnet's IP address range when you launch the instance.
Security groups	Cannot be associated with a NAT gateway. You can associate security groups with your resources behind the NAT gateway to control inbound and outbound traffic.	Associate with your NAT instance and the resources behind your NAT instance to control inbound and outbound traffic.
Network ACLs	Use a network ACL to control the traffic to and from the subnet in which your NAT gateway resides.	Use a network ACL to control the traffic to and from the subnet in which your NAT instance resides.
Flow logs	Use flow logs to capture the traffic.	Use flow logs to capture the traffic.
Port forwarding	Not supported.	Manually customize the configuration to support port forwarding.
Bastion servers	Not supported.	Use as a bastion server.
Traffic metrics	Not supported.	View CloudWatch metrics.
Timeout behavior	When a connection times out, a NAT gateway returns an RST packet to any resources behind the NAT gateway that attempt to continue the connection (it does not send a FIN packet).	When a connection times out, a NAT instance sends a FIN packet to resources behind the NAT instance to close the connection.
IP fragmentation	Supports forwarding of IP fragmented packets for the UDP protocol. Does not support fragmentation for the TCP and ICMP protocols. Fragmented packets for these protocols will get dropped.	Supports reassembly of IP fragmented packets for the UDP, TCP, and ICMP protocols.

EBS Voulme and its Snapshot

List of Topics

1) Types of EBS volume
2) What is SSD & HDD
3) Difference between the volumes of EBS
4) What is IOPS/ Provsioned IOPS

5) What is IO Credit and Baseline performance
6) How Throughput Optimized volume (st1) Works
7) What is Baseline and Burstable performance

1) Types of EBS volume

AWS offers following 5 types of volumes, each differs by price performance and some other characteristics. The below listed types are mainly categorized by the two types of Disks first one is SSD and second is HDD.

a) SSD-Genral purpose (gp2)
b) SSD-Provisioned IOPS (io1)
c) HDD-Throughput Optimized (st1)
d) HDD-Cold backed (sc1)
e) Magnetic (Old Generation)

Before proceeding with the types of EBS in Detail will see what is SSD and HDD.

2) What is SSD & HDD

HDD - it will have physical disks and these are mechanical hard drive's. If exposed to elements there may be a data loss. Surface of disk should be free of contaminants. The Head of the disk moves back and front to read the data. HDD - backed volumes are optimized for large streaming workloads where throughput (measured in MiB/s) is a better performance measure than IOPS

SSD - SSD is like a flash Storage. It is too small and light compared to HDD. It has NO moving parts. Life span may be about 2000 years for newer generation and for Older generation is about 72 years if used heavly. Performance is 3 times faster than mechanical hard drive's. And even price is little more compared to HDD. Much reliable compared to HDD. SSD-backed volumes are optimized for transactional workloads involving frequent read/write operations with small I/O size, where the dominant performance attribute is IOPS

Less power 

3) Difference between the volumes of EBS

SSD-Backed Provisioned IOPS (io1) - I/O-intensive, NoSQL and relational databases
SSD-Backed General Purpose (gp2) - Boot volume, low-latency interactive apps, dev & test

HDD-Backed Throughput Optimized (st1) - Big data, data warehouse, log processing

HDD-Backed Cold (sc1) - Colder data requiring fewer scans per day

	General Purpose (gp2)	Provisioned IOPS (io1)	Throughput optimized (st1)	Cold backed (sc1)	Magnetic
Base Disk Type	SSD	SSD	HDD	HDD	Previous generation HDD
Use Cases	Recommended for frequently accessed workloads System boot volumes Virtual desktops Low-latency interactive apps Development and test environments	For Critical business applications that require sustained IOPS performance, or more than 10,000 IOPS or 160 MiB/s of throughput per volume Large database workloads,	Streaming workloads requiring consistent, fast throughput at a low price Big data Data warehouses Log processing Cannot be a boot volume	Throughput-oriented storage for large volumes of data that is infrequently accessed Scenarios where the lowest storage cost is important Cannot be a boot	Recommended for infrequently accessed workloads
Volume Size	1 GiB- 16TiB	4 GiB-16TiB	500 GiB-16TB	500 GiB- 16 TiB	1GiB-1TiB
	10,000	20,000	500	250
	65,000	65,000	65,000	65,000	48,000
Throughput Per instance	1,250 MiB/s	1,250 MiB/s	1,250 MiB/s	1,250 MiB/s	1,250 MiB/s
Performance based on attribute	OPS	OPS	MiB/s	MiB/s	OPS

4) What is IOPS

IOPS means Input/output operations per second, is used to measure performance of Hard disk drives (HDD), solid state drives (SSD), and storage area networks (SAN). IOPS is measured in integer. 

For more understanding of IOPS it can be compared to rpm of a car engine. If a vehicle is in neutral, stating that the engine is capable of spinning at 10,000 rpms in that moment is meaningless. Without taking into account the data block size (or I/O size), read/write activity or I/O stream, IOPS as a stand-alone measurement says little.

IOPS are a unit of measure representing input/output operations per second. The operations are measured in KiB, and the underlying drive technology determines the maximum amount of data that a volume type counts as a single I/O. I/O size is capped at 256 KiB for SSD volumes and 1,024 KiB for HDD volumes because SSD volumes handle small or random I/O much more efficiently than HDD volumes.

When small I/O operations are physically contiguous, Amazon EBS attempts to merge them into a single I/O up to the maximum size. For example, for SSD volumes, a single 1,024 KiB I/O operation counts as 4 operations (1,024÷256=4), while 8 contiguous I/O operations at 32 KiB each count as 1operation (8×32=256). However, 8 random I/O operations at 32 KiB each count as 8 operations. Each I/O operation under 32 KiB counts as 1 operation.

Similarly, for HDD-backed volumes, both a single 1,024 KiB I/O operation and 8 sequential 128 KiB operations would count as one operation. However, 8 random 128 KiB I/O operations would count as 8 operations.

Consequently, when you create an SSD-backed volume supporting 3,000 IOPS (either by provisioning an io1 volume at 3,000 IOPS or by sizing a gp2 volume at 1000 GiB), and you attach it to an EBS-optimized instance that can provide sufficient bandwidth, you can transfer up to 3,000 I/Os of data per second, with throughput determined by I/O size.

For example let’s compare how two workloads accessing the same amount of data require a significantly different amount of IOPS. 

The first workload requires reading ten 750MB files, 7.5GB and it takes 100 seconds for the transfer to occur. This means that the transfer rate is 75MB/s and consumes 10 IOPS, which is well within the capabilities of a single hard disk. The second workload requires reading ten thousand 750KB files, the same amount of data, 7.5GB, but it consumes 10,000 IOPS. Since the typical disk drive can’t generate more than 200 IOPS this request won’t get done in the same 100 seconds.(To Understand transfer of 75 Kg object each 7.5 KG will require less load than transfering 75KG which has 10,000 object.)  This is an example of how different workloads can require significantly different performance, while using the same storage capacity.

5) More About General Purpose volume

The performance of gp2 volumes is tied to volume size, which determines the baseline performance level of the volume and how quickly it accumulates I/O credits; larger volumes have higher baseline performance levels and accumulate I/O credits faster. 

Minimum IOPS - 100
Maximum IOPS - 10,000
Baseline  - 3 1OPS/GiB

Baseline of 3 IOPS per GiB with a minimum of 100 IOPS, burstable to 3000 IOPS. And Maximum IOPS for genral purpose is 10000. Also, IOPS for volume sizes greater than 3333 GiB is 10000 IOPS.

I/O credits represent the available bandwidth that your volume can burst large amounts of I/O when more than the baseline performance is needed. The more credits your volume has for I/O, the more time it can burst beyond its baseline performance.

Each volume receives an initial I/O credit balance of 5.4 million I/O credits, which is enough to sustain the maximum burst performance of 3,000 IOPS for 30 minutes

Volumes larger than 1,000 GiB have a baseline performance that is equal or greater than the maximum burst performance, and their I/O credit balance never changes. The maximum I/O credit balance for a volume is equal to the initial credit balance (5.4 million I/O credits).

Bursting and I/O credits are only relevant to volumes under 1,000 GiB, where burst performance exceeds baseline performance.

The burst duration of a volume is dependent on the size of the volume, the burst IOPS required, and the credit balance when the burst begins. This is shown in the following equation:

                            (Credit balance)

Burst duration  =  ------------------------------------

                   (Burst IOPS) - 3(Volume size in GiB)

Eg: If the credit balance is maximum(5.4 Million) and volume size is 1 GB then the burst duration is

Burst duration = 5400000/3000 - 3*1 = 5400000/2997 = 1801 (in Sec for Minutes 1801/60 = 30), then 30 Minutes is the maximum duration of this burst performance.

Throughput can never exceed 160 MiB/s. The throughput limit for gp2 volumes is 128 MiB/s for volumes less than or equal to 170 GiB and 160 MiB/s for volumes over 170 GiB. When I/O demand drops below the baseline level and unused credits are added to the I/O credit balance, the maximum IOPS performance of the volume will again exceed the baseline. 

6) Provisioned IOPS

Minimum IOPS - 100
Maximum IOPS - 20,000
IOPS max is based on 50:1 Ratio

The throughput limit of io1 volumes is 256 KiB for each IOPS provisioned, up to a maximum of 320 MiB/s (at 1,280 IOPS).

For example, a 100 GiB gp2 volume with an empty credit balance has a baseline performance of 300 IOPS and a throughput limit of 75 MiB/s (300 I/O operations per second * 256 KiB per I/O operation = 75 MiB/s)

6) How Throughput Optimized volume (st1) Works

Subject to throughput and throughput-credit caps, the available throughput of an st1 volume is expressed by the following formula:

(Volume size) x (Credit accumulation rate per TiB) = Throughput

In the above figure in throughput line it is showing Baseline 40 MiB/S  Per TB, as we are creating 500 GB volume the throughput is showing as 20 and 123 is the burstable performance.

For a 1 TiB st1 volume, burst throughput is limited to 250

6) What is Baseline and Busrtable performance

Trying to explain what is baseline performance and burstable performance in laymen way. Baseline performance is something like running a car with normal power and if normal power is not utilized completely, then leftover will be added to nitrous power (which is IO credit bucket) In case if we need more power then we can provision extra power by burning nitrous power till it gets empty (technically using io credit balance at some IOPS rate till the bucket becomes empty) even the nitrous mode will have some max speed like 200 KM/h similarly even provisioned IOPS will be bursted at some maximum IOPS  rate which is 3000 IOPS.

Monitoring the Burst Bucket Balance for gp2, st1, and sc1 Volumes

You can monitor the burst-bucket level for for gp2, st1, and sc1 volumes using the EBS BurstBalance metric available in Amazon CloudWatch. This metric shows the percentage of I/O credits (for gp2) or throughput credits (for st1 and sc1) remaining in the burst bucke

About EBS Snapshot

Snapshots occur asynchronously;

Status of the snapshot is pending until the snapshot is complete (when all of the modified blocks have been transferred to Amazon S3),

you can take a snapshot of a volume while a previous snapshot is in the pending status, having multiple pending snapshots of a volume may result in reduced volume performance until the snapshots complete.

Limit of five pending snapshots for a single gp2, io1, or Magnetic volume, and one pending snapshot for a single st1 or sc1 volume.

Snapshots that are taken from encrypted volumes are automatically encrypted. Volumes that are created from encrypted snapshots are also automatically encrypted.

To create a snapshot for an Amazon EBS volume that serves as a root device, you should stop the instance before taking the snapshot.