Always Encrypt AWS EC2 Instances

When running a business and the goal is to become successful, you may inevitably fill out a risk assessment questionnaire that asks, “Is all your data encrypted at risk?”. And when you start looking at your list of EBS volumes created over the past period of time, you might be surprised to learn that the “encrypted” property of your volumes very well might equal “false”. NVMe instance store volumes are encrypted, but many EC2 solutions rely on EBS volumes, and they are not encrypted by default.

Encryption at rest for Amazon Elastic Block Store (EBS) volumes protects data when it’s not in use. It ensures that data stored on the physical storage media in an AWS data center is unreadable to anyone without the appropriate decryption key. Many argue this is a fundamental component of a strong security strategy, and they are not wrong.

AWS leverages its Key Management Service (KMS) to manage the encryption keys. You can use the default AWS-managed keys or create and manage your own customer-managed keys (CMKs) for more control over key policies, access permissions, and rotation schedules.

Does encryption at rest really matter while at an AWS data center, specifically? Unless you are dealing with classified information, probably not. AWS has an amazing level of virtual security separating your data from bad actors, both virtually and physically. The chances of someone walking off with your data medium (hard drive) are slim to none, and when the medium goes bad, the destruction and audit process is equally impressive. But at the end of the data, it matters to someone’s boss, their investors, policies, perception, and potentially your career. Many industry regulations and security standards, such as HIPAA, PCI DSS, and GDPR, require that sensitive data be encrypted at rest.

Security is like an onion with many layers. While AWS has robust physical and logical security controls in place, encryption at rest adds another vital layer of protection. This “defense-in-depth” approach ensures that even if one security control fails, others are there to prevent a breach.

Encryption isn’t limited to just the EBS volume itself. Per AWS documentation, when you encrypt an EBS volume, any snapshots you create from it and any subsequent volumes created from those snapshots will also be automatically encrypted. This provides an end-to-end security envelope for your data’s entire lifecycle.

So why not do it? The list of reasons is small, but you need to be aware of them, especially when dealing with AMIs and cross-region copies:

  • Very minimal increase in latency (typically negligible)
  • If a key becomes unusable (disabled or deleted), you cannot access the encrypted volume data until the key is restored
  • Additional key management overhead may be necessary if you opt to manage your own keys
  • AMIs with encrypted snapshots cannot be shared publicly – only with specific AWS accounts
  • Cannot directly copy encrypted snapshots to another region (must re-encrypt with destination region key)
  • Minimal additional cost for AWS KMS key usage

When creating an EC2 instance, the default view does not encrypt the volume. You will need to press the “Advanced” link in the “Configure storage” section first.

Then, expand your volume details. Next, change the “Encrypted” property from “Not encrypted” to “Encrypted”. Optionally, select your KMS key or leave it alone, and it will use the default. While you are here, you may wish to change the “Delete on termination” from “No” to “Yes”. This will help prevent any accidental data loss in edge cases, but be aware that this may lead to unexpected orphaned EBS volumes if you don’t go in and clean up your EBS volumes when you delete EC2 instances.

If you forget to turn this on, or you have an existing instance, you can still convert the volume to encrypted. It is a bit of a process though. You need to stop the instance, create an encrypted snapshot, detach the volume from the instance (jot down the device name such as /dev/xvda), restore the encrypted snapshot as a volume, and attach the volume to the instance with the same device mapping.

#aws, #ebs, #ec2, #encryption

Lessons Learned for Windows EC2 Reserved Instances on AWS

March 2017 rolls around and AWS releases awesome new flexibility with reserved instances (RI). You can now split and merge RI’s as well as be automatically be pro-rated on-demand instance costs if you own a lesser RI. I also watch YouTube videos that also explain how this new flexibility works and how great it is. But in the excitement of it all I don’t realize that this new flexibility only applies to regional Linux/UNIX RIs with shared tenancy within the same instance class.

Here’s a case example:
You run an e-Commerce site that runs an m4.large instance. On January 1st 2017 you reserved a m4.large instance for one year. Come December 1st, traffic is expected to double for the Christmas season, so you scale up your instance to a m4.x-large instance type until January 1st.

If Running Linux:
Your annual savings is 38% over on-demand if you were to use m4.large during the entire 2017 year. However jumping up to m4.x-large will increase your bill by about what a m4.large instance would cost on-demand for the month of December 2017. This pro-rated charge is done automatically. There are a couple Linux OS exceptions and hourly Software charges are not calculated in this example.

If Running Windows:
Your annual savings is 20% over on-demand if you were to use m4.large during the entire 2017 year. However jumping up to a m4.x-large will increase your bill by about what a m4.x-large instance would cost on-demand for the month of December 2017. Essentially your savings now are negative due to the fact that your instance is not pro-rated with your RI. This is due to the fact that you are still paying for your reserved instance of m4.large, but it’s not being used. Then on top of that you’re paying for a m4.x-large. As an example, one year of a reserved m4.large costs $1349.04, a savings of $332.88. One month of m4.large not being used costs on average $140.16. This brings your 20% savings down to around 9%. Hourly Software charges are not calculated in this example.

Summary:
When running Linux you have fairly minimal risk involved when getting a reserved instance. However your risk goes up quite a bit reserving a Windows instance. There are a number of options to mitigate that risk level down. One option is to get a convertible RI. This allows you to exchange OS,  family or tenancy. But keep in mind your big picture. For you this may only be good if you think you’ll need to move from a t2 to a m4 family. Another option is you can sell your unwanted RI on the marketplace at a reduced price. When looking at this option, consider how much savings equates to dollars and how much time you’ll need to calculate the risk, estimated savings reduction and time spent selling when selling an RI. Of course different instance types have different savings levels. In the end, it comes down to either a statistician to calculate risk vs. benefit or theories and experience.

In conclusion, I likely wouldn’t bat an eye getting either a standard or convertible RI for Linux if I largely suspected the RI would be needed for at least a year. But I would likely keep a Windows instance on-demand if there was any chance for instability unless I had enough on-demand instances to off-set the risk if one instance no longer matches an RI for a time period.

#aws, #ec2, #instance, #linux, #reserved, #windows

Buying AWS Unwanted EC2 Reserved Instances

You purchase a year-long EC2 Reserved Instance (RI) from Amazon Web Services (AWS). You’re now saving 30% on your sparkling EC2 instance cost!

Fast forward three months. Your project tanked and is costing you money instead of making money. You need to kill it and kill it fast.

But then you remember that one-year contract you have with AWS. <doomed>

You then remember that you can sell off your RI to a marketplace. Bank account saved – mostly.

That part is easy to research and follow the steps for success.

Now “Wannabe Joe” is looking for a deal and wants to purchase that discounted RI you’re selling off. Joe goes to the EC2 console and clicks “Reserved Instances”. He then proceeds to “Purchase Reserved Instances”.

He sees a paragraph:

Reserved Instances sold through the Reserved Instance Marketplace are identical to those sold by Amazon Web Services, except they may have different prices and terms. For more information about the Reserved Instance Marketplace, go to the Reserved Instance Marketplace web page.

He remembers about the marketplace selling unwanted instances so he clinks on the provided link. Listing, selling, fee and getting paid. All great for the seller. But how does he purchase one. Click-after-click just provides frustration.

Don’t worry Joe. You overthought the whole process.

  1. In the AWS Console Home, go to the EC2 console
  2. Press the “Reserved Instances” link on the left and then press the “Purchase Reserved Instances” button up top.
  3. Choose your platform, types, zone, term and tenancy.
  4. Press the “Search” button
  5. If there are any unwanted instances up for sale, they will be listed under the “Seller” column as “3rd Party”.
  6. Add to cart and away you go.

console_ri_purchase_1

Simple 🙂

Reference and image by: https://aws.amazon.com/blogs/aws/amazon-ec2-reserved-instance-marketplace/

#aws, #ec2, #marketplace, #reserved

AWS EBS Live Volume Modification Gotcha

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)

modify-disabledI 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

#aws, #ebs, #ec2, #elastic-volumes, #live-volume-modification, #magnetic

Attach AWS IAM Role to Existing EC2

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.

  1. Create an IAM role
  2. Attach the IAM role to an existing EC2 instance that was originally launched without an IAM role.
  3. Replace the attached IAM role.

https://aws.amazon.com/blogs/security/new-attach-an-aws-iam-role-to-an-existing-amazon-ec2-instance-by-using-the-aws-cli/

#aws, #ec2, #iam, #role