AWS Cost Saving Tip 10: Make right choice between PIOPS vs Std EBS volumes for saving costs

Tip 1: When using EBS PIOPS Volumes saves cost ?
Since OLTP databases are generally IO intensive with random read/write pattern and demand consistent IOPS they are better suited for EBS PIOPS volumes than Standard EBS volumes. At an instant look of the PIOPS pricing table, it may sound expensive compared to Standard EBS volumes, but when you are applying it in right use cases actually you can save better costs than standard EBS volumes.
Let us explore some scenarios on how PIOPS saves cost than Standard EBS Volumes:

Imagine you are running a Database on Amazon EC2 instance with following requirements.

Scenario 1:
Load: Medium load -Read/Write
Type : OLTP
DB : MySQL
IOPS: 1,000
Volume Size : 500 GB
EC2 instance : m1.xlarge
EBS Optimized - Yes

EBS Type	Volume Size	IOPS	IOPS Cost	Volume Price	Overall (USD)
PIOPS	500	1000	100	62.5	~162.5
Standard	500	Best effort	259	50	~309
PIOPS = 500 X0.125 + 1000 X 0.1 = ~162.5 Standard = 500 X 0.1 + (86400 X 30 X 1000 /1000000) X 0.1 = ~309  Standard volumes are assembled in EBS Striping (RAID 0) to get 1000 IOPS in Best effort basis

Savings : You can achieve ~47% cost savings if EBS PIOPS can be used instead of Standard EBS Volumes for OLTP scenario for medium loads


Scenario 2:
Load: Heavy load -Read/Write
Type : OLTP
DB : MySQL
IOPS: 10,000
Volume Size : 1 TB 
EC2 instance : m2.4xlarge
EBS Optimized - Yes

EBS Type	Volume Size	IOPS	IOPS Cost	Volume Price	Overall
PIOPS	1 TB	10000	1000	125	~1125
Standard	10 TB	Best effort	2592	1000	~3592
PIOPS = 1 TB X0.125 + 10000 X 0.1 = ~1125 Standard = (10 X 1TB) X 0.1 + (86400 X 30 X 10000 /1000000) X 0.1 = ~3592 Standard volumes are assembled in EBS Striping (RAID 0 = 1 TB X 10) to get 10000 IOPS in Best effort basis ( not guaranteed)

Savings : You can achieve ~68% cost savings if EBS PIOPS can be used instead of Standard EBS Volumes for OLTP scenario for Heavy loads 

It is clear from the above analysis that if you have OTLP workloads with consistent IOPS requirements then depending upon the Volume Size and number of IOPS required, your savings also proportionately increases if you choose PIOPS volumes over Standard volumes.

Tip 2: When using EBS standard Volumes saves cost ?
When you are designing an online application, it is common that not all the tiers demand consistent IOPS. Example: Your web and application layers usually do not demand consistent IOPS.  Unless you are locally writing lots of data files in web/app EC2 (which is not a advisable practice) you do not need PIOPS volumes for these tiers. For such tiers standard EBS volumes are recommended. Standard volumes are well suited for use as boot volumes for web/app tiers, where the burst I/O capability provides fast instance start-up times (+1 when used in autoscaling). In addition std volumes are better performers for sequential operations. ex: Workloads like OLAP databases, Reporting stores etc which are more sequential, bursty and follows batch-oriented pattern are a better fit for standard volumes.
Let us explore some scenarios on where to use standard volumes and avoid PIOPS overuse and save costs.
Scenario 3:
Load: Low IOPS, boot volumes , bursty workloads
Tier : Web/App 
IOPS: 30-100
Volume Size : 30 GB
EC2 instance : m1.large
EBS Optimized - No

EBS Type	Volume Size	IOPS	IOPS Cost	Volume Price	Overall
PIOPS	30 GB	100	10	3.75	~13.75
Standard	30 GB	30-100	7.7	3	~10.7
PIOPS = 30 GB X0.125 + 100 X 0.1 = ~13.75 Standard = 30 GB X 0.1 + (86400 X 30 X 30 /1000000) X 0.1 = ~10.7

Imagine you 10+ EC2 serving your Web/App Tier then multiply this cost :

13.75 X 10 = ~137.5 USD

10.7 X 10 = ~ 107 USD

Savings : You can achieve ~22% cost savings if EBS volumes can be used instead of PIOPS Volumes for boot/sequential scenarios. 

It is evident that from the above analysis that wisely choosing right EBS volume type saves money. All layers of the application stack will not demand heavy and consistent IO in a larger web scale application; Secondly EBS PIOPS is costlier than standard EBS volumes. Taking both the points into consideration, I usually recommended to mix-match your tiers with standard EBS/PIOPS volumes and other storage options to get better overall cost efficiency and performance in Amazon Cloud.

Other Tips

Cost Saving Tip 1: Amazon SQS Long Polling and Batch requests
Cost Saving Tip 2: How right search technology choice saves cost in AWS ?
Cost Saving Tip 3: Using Amazon CloudFront Price Class to minimize costs
Cost Saving Tip 4 : Right Sizing Amazon ElastiCache Cluster
Cost Saving Tip 5: How Amazon Auto Scaling can save costs ?
Cost Saving Tip 6: Amazon Auto Scaling Termination policy and savings
Cost Saving Tip 7: Use Amazon S3 Object Expiration
Cost Saving Tip 8: Use Amazon S3 Reduced Redundancy Storage  (new)
Cost Saving Tip 9: Have efficient EBS Snapshots Retention strategy in place (new)
Cost Saving Top 10: Make right choice between PIOPS vs Std EBS volumes and save costs (new)

Part 4: AWS High Availability Patterns : Database Tier

High Availability @ Database Layer

Data is the most valuable part of any application and designing High Availability for the Database Layer is the most critical priority in any Fault tolerant architecture. To avoid Single Point of Failure in the Database layer it is a common practice to launch the Multiple Database server's in Master-Slave replication or Cluster mode. Now let us see some of the common architecture practices and considerations for the same in AWS: 

Master Slave Replication:

We can configure 1 MySQL EC2 as master and 1 or more MySQL EC2 as Slaves in this architecture. If they are deployed in AWS public cloud, then the Database Servers needs Elastic IP, if they are deployed in AWS Virtual Private Cloud, then we can work with internal VPC Network IP itself. Master and Slave will use Asynchronous replication of data between themselves in this mode. When the Master DB EC2 fails, using custom scripts we can promote one of the slave DB EC2 as master and ensure HA in this layer. We can have Master- Slave architecture running in Active-Active(A-A) or Active-Passive(A-P) HA mode. In A-A mode, all writes and immediate write-read txns should be done in Master DB EC2, independent reads are done from slave DB. In A-P mode all writes and reads should be done on master, only when master fails, slave is promoted and made active. It is recommended to use EBS backed AMI’s for all Database EC2 server instances for stability on disk level. For additional performance and data integrity we can configure MySQL EC2-EBS with various RAID levels as well in AWS. 

MySQL NDBCluster:

We can configure 2 or more MySQL EC2 for SQLD + Data nodes and 1 MySQL EC2 as management node in this cluster architecture in AWS. Both the nodes in cluster will use Active Synchronous Data Replication between themselves. Write/Reads can be performed on both the nodes simultaneously. When one EC2 DB node in cluster fails other will be active to take the txn requests. If they are deployed in AWS public cloud, then the Database Servers needs Elastic IP, if they are deployed in AWS Virtual Private Cloud, then we can work on internal VPC Network IP itself. It is recommended to use EBS backed AMI’s for all Database EC2 server instances for stability on disk level. For additional performance and data integrity we can configure MySQL EC2 cluster-EBS with various RAID levels as well in AWS. 

Multi-AZ RDS HA:

If we use Amazon RDS MySQL for the database layer, then we can configure 1 Master in Amazon AZ-1and 1 Hot Standby in another Amazon AZ-2 (will explain AZ concepts in detail in coming sections). We can additionally have multiple Read Replica Slaves attached to the RDS Master-Slave combination. For Additional HA, we can distribute RDS Read Replicas in Multiple AZ’s as well. RDS Master and Slave nodes will use Synchronous Data Replication between themselves. Read Replica Slaves will use asynchronous replication. When the RDS Master fails, RDS Hot Standby will get promoted automatically in minutes with the same endpoint URL. All writes and immediate write-read txns should be done in RDS Master, Independent reads can be done from RDS Read Replica’s. All RDS instances are currently built over EBS; RDS also offers point in time recovery and automated backups for stability. RDS can work inside Amazon VPC as well.

Related Articles : AWS High Availability Patterns Series

Part 2: AWS High Availability Patterns:Web App Tier

Part 3: AWS High Availability Patterns : DNS Load Balancing Tier

Part 4: AWS High Availability Patterns : Database Tier

Part 5: AWS High Availability Patterns : Multiple Availability Zones

Part 6: AWS High Availability Patterns : Using AWS Building Blocks

Part 7: AWS High Availability Patterns : Multi Region Architecture

Part 8: AWS High Availability Patterns : Multiple Cloud Providers

Full Article : Overcoming Outages in AWS : High Availability Architecture Patterns