{"id":14044,"date":"2021-05-30T23:33:55","date_gmt":"2021-05-30T16:33:55","guid":{"rendered":"https:\/\/renovacloud.com\/?p=14044"},"modified":"2021-06-04T21:09:58","modified_gmt":"2021-06-04T14:09:58","slug":"5-ebs-worst-practices-you-should-avoid","status":"publish","type":"post","link":"https:\/\/renovacloud.com\/en\/5-ebs-worst-practices-you-should-avoid\/","title":{"rendered":"5 EBS Worst Practices You Should Avoid"},"content":{"rendered":"

Are you an EBS user looking to cut costs and avoid cloud waste? You\u2019ve come to the right place!<\/span><\/p>\n

Using <\/span>Amazon Elastic Block Store (EBS) <\/b>volumes to store data is an integral part of using <\/span>Amazon Elastic Compute Cloud (EC2)<\/b>. Most EC2 use cases will have multiple EBS volumes attached to any given EC2 instance. Although EBS volumes are easy to set up, many organizations don\u2019t provision or manage them in the most optimal way so they can get the best possible price-performance ratio. This can lead to increased cloud waste.<\/span><\/p>\n

In this article, we\u2019ll outline some of the most common bad practices you should avoid, so you can be at the top of your EBS game.<\/span><\/p>\n

Overprovisioning EBS volumes<\/b><\/h3>\n

Not surprisingly, the most common EBS bad practice is over-provisioning. Overprovisioning happens when large-capacity, highly performant EBS volumes are attached to EC2 instances but contain little to no data, or work well above their required performance. Typically overprovisioning happens when volumes are created without any clear idea or planning about capacity and performance requirements.\u00a0<\/span><\/p>\n

Another example of overprovisioning is when high performance EBS volumes are attached to low network bandwidth EC2 instances. EBS volumes are accessed via a network, and the performance of an EBS volume is highly dependent on the network bandwidth and throughput of the EC2 instance it\u2019s attached to. Attaching a highly performant EBS volume to a low network throughput EC2 instance will result in low volume utilization. Also, using high-performance EBS volumes with non-EBS-optimized EC2 nodes will result in bigger latency.\u00a0<\/span><\/p>\n

\"\"<\/p>\n

These common EBS mistakes might not be a life-or-death hike up mount doom, but they can feel like it<\/b><\/p>\n

Overprovisioning results in unnecessary costs, and can be diagnosed by checking EBS volumes metrics.<\/span><\/p>\n

Keeping unused EBS volumes and snapshots<\/b><\/h3>\n

This is another bad practice where EBS volumes are provisioned for possible future use or detached from existing EC2 instances, but never used. These unattached volumes sit idle in the customer\u2019s account, costing money.<\/span><\/p>\n

You can check the AWS EC2 console for EBS to find unattached volumes, and safely remove them if they are not required.<\/span><\/p>\n

Using a single volume to store everything<\/b><\/h3>\n

This bad practice stems from how easy it is to provision EC2 instances, attach EBS volumes, and not give enough thought to the workload itself.\u00a0<\/span><\/p>\n

In this model, the operating system, application, data, logs, and swap space all share the same volume. It\u2019s often argued that using a single disk for everything was an issue in the old days when hard drives were directly attached to physical servers. Today, indeed a cloud-hosted volume\u2019s storage space maps to multiple, geographically separated machines. However, this is more to do with capacity than performance.<\/span><\/p>\n

As far as the operating system is concerned, it still sees the single volume as a storage area with a finite limit. So when that volume runs out of space, the applications in the machine are still affected.<\/span><\/p>\n

Let\u2019s consider a single-volume EC2 instance running a critical database. This machine will have an operating system cache, log files, and temporary files \u2013 all generated in the same volume where the data files are stored. If the log files are all blown up in size (perhaps due to an application bug sending huge trace messages to the files), the storage may run out far quicker than anticipated. This condition would affect the database\u2019s availability.<\/span><\/p>\n

It\u2019s therefore important to map out an EC2 instance\u2019s volume structure during the solution architecture phase. The only time using a single volume or the root volume to store everything makes sense is when the machine is hosting a small or less critical application. It also makes it easy to snapshot the volume.<\/span><\/p>\n

\"\"<\/span><\/p>\n

Never store everything in one place<\/b><\/p>\n

Using suboptimal file system<\/b><\/h3>\n

A file system dictates how data in a storage volume is stored, accessed, searched, written, or tracked. There are different file systems for different operating systems like Linux, UNIX, or Windows.\u00a0<\/span><\/p>\n

One file system often performs better than another for the same workload type. Often an EC2 instance is running multiple types of workloads, each accessing a different volume for its data. It then becomes a question of using different file systems for different EBS volumes attached to the EC2 instance. However, more often than not, the same file system is used in all the volumes \u2013 resulting in suboptimal performance.<\/span><\/p>\n

Once again, choosing the right file system for different workloads will be a part of solution architecture.<\/span><\/p>\n

Creating non-synchronized snapshots and lazily loading restored volumes<\/b><\/h3>\n

Snapshots are used to backup EBS volumes. Typically, the snapshot process is automated: a scheduled task runs a backup program or script against every EBS volume attached to every EC2 instance. Once completed successfully, the job usually sends a message to the operations team. It also sends a warning if it can\u2019t snapshot one or more volumes. However, backups should be carefully designed to ensure data can be recovered in case of a failure or accidental data loss.\u00a0<\/span><\/p>\n

Many snapshot processes need precise synchronization. For example, let\u2019s consider an application that runs on two EC2 servers. One EC2 machine hosts the app\u2019s database files, the other one hosts its binaries, logs, and configuration files. Throughout the day, both configuration files and the database are updated, and both need to be in sync.\u00a0<\/span><\/p>\n

By default, each EBS volume will have a backup done in isolation; there\u2019s no guarantee that isolated EBS volumes snapshots will start or finish at the same time, even if they are attached on the same EC2.\u00a0<\/span><\/p>\n

Now imagine this. The automated snapshot process backs up the database volume at the start of its job, and after a few hours, snapshots the configuration files\u2019 volume. Between the two snapshots, there\u2019s a gap of a few hours \u2013 making the volume backups out-of-sync. Oncerestored, these volumes may not work in sync for the application to come online properly.<\/span><\/p>\n

That\u2019s why, if your application has more than one volume that needs to be recovered in case of a failure and they need to be in-sync, make sure to use <\/span>crash-consistent snapshots across multiple volumes<\/span><\/a>.<\/span><\/p>\n

\"\"<\/span><\/p>\n

Make sure your backups are better synced than they are<\/b><\/p>\n

It\u2019s also important to notice that by default, after creating an EBS volume from a snapshot, the data isn\u2019t readily available inside the volume. The data is lazily loaded <\/span>only<\/span><\/i> when it\u2019s accessed.\u00a0<\/span><\/p>\n

For certain workloads like databases, this can mean the restored volume performs slower than desired for a long time until all the data has been accessed at least once. <\/span>Fast Snapshot Restore<\/span><\/a> addresses this issue. Although it comes with extra costs, it should be carefully considered for latency-sensitive workloads.<\/span><\/p>\n

Bonus: Not encrypting volumes<\/b><\/h3>\n

Okay, we thought we would talk about five EBS worst practices, but here\u2019s another one \u2013 just as a bonus.<\/span><\/p>\n

Disk encryption ensures that data stored in a volume is encrypted with a symmetric key. In case the AWS account is hacked, bad actors can make your EBS snapshots public, copy the snapshot to their account, and then change the access permission of the snapshot back to private. They can then attach the copied snapshot to their own EC2 instance and access the data.<\/span><\/p>\n

\"\"<\/p>\n

Scary right? Not so much if you encrypt\u00a0 your volume. Without the key used to encrypt the EBS volume, the snapshot can\u2019t be restored.<\/span><\/p>\n

Many organizations encrypt their critical data volumes as part of regulatory compliance. Those that choose not to,\u00a0 are at risk of data breach. Ideally, data should be encrypted both at rest and in transit.<\/span><\/p>\n

Encrypting EBS volumes with AWS KMS keys is a simple process as this <\/span>AWS documentation<\/span><\/a> shows.<\/span><\/p>\n

Final words<\/b><\/p>\n

Amazon EBS is a useful, flexible and easy-to-use managed service from AWS. Hopefully, this article has given you some ideas about the pitfalls you can avoid when using EBS volumes and the means to address them. Designing and using EBS volumes appropriately can help minimize associated costs, as well as improve data security, data recovery, and performance.\u00a0\u00a0<\/span><\/p>\n

You can also <\/span>contact<\/span><\/a> one of our cloud optimization experts to learn how you can minimize EBS management efforts and maximize savings.<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"

Are you an EBS user looking to cut costs and avoid cloud waste? You\u2019ve come to the right place! Using Amazon Elastic Block Store (EBS) volumes to store data is an integral part of using Amazon Elastic Compute Cloud (EC2). Most EC2 use cases will have multiple EBS volumes attached to any given EC2 instance. […]\n","protected":false},"author":2,"featured_media":14040,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[],"tags":[35,405,765],"class_list":["post-14044","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","tag-aws","tag-aws-2-en","tag-ebs-en"],"_links":{"self":[{"href":"https:\/\/renovacloud.com\/en\/wp-json\/wp\/v2\/posts\/14044","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/renovacloud.com\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/renovacloud.com\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/renovacloud.com\/en\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/renovacloud.com\/en\/wp-json\/wp\/v2\/comments?post=14044"}],"version-history":[{"count":0,"href":"https:\/\/renovacloud.com\/en\/wp-json\/wp\/v2\/posts\/14044\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/renovacloud.com\/en\/wp-json\/wp\/v2\/media\/14040"}],"wp:attachment":[{"href":"https:\/\/renovacloud.com\/en\/wp-json\/wp\/v2\/media?parent=14044"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/renovacloud.com\/en\/wp-json\/wp\/v2\/categories?post=14044"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/renovacloud.com\/en\/wp-json\/wp\/v2\/tags?post=14044"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}