In my journey through the cloud I often come across great new initiatives. The interesting fact is that although the cloud is a pure revolution terms such as SLA, TCO and ROI remain valid, new methodologies and techniques are presented to support them in the cloud.
In part one I described the AWS EBS snapshot mechanism. In this part I will drill deeper on how to calculate the EBS snapshot cost. I will show how to be able to do a rough estimation or even to perform an accurate cost analysis using monitoring tools.
In order to estimate how large your EBS snapshots will be, you need to know how much your volumes are changing. One way would be to guesstimate,we can use a simple thumb rule that is often used in- backup planning: A typical data volume of a production server changes about 3% a day. Let’s try and calculate the cost. Assuming a 1TB EBS volume, that is 70% full at first. We take snapshots and keep them for 30 days. So, the first full will be taking 700GB (70% of 1TB). For the incremental snapshots we can multiply 30 (days) by 30GB (3% of 1TB) and we reach 900GB. Add them together and we reach about 1.6TB of total snapshot storage. AWS compresses the snapshots when they are stored in S3.
When you keep important business data in your EC2 servers, you need a backup and disaster recovery (DR) solution like you would for any server. For operational backup, the most efficient and effective approach in EC2 is to use EBS snapshots. These are the parallel of hardware snapshots in a traditional data center.In this post we will discuss the challenges you encounter when you use EBS snapshots.
In part 1 of this three part series, we introduced Amazon Glacier as an extremely low-cost cloud storage service that provides secure, durable, and flexible storage for data backup and archival. Amazon Glacier allows you to store your data reliably for as little as $0.01 per gigabyte per month. It helps you to retain your data for future analysis or reference so you can focus more on business than operating and maintaining storage infrastructure.
The following describes my personal case on how I maintained snapshots of my AWS EBS. The following requirements guided me with the scripts and tools I decided to use:
Scalability is about application, architecture and infrastructure design, and careful management of server components.
If you’re using MySQL checkout 5 ways to boost MySQL scalability in the cloud-
The cloud definitely marks a new era. Not only can we manage our resources in a flexible way and with no capital investment, but we can also enjoy the state-of-the-art infrastructure of large cloud providers, like AWS cloud. Specifically, when we use EC2 to compute endless resources, we know that in terms of the durability of our virtual servers, power supply, and storage, we can trust AWS to have the best of the best.
In case of a disaster we would like to make sure that our applications are still up and running, while taking advantage of our failover hosting/cloud provider. The Disaster Recovery (DR) architecture is driven by the criticality of applications and data. The decision regarding what to back up and deploy eventually translates into ongoing costs that can be extremely significant. Every IT organization has its own high level policy guidelines. These policies are eventually translated into the policy deployed for each of the different applications the enterprise runs. The CIO and its team need to make sure they define both the high level policies and the actual budget that can be spent for DR matters.
The policies for Disaster Recovery (DR) in an enterprise are driven by the criticality of applications and data. As the public cloud has gained in credibility, more and more IT teams are taking advantage of the failover public cloud provider as a way of addressing DR and ensuring business continuity.
On the following presentation Lahav Savir, architect and CEO of Emind Systems, gives an introduction to Disaster Recovery and presents his insights based on Emind’s best practices.
