How to create HTTPS Load Balancer with SSL Cipher in Amazon AWS Cloud

Tasks for Creating a HTTPS Load Balancer with SSL Cipher Settings and Back-end Server Authentication

1	Configure the listeners for your load balancer by specifying the ports and protocols to use for front-end connection (client to load balancer) and back-end connection (load balancer to back-end instance) and install SSL server certificate on your load balancer.
2	Configure SSL ciphers for SSL negotiation when a connection is established between the client and your load balancer.
3	[Optional] Enable the back-end server authentication.
4	Configure an application health check for your back-end instances.
5	Register Amazon EC2 instances with your load balancer.
6	Verify the details of your newly created load balancer.

 Complete process here Ref: AWS Documenation 

Lastly, I wanted to list several of the benefits and some not so well known gotchas of utilizing AWS ELB's.

Benefits:

• Very simple way of delivering high availability across AZ's in the same region
• Provides web and application resiliency in the event of site issues, hardware/application failure
• Can be configured as External or Internal - if using a VPC end points for your clients or application to reference
• Supports TCP, Secure TCP, HTTP and HTTPS, supports the use of certificates -> how to configure SSL as well as many other ports for your applications to use.
• Built in health checks for instance availability, highly configurable
• Low cost to implement
• Now provides access to the ELB logs, stored in S3 providing insight into traffic patterns, server responses, latency and will help to troubleshoot issues with your back end apps.
• Can be managed and manipulated using the GUI or the API
• Support cross-zone load balancing
• Support Sticky Sessions
• Supports the use of Security Groups to secure your instance and reduce your exposure.

Gotchas:

• Supports limited low ports, does not support passing traffic like SMB, FTP etc.
• AWS ELB's do not span across regions, only across Availability Zones
• Has a default timeout value for session-state of 1 minute; this can be changed with help from support to a higher value if your application requires this
• When instances are stopped behind an ELB, the ELB status is updated to stopped.  Upon restart of the instance, the ELB is not automatically updated to the correct state, requiring the instance to be re-registered
• Limited per view of the ELB, limited self service options to support
• Once created, you cannot modify the ELB to be internal or external facing and you cannot rename the ELB it has to be deleted and recreated.  You are able to change listeners, health checks, security groups, networks used, adding SSL etc.