We currently run some magnetic EBS volumes for data storage accessed by EC2 instances. Last month AWS announced the availability of Live Volume Modification with Elastic Volumes on EBS. This would enable a volume to expand while being in-use. Where as before you’d have to schedule downtime.
Live Volume Modification is almost a must-have feature for the web servers we run to be cost efficient and reduce any downtime. I have also noted that EBS Magnetic Volumes are now considered “previous generation” technology. (AKA: silent deprecation, just like reduced redundancy S3)
I attempted to expand a magnetic volume on a m3.large instance but found that the modify link was disabled. After a forum post, and the helpful reply from AWS, I found that previous generation magnetic volumes can not be modified while live.
This feature is too important and we will be moving to a SSD volume type instead to enable this feature. However it remains to be seen what restrictions we may have. Documentation states: “Current generation m3.medium instances fully support volume modification. However, some m3.large, m3.xlarge, and m3.2xlarge instances may not support all volume modification features.”
See more information at “Considerations for Modifying EBS Volumes”
Forum reference: https://forums.aws.amazon.com/message.jspa?messageID=771210
It has always been one of my pet-peeves that I had to attach an IAM role to an EC2 instance just in case I’d need it in the future. The reason was you couldn’t attach one later.
Attaching a role allows API access to AWS from your instance w/o having to inject API keys, which reduces security and maintainability (you’d have to remember to change out the keys when rotating keys).
AWS has now announced that you can attach an IAM role to an exiting EC2 instance.
- Create an IAM role
- Attach the IAM role to an existing EC2 instance that was originally launched without an IAM role.
- Replace the attached IAM role.
Stop using Reduced Redundancy S3 storage (RRS) on AWS now. Starting price for RRS is now $0.024 where as standard S3 starts at $0.023.
This caught me off guard today as I use RRS for backups due to what used to be an approximate 33% savings over standard S3.
For me using Glacier for backups is out of the question due to the waiting period necessary to get files.
There is also the newer “Standard – Infrequent Access” storage type for S3. This is a good option for storing perhaps a system image when doing backups, however for what I normally backup, which are small website files, this likely won’t be a good fit either. Each file has a minimum storage bill of 128KB. The math and gamble required likely won’t be worth the effort.
So for now I’ll likely be switching to all standard S3 storage for backups. I don’t use S3 for much else other than EC2 snapshots and temporary file storage for migrations.