AWS has a diverse list of instance types. From general-purpose servers to others more suitable for CPU- or memory-intensive workloads, of various sizes. I/O performance is also a variable. Without extensive application benchmarks, it’s a challenge to pick the most suitable instance type a priori. Frequently, users find themselves with instances that are too big for their needs, and pricier.
Choosing and provisioning instances that suit your operational needs at any time is one of cloud computing’s highlights – adding a new server is as easy as following a simple wizard. As a by-product of this flexibility, many times one gets to a number of compute instances growing very fast, much faster than expected. Sometimes it becomes difficult to keep track of all the instances that you have launched and identify those that are just sitting around without doing anything.
Stale resources can become a management nightmare in cloud environments. One of the important aspects of the economics of a pay-per-use model is the “use” – pay for what you use and don’t pay for what you don’t use. The details of what “use” is makes things a bit more complicated than they seem.
One of the handiest features of AWS is EBS Snapshots – the ability to create virtual copies of EBS Volumes at a specific point in time. Snapshots offer an adequate instrument to perform backups of EBS Volumes, and are also efficient: only the data blocks that have changed in the volume since your last snapshot are saved. It comes as a surprise that with such an easy facility for volume backups, we still find so many volumes with no or too few snapshots.
This is a variation of the previous Mistake #5: Forgetting to Clean Up Stale Resources, but curious enough to get its own post. Users tend to forget that AWS charges for Elastic IPs only when they’re not in us (it’s a bit counter-intuitive even though the motivation is clear: preventing users to keep IP addresses reserved without ever using them).
In the previous post of this series (Mistake #6 - Taking too Few or No EBS Snapshots) we pointed out how AWS users fail to leverage EBS Snapshots in their back-up process. On the other extreme of snapshot usage lays another mistake. Being easy as it is, EBS snapshot creation, when done without moderation, leads very fast to sprawling. Too many snapshots to manage add complexity to your backup process. Even though you’re only charged for the differential data, snapshot sprawling can still increase your storage costs on an aggregated basis, especially in combination with another common mistake – forgetting to clean up stale resources.
Amazon’s approach to security is based on “shared responsibility” between users and AWS – Security Groups is one of the tools Amazon provides for users to fulfill their part. One would expect that when it comes to security, users don’t err.
AWS ‘Availability Zones’ is a simple feature that distributes a user’s workload across multiple data centers within a given region. We don’t even need to go as far as saying users don’t leverage AWS multiple regions to distribute their workload – the complexity and overhead in this case might be significant. AWS availability zones on the other hand are a simpler tool to pull advantage from distributed workloads in the cloud, yet users commonly overlook this capability.
In AWS, users are charged for allocated Elastic IPs that are not associated to a running instance nor to a network interface (VPC). Therefore, the best practice is to keep only those IP addresses that will be needed in the future. Allocated Elastic IPs you don’t plan to use in the future, or those you just forgot to release, may contribute to unexpectedly high bills.
Newvem tracks the usage of your allocated Elastic IPs and identifies those that haven’t been in use for a significant period. We suggest you consider releasing those allocated IP addresses if you do not plan to use them.