AWS Cost Saving Tip 18: Using AWS Tagging with Graffiti Monkey to Saves costs

Tagging AWS assets and resources is a simple and an important feature that helps IT teams streamline their process of managing the environments. We can categorize AWS resources in variety of ways using the AWS Tagging feature. For example: 

• Environment based Tags: Environment based tags can be used by customers who have Larger AWS footprints. These tags will help you to distinguish between production, development, and staging infrastructure deployed on AWS
• Application based Tags: Used to describe the set of disparate resources (or clusters) that work together to deliver a product or service to a customer. Can be applied on Small to Big AWS Production environments to identify the resources used
• Role based Tags– Used to describe the function of a particular node (web server, database server, load balancer, etc.). Owner – Used to identify the individual who is responsible for the instance. Both these cases are usable for small AWS foot prints.

How it helps ?
Tags can be very useful in understanding our AWS Billing. When you run large foot prints on AWS, constantly we need to monitor and manage our resource usage. Any IT operations team which manages AWS resources, constantly need to work on the following questions to optimize and manage their operations efficiently. Which AWS resources are used ? Which resources are lying idle (volumes, snapshots) in detached state ? Which Tiers or environments are consuming more billing than others? Which owner is exceeding the AWS cost allocated ? In short by starting to tag the AWS resources we will know how those assets are translating to monthly cost and take optimization decisions. Tagging is an simple but an essential feature that helps us to reduce and keep costs in control by improving our management efficiency in AWS.

AWS Tags in Detail:
Each tag consists of a key and a value, both of which the user can define. Currently AWS does not provide facility to TAG all AWS resources. Some of them can be Tagged only using API actions or the Command Line. The following Screen Shot shows all AWS resources and the restrictions that apply to them. Resources with tagging restrictions of None can be tagged with API actions, the CLI, and the console.

The following diagram illustrates how tagging works. In this example, i am assigning two tags to each of my EC2 instances, one called Owner and another called Stack. Each of the tags also has an associated value.
Owner = 8KMiles , Stack = Development, Stack = Production as illustrated in the below diagram

You can assign tags using the AWS Management Console, the Amazon EC2 command line interface (CLI), and the Amazon EC2 API.You can define tags from the EC2 console by selecting the relevant instance and selecting the “Tags” option.  Alternatively, you can select the instance, click “Actions” and select “Add/Edit Tags.” Below Screenshot shows how tags can be assigned using AWS Management Console

We have assigned Name, Owner , Environment and Contact for the 8KMiles Production instance using the AWS Tagging feature. The above is not the usual EC2 Managed Service naming standard , but just an simple illustration of the tag use case.
AWS Tagging Constraints and the Cost Leakage:
Currently AWS Tagging has some limitations as well. For example each tag associated with a single AWS resource, applies only to that particular resource and it is not propagated to the dependent resources attached to it. Example: Imagine if you have an EC2 instance, most of the times this EC2 instance is attached with dependent resources like EBS volumes, Snapshots etc. Usually there will be 1-2 EBS Volumes on normal scenarios and up to 8 EBS Volumes or more on RAID Scenarios. Number of snapshots are more in number and usually becomes unmanageable. Imagine how this problem will be propagated if you are running a Large AWS foot print with thousands of EC2 instances. 
You have to find each EBS volumes associated with a particular EC2 and Tag it separately.Managing this is easier said than done and usually slightest mis- management of these resources will lead to cost leakage. What if i can use a tool to automate tagging for dependent AWS resources. It will surely reduce the manual labor associated and help us remove all the dependent resources when we are removing the EC2. This avoids leakages and reduces cost of Cloud Operations in very dynamic AWS environments.

Welcome to Graffiti Monkey. 
The Graffiti Monkey goes around tagging things automatically. By looking at the tags of an EC2 instance, it copies those tags to the EBS Volumes that are attached to it, and then copies those tags to the EBS Snapshots as well. This small automation reduces hours of Manual labor on large AWS footprints, helps us efficiently manage the cloud infrastructure and reduce the cost leakages.

Step 1: Installation  of Graffiti Monkey 

Easiest way to install Graffiti Monkey using the usual PyPI channels.Please refer the below screenshot

link for installing pip.http://www.pip-installer.org/en/latest/installing.html

Step 2: Using Graffiti Monkey

It will identify the tags associated with EC2 instance and applies them to dependent resources like EBS volumes and snapshots saving hours of manual labor.

This Post is co authored with Nitheesh 8Kmiles

Other Cost Saving 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  
Cost Saving Tip 9: Have efficient EBS Snapshots Retention strategy in place 
Cost Saving Tip 10: Make right choice between PIOPS vs Std EBS volumes and save costs 
Cost Saving Tip 11: How elastic thinking saves cost in Amazon EMR Clusters ? 
Cost Saving Tip 12: Add Spot Instances with Amazon EMR 
Cost Saving Tip 13: Use Amazon Glacier for archive data and save costs 
Cost Saving Tip 14: Plan your deletion in Amazon Glacier and avoid cost leakage 

Cost Saving Tip 15: Plan your Amazon Glacier Retrieval strategy and avoid cost leakage 

Cost Saving Tip 16: Periodically remove your unwanted AWS resources and save costs (new)

AWS Cost Saving Tip 17: Add Amazon RDS Read Replica's on need basis and save costs (new)

Tips, Points to consider while building EC2 AMI's

This article is syndicated from Sanket's Blog : http://sanketdangi.com/post/52050147104/points-to-consider-while-bundling-ami

According to AWS, “Amazon Machine Images (AMIs) are the basic building blocks of Amazon EC2. An AMI is a template that contains a software configuration (operating system, application server, and applications) that you can run on Amazon’s proven computing environment.”

For example, an AMI might contain the software to act as a web server (Linux, Apache, and your web site) or it might contain the software to act as a Hadoop node (Linux, Hadoop, and a custom application).

There are three types of AMI’s :

A.      Public AMI – These are the ones which are freely available, advertised and shared with all AWS accounts. AWS has a huge collection of Public AMI’s.

 B.      Paid AMI – These are the ones which you can purchase from AWS marketplace, developers or service contract with any organization like RedHat.

 C.      Private AMI – These are the AMI’s which are generated from Public AMI’s and customized by us for our future use. They are available in only our AWS account. If we want we can share these AMI’s with other AWS accounts too. Also, if we want to share our private AMI with whole AWS community, we can convert that into a public AMI.

Below mentioned are some pointers which one can consider before bundling AMI’s :

1.       Remove Authorized Keys

Before bundling an AMI out of your current instance, please make sure to remove existing entries in .ssh/authorized_keys else the key from which the instance is launched will be automatically included. In case you forget to remove that entry, login into new instance (coming from newly bundled AMI) is only possible through old keypair. New keypairs won’t work.

For e.g.,  if the current instance is launched using keypair-1.pem and before bundling AMI, you have forgot to remove entries from authorized_keys, then access to new instance from newly bundled AMI is only possible through keypair-1.pem only. If you launch new instance using keypair-2.pem, we won’t be able to login into instance using keypair-2.pem file.  

Important : You will lose access to your current instance if you remove authorized_keys and exit from your current ssh session. Hence, ssh into same instance won’t be allowed.

2.       Delete history

It is always good to clear your command history.  before bundling an AMI. For clearing your command history, remove .bash_history or issue command “history –c”. There are possibilities that you might have issued commands using your access key and secret keys, private key pairs or other sensitive information.

3.       Provide meaningful names

It is advisable to provide meaningful names to your AMI’s and also post small description. It provides easy search for other users. This is strongly recommended if you plan to make your AMI as Public AMI.

4.       Empty log files

It is always good habit if you clear your existing log files before bundling AMI. Your instance might have logs files from various packages like apache, tomcat etc.

5.       Remove sensitive data

Don’t forget to remove any private keypairs and x.509 certificates or any additional confidential sensitive data if used.

6.       Delete all downloaded packages and files

If you have downloaded some packages (like s3cmd tools) or additional files and configured them on your instance, please remove them before bundling AMI.

7.       Disable SELINUX while bundling instance store backed AMI’s

If you are bundling instance store backed AMI’s, please remember to disable SELINUX before issuing ec2-bundle-vol command.

Understanding Amazon Elastic Block Store (EBS) in detail

Amazon Elastic Block Store (EBS) provides block level storage volumes for use with Amazon EC2 instances. In a typical block level storage device, raw storage volumes are created and then the server-based operating system connects to these volumes (over Fibre Channel, iSCSI etc) and uses them as individual drives. This fundamental flexibility makes block level storage usable for variety of application needs like file storage, database storage, virtual machine volumes and more. You can have variety of file system running on the block level storage, example NTFS for windows and ext3/XFS etc for Linux. In simpler terms Amazon EBS is like a massive SAN (Storage Area Network) in the AWS infrastructure. The physical storage could be hard disks, SSD’s etc under the EBS hood. Amazon EBS is one of the most important and heavily used storage services of AWS, even the building blocks like RDS, DynamoDB, CloudSearch etc possibly rely on EBS in the Cloud.

In Amazon EBS you can allocate a disk volume of 1GB to 1TB in size and data written will persist independently (unlike ephemeral disks) from the life of an Amazon EC2 instance attached with it. The volume is internally stored on redundant disks in an Amazon Availability Zone scope, which means that the EC2 instances using the EBS Volumes also should reside on the same AZ. The data is automatically replicated within the same Availability Zone (internally some form of RAID is employed by AWS) to prevent data loss due to failure of any single hardware component. Since the Amazon EBS lifetime is separate from the instance on which it is mounted, you can detach it and later attach it on another EC2 instance in the same availability zone.

Following are the few definitions which readers need to be conversant before going deep into this multi part article series :

IOPS	Input Output Operations Per Second
Throughput	Read / Write rate to storage in seconds (MB/s)
Capacity	Volume of Data that can be stored (GB)
AZ	Availability Zone within the Same Amazon EC2 region
SAN	Storage Area Network
RAID	Redundant Array of Independent Disks

EBS Volumes can currently be classified into two types. They are Standard EBS Volumes and Provisioned IOPS Volumes. Standard EBS Volumes are the first generation EBS Volumes that are suitable for sequential IO workloads. PIOPS Volumes are more consistent and are targeted towards OLTP workloads. Let us explore in detail about each type of EBS Volumes ?  what are the positives and negatives of using the same ? Any best practices, tips, points to remember while incorporating the same in the architecture. Refer the articles here Standard & PIOPS.

One of the biggest advantages of running your infrastructure in Amazon Web Services is the flexibility and the choice it offers to the architects while making critical decisions. Though cost savings is not the main reason why users migrate to AWS, it is also one of the important factors that needs to be taken care for efficient on going operations in on demand nature of Amazon Cloud. Making the right choice between Standard EBS Volumes and PIOPS volumes can have impact in the infrastructure cost savings in AWS infrastructure. By having an detailed understanding of what use cases best fit these volume types, you can accordingly provision suitable volume types in the architecture stack. Choosing a wrong volume can lead to a cost leakage between 20 - 70% based on the analysis done. Refer the article here. 

I read a line in AWS Documentation about EBS that " 10% of your provisioned IOPS 99.9% of the time" - What does this mean ? and why it is important ? Refer article here

We all know that AWS team constantly listens to the user inputs and delivers their product road map tying them. One such instance is their introduction of EBS Optimized EC2 instance. In normal EC2 instance, the Network is shared between your front facing workloads and your EBS IO operations. This often leads to congestion in high traffic web sites that rely a lot on OLTP database systems. Even though you RAID your EBS volumes to extract more IOPS, if the pipe between the EC2 instance and your EBS is constantly choked you end up scaling your instance types to get larger bandwidth. On cost and compute perspective , this is not an ideal scenario. AWS introduced EBS optimized instances specifically to tackle this situation and help users with better performance while using EBS volumes. Refer this article to understand how EBS optimized instances can help you extract better performance from your architecture.

Extracting higher performance from EBS is always an topic of interest to me as well lots of AWS enthusiasts and users. In order to achieve the same you need deeper understanding on IO latency and IO Block size. The IOPS rate you get usually depends on the I/O size of your applications’ reads and writes. It is very important to know the I/O size your application operates and accordingly expect the performance from EBS Volumes.Latency is a measure of how long it takes for a single I/O request to happen from the apps perspective.Only IOPS numbers alone are meaningless without considering additional metrics such as latency, read/write % and I/O block size etc.
Let us explore in this section, how these two factors can affect your performance expectation while using Amazon EBS and why it is important to know about them before tuning  Refer articles here IO Latency and IO Block Size.

Performance extraction from Amazon EBS :
Pre warming the EBS Volume. Click here.
EBS Striping. Click here.

Since EBS volume redundancy is limited to Availability Zone scope , it becomes a necessity incrementally backup the data stored in them frequently to a much more robust system like S3. EBS snapshot is one such technique that allows us to backup the state of a system at a particular point in time to S3 and they are incremental in nature. Users have lots of confusion on how these snapshots work internally, what happens if i delete an older snapshot ? what benefits it brings to the operations ? In this section we deep dive into the workings of EBS snapshots and answer questions like what are some of the objectives for using them? How to achieve consistent snapshots in AWS? what are the best practices, tips , points to note while using them. Refer article here.

Though EBS snapshots are incremental in nature , it is recommended to have a proper snapshot deletion and retention strategy in place. If this mechanism is not addressed as part of your on going IT operations, you can end up with a 70% cost leakage in some scenarios. Refer this article to understand in detail the analysis behind the cost savings. 

EBS snapshots have Amazon EC2 regional scope. In case you are planning to geographically expand or have data backed up on different Amazon EC2 region at regular intervals to minimize data loss and recovery time, you can use EBS snapshot copy feature for this purpose. How to copy EBS snapshots, Time taken between regions for copying ? Points to remember while implementing the same are covered in this article. Click here to understand more about EBS snapshot copy feature.

Common best practices for securing your EBS like IAM your EBS volumes, Wiping Data from EBS Volumes, Sharing Amazon EBS snaphsots,Storing AWS Credentials on an EBS Snapshot Securely are discussed in this article. If you want deeper protection for EBS you can also encrypt the volume using TrendMicro Secure Cloud. Check this article to get instructions for implementing the same in Amazon Web Services infrastructure

EBS Article Series Index

Part 1: Understanding Amazon Elastic Block Store
Part 2: Understanding Standard EBS Volumes
Part 3: Understanding EBS PIOPS Volumes
Part 4: Understanding EBS-Optimized Instances
Part 5: Understanding Latency in EBS
Part 7: 10% of your provisioned IOPS 99.9% of the time
Part 8: Performance Tuning - Pre Warming the EBS volume
Part 9: Performance Tuning - EBS Striping
Part 10: Performance Tuning - IO Block Size
Part 11: Understanding Amazon EBS Snapshots
Part 12: Securing Amazon EBS volumes - EBS Encryption using SecureCloud (new)
Part 13: Amazon EBS Security Best practices and tips
Part 14: How proper EBS Snapshot Retention strategy can save costs (new)
Part 15: Amazon EBS Snapshot copying- How-to, Performance and Tips (new)
Part 16: Make right choice between PIOPS vs Std Volumes and save cost (new)

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 15: Amazon EBS Snapshot copying- Performance, Tips and How to

Most of us know that EBS snapshots have Amazon EC2 regional scope. In case you are planning to geographically expand or have data backed up on different Amazon EC2 region at regular intervals to minimize data loss and recovery time, you can use EBS snapshot copy feature for this purpose.
The copied EBS snapshot behaves the same like regular snapshots, i.e. it can be used to create new EBS volumes which can then be attached to an EC2 instance in the destination region. Since the data is moved across regions in the form of snapshots, you will be charged only for the data transferred to copy the snapshot and to store the copied snapshot at the destination region.
Following table illustrates the time it takes to copy EBS snapshots from Different Source and Destination Amazon EC2 regions. Data used was a 50 GB compressed file stored on an Amazon EBS volume which was taken as a snapshot and transferred using EBS snapshot copy process. Since AWS keeps improving their infrastructure every day, the time taken may vary in coming months/years. But the figures mentioned below can used as an reference to plan your Recovery time objectives and migrations:

EBS Snapshot Copy vs Amazon EC2 Regions matrix :

Source Region	Destination region	File Size/Type/EBS Volume Size	Time Taken
USA-East	Singapore	50 GB Compressed file in EBS Volume	1 hr 24 min
USA-East	US-West (Oregon)	50 GB Compressed file in EBS Volume	24 min
USA-East	Europe (Ireland)	50 GB Compressed file in EBS Volume	45 min

Points to note about Amazon EBS snapshot copy :

• Unlike the create snapshot operation, which is incremental in nature, the EBS copy snapshot operation copies all of the bytes in the snapshot every time. It is recommended to use EBS snapshot copy once a day for larger databases with Multi region DR to reduce data transfer cost . Only if your DB is not a large one and you need better RTO/RPO + your IT budget can afford it, you should reduce this frequency accordingly.
• EBS Snapshots now support incremental copies. The first time you copy an EBS snapshot of a volume to a particular Region, all of the data will be copied.  The second and subsequent copies of snapshots from the same volume to the same destination region will be incremental: only the data that has changed since the last copy will be transferred. As a result, the snapshot will transfer less data and complete more quickly than before. It is recommended to use EBS snapshot copy across regions frequently if you need better RTO/RPO for DR.  . To know more about how EBS Snapshots works ? click here
• Currently RDS Snapshot copy is not supported. In case you need to move data to different Amazon Region you will have to manage it through RDS dumps or implement your own programmatic replication in EC2+RDS, till AWS RDS team introduces this feature. Customers who need their database to be backed up on different region on AWS, adopt some of the following strategies, let us take MySQL as the DB and explore some techniques:
• Configure MySQL on Amazon EC2 with Master-Slave mode. Freeze the file system and take regular snapshots in the source region. Copy these snapshots once or twice a day depending upon the RTO/RPO and DR budget using EBS Snapshot copy feature.
• Configure MySQL on Amazon EC2 with Master-Slave mode. Have another Slave running on Destination region which asynchronously updates records from the Master in source region. Secure the entire transport using SSL or VPN between regions.

How to do Amazon EBS Snapshot Copy between Regions ?


In this article we are copying a Snapshot from US-EAST Virginia Region to Asia Pacific Singapore Region.
EBS Snapshot Copy is done using the AWS Management Console:
1. Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/
2. In the Navigation pane click Snapshots under the Amazon Elastic Block Store menu

3. In the EBS Snapshot page select the Snapshot ID you need to copy to destination region and Click Copy.

4. In the Copy snapshot dialog box you need to fill the following details.
Destination Region: The region where you want to copy the snapshot. In this case it is Asia Pacific (Singapore)
Description: Description of the snapshot. By default you can retain the one as shown in the below figure.

5. Click Yes, Copy button and the following dialog screen will be shown as confirmation.

6. To check the progress of the snapshot copy go to the Destination region (Asia Pacific Singapore in this case) and check the progress in the EBS snapshot page.

EBS Article Series (continued..)

Part 1: Understanding Amazon Elastic Block Store
Part 2: Understanding Standard EBS Volumes
Part 3: Understanding EBS PIOPS Volumes
Part 4: Understanding EBS-Optimized Instances
Part 5: Understanding Latency in EBS
Part 7: 10% of your provisioned IOPS 99.9% of the time
Part 8: Performance Tuning - Pre Warming the EBS volume
Part 9: Performance Tuning - EBS Striping
Part 10: Performance Tuning - IO Block Size
Part 11: Understanding Amazon EBS Snapshots
Part 12: Securing Amazon EBS volumes - EBS Encryption using SecureCloud (new)
Part 13: Amazon EBS Security Best practices and tips
Part 14: How proper EBS Snapshot Retention strategy can save costs (new)
Part 15: Amazon EBS Snapshot copying- How-to, Performance and Tips (new)