Crib-Notes: End-to-End SSL Within AWS

In general, when using an Elastic Load-Balancer (ELB) to do SSL-encrypted proxying for an AWS-hosted, Internet-facing application, it's typically sufficient to simply do SSL-termination at the ELB and call it a day. That said:

• If you're paranoid, you can ensure that only the proxied EC2(s) and the ELB are able to communicate with each other via security groups.
• If you're under compliance-requirements (e.g., PCI/DSS), you can enable end-to-end SSL such that:
  1. Connections between Internet-based client and the ELB are encrypted
  2. Connections between the ELB and the application-hosting EC2(s) is encrypted

Either/both amount to a "belt and suspenders"  approach. Other than "meeting policy", security isn't meaningfully improved: given AWS's overarching security-design, even if someone else has access to your application-EC2(s) and ELB's VPC, they won't be able to sniff packets/data – encrypted or not.

Technical need aside... Implementing end-to-end SSL is trivial:

• ACM allows easy provisioning of SSL certificates for the ELB (with the security-bonus of automatically rotating said certificates). 
• You can very generic, self-signed certificates on your application-hosting EC2s:
  
  • The certificate's Subject doesn't matter
  • The certificate's validity window doesn't matter (no need to worry about rotating certificates that have expired)

Thus setup comes down to:

1. Create an EC2-hosted application/service:
   1. Launch EC2
   2. Install HTTPS-capable application
   3. Generate a self-signed certificate (setting the -days to as little as 1 day). Example (using the OpenSSL utility):
      
      

      openssl req -x509 -nodes -days 1 -newkey rsa:2048 \
         -keyout peer.key -out peer.crt

      
      When prompted for input, just hit the <RETURN> key (this will create a cert with defaulted values ...which, as noted previously, don't really have bearing on the ELB's trust of the certificate). Similary, one can wholly omit the -days 1 flag and value – the default certificate will be valid for 30 days (but, ELB doesn't care about the validity time-window).
      
   4. Configure the HTTPS-capable application to load the certificate
   5. Configure the EC2's host-based firewall to allow connections to whatever port the application listens on for SSL-protected connections
   6. Configure the EC2's security group to allow connections to whatever port the application listens on for SSL-protected connections
2. Create an ELB:
   1. Set the ELB to listen for SSL-based connection-requests (using a certificate from ACM or IAM)
   2. Set the ELB to forward connections using the HTTPS protocol to connect to the target EC2(s) over whatever port the application listens on for SSL-protected connections
   3. Ensure the ELB's healthcheck is requesting a suitable URL to establish the health of the application 

Once the ELB's healthcheck goes green, it should be possible to connect to the EC2-hosted application via SSL.If one wants to verify the encryption-state of the connetction between the ELB and EC2(s), one would need to login to the EC2(s) and sniff the inbound packets (e.g., by using a tool like WireShark).