Whether or not root volumes on AWS need to be encrypted is a subject of debate. The encrypted AMI is all about protecting data at rest.
All three scenarios are pretty unlikely, but (as with most things in life) there are no guarantees. Some of our clients don’t keep the kind of sensitive information that mandates encryption. However, others who are entrusted with such data and are under regulatory mandates demand encryption.
At one point, it was only (easily) possible to encrypt data volumes. Many used these additional volumes to store sensitive information and avoid writing to the root volume. However, late in 2015, AWS announced encrypted EBS boot volumes- a great feature that closed the gap on the encryption front across the instance. For organizations with compliance requirements, encrypted EBS boot volumes aren’t just a feature, but a must have.
You can find command line examples of how to create an encrypted EBS volume from this AWS Blog.
At Fairwinds, we like to automate even further. Since we use Ansible, we put together a role that creates an encrypted AMI. In addition to handling the copy, the role will also help you find a base AMI to use for your encrypted AMI. (You can find the role on our Fairwinds GitHub page. If you’re going down the root volume encryption route, we hope this role will prove useful.)
In short, encryption is a no-brainer for those with regulatory requirements. Many questions go away if you can check the “all data is encrypted” box.
For those on the fence, I’ll offer this rule of thumb: If you encrypt your data volumes, you should also encrypt the root volume. After all, why put three deadbolts on the front door and then leave the back door open?