Data Encryption

EBS Volume Encryption
EBS has been configured to always encrypt new volumes. See AWS EBS encryption for technical details.

Amazon RDS Encryption
Amazon RDS databases, which internally utilize EC2 instances, are also configured to use encrypted EBS volumes. A custom KMS key is generated for this purpose. See Encrypting Amazon RDS resources for additional information.

Communication between your applications and Amazon RDS databases should use a TLS certificate to encrypt traffic. This requires the use of the Amazon RDS CA certificate which has been conveniently installed for you in every EC2 instance in your environment at /etc/ssl/rds-combined-ca-bundle.pem. See Using SSL/TLS to encrypt a connection to a DB instance for useful configuration and usage information.

S3 Bucket Encryption
S3 buckets are configured to automatically encrypt objects using Amazon's server-side encryption key. When creating new buckets, you can either default to this key or use a custom KMS key. However, the custom key needs to be in the same region as the bucket.

Load Balancer End-to-End Encryption
AWS requires that network traffic is encrypted all the way to EC2 instances if protected health information is being transmitted. This means one cannot terminate an SSL connection at the load balancer, passing data in the clear to internal machines. Instead, an SSL certificate is attached to the load balancer, and the Web server on each EC2 instance is configured with a local self-signed certificate.

ElastiCache Encryption
If your system is using ElastiCache Redis to persist protected health information, it has been configured to encrypt data at rest and a local stunnel service connection has been installed on each EC2 instance so that traffic can be encrypted in transmission. See ElastiCache for Redis in-transit encryption.

Transmitting Data Securely Between Instances
To transfer data between EC2 instances during one-off operations, create a local SSH keypair on the origin machine and then add the public key to each destination machine's ".ssh/authorized_keys" file under the relevant user's home directory. Then use the scp utility which leverages an encrypted SSH session to transfer data.

Another approach, which does not require SSH keys, is to use the AWS CLI to upload a file to an S3 bucket from the origin machine and then download the file from S3 on the destination machine. See the S3 reference page.

Data transmitted between applications and internal API's should also be encrypted. The Web server for the API endpoints should have an SSL certificate. In addition, an internal load balancer can be added in front of internal machines. This load balancer would have its own certificate.