ELB Cont - Session Stickiness, Encryption, etc.

Session Stickiness
-         A.k.a., session persistence, is a process in which a load balancer creates an affinity between a client and a specific network server for the duration of a session, (i.e., the time a specific IP spends on a website). A load balancer assigns an identifying attribute to a user, typically by issuing a cookie or by tracking their IP details. Then, according to the tracking ID, a load balancer can start routing all the requests of this user to a specific server for the duration of the session. (https://www.imperva.com/learn/availability/sticky-session-persistence-and-cookies/#:~:text=Session%20stickiness%2C%20a.k.a.%2C%20session%20persistence,IP%20spends%20on%20a%20website).)
-         Legacy approach to this – keep all session detail in db shared by servers. If one node fails – another picks up using the detail from db.
-         Requires SSL termination (offloading) on ELB – need X.509 on ELB (purchased or imported)
-         SSL Certificate MUST be in same region as ELB
-         Requires HTTPS

Cookies:
-        Cookie generated by ELB - Duration-based session persistence
          §  If EC2 fails, ELB reroutes to a new healthy instance but the session is no longer sticky
-         Cookie generated by the application - Application-controlled session persistence
          §  ELB will honor one if supplied by the app. If app cookie expires - session is no longer sticky, load balance based on EC2 busy-ness.
          §  If EC2 fails but cookie hasn't expired yet, route traffic to a new instance and keep session sticky
Pros of session stickiness:
-         Minimized data exchange – servers within your network don’t need to exchange session data, a costly process when done on scale.
-         RAM cache utilization – Sticky sessions allow for more effective utilization of your application’s RAM cache, resulting in better responsiveness.
 Cons:
-         Not fault tolerant – EC2 can fail, information loss
-         server can become overloaded if it accumulates too many sessions, or if specific sticky sessions require a high number of resources. This could result in your load balancer having to shift a client to a different server mid-session, resulting in data loss.

SSL - Encryption
-         Secure Socket Layer - negotiation configuration, aka security policy
-         Includes encryption protocol version, ciphers, etc.
-         Front end (client) – can define his own security policy or use one pre-defined by AWS
-         Back end – can only use pre-defined by AWS
Security Policy Components:
-         SSL Protocols: SSL / TLS: TLS v1.0, 1.1, 1.2, SSL 3.0. No TLS 1.3 or 2.0
-         SSL Cipher suite – which encryption algorithms will be used
-         Server Order Preference
          §  By default - enabled
          §  if enabled – first cipher match in ELB cipher list that matches an entry in the client cipher list is used
          §  if disabled - first match in Client cipher list with ELB is used
-         SSL cert provided by AWS Certificate Manager contains RSA public key. Need to make sure the cipher suite that uses RSA is included in the sec policy (RSA in the cipher name).
-         AWS will configure ELB with current/latest pre-defined security policy – by default unless specified otherwise
-         Only a single X.509 supported by single ELB (for example: a single website is hosted behind ELB). If need to use multiple certificates – define multiple ELB's.
-         One-way authentication – cert is stored on the server, used to prove server's identity
-         2-way authentication – certificates on both Client and Server. 
-         Client-side certificate authentication - not supported by ELB with HTTPS. If required – use TCP (not https) from Client to Server and let Client<->Server perform authentication + enable proxy protocol on ELB. Server will need to read proxy headers, able to encrypt/decrypt and MUST have a certificate. Sticky Session feature would not be supported as it requires HTTPS.
-         For Proxy Protocol on ELB:      TCP<->TCP or SSL<->TCP
-         For X-Forwarded-For header:   HTTP<->HTTP or HTTPS<->HTTP or HTTPS<->HTTPS
 
ELB Connection Draining
-         Disabled by default
-         Wait for in-flight sessions to complete (1-3600 sec, 300 sec by default)
-         "InService: Instance Deregistration Currently In Progress"
-         No new requests are sent to instance
 
Can use Route 53 for DNS failover between 2 ELBs in 2 regions
 
ELB Monitoring
-         CloudWatch – will collect info about ELB node itself
          §  if requests flow via ELB (ELB is active), ELB Service will send metrics every 1 min - only if there is traffic flowing through ELB.
          §  Can use SNS to send notifications if threshold approaching. Enabled by default.
-         Access Logs – info about requestor (IP, port, timestamp, etc.); disabled by default.
          §  Contains originator's detail - if you need to see information about requester etc. Goes into the specified S3 bucket, S3 charges apply.
-         Clout Trail – API calls audit trail. Can also be stored in S3.
 
ELB Pre-Warming
-         It takes 1-7 min to spin off a new ELB node if utilization is approaching 100%
-         Requests above ELB capacity fail – no queueing
-         Can handle traffic increases of 50% every 5 min
-         If anticipating a spike – contact AWS and ask pre-warm ELB's to specific capacity
 
ELB Scaling
-         ELB DNS is updated with public IP's of new ELB nodes
-         ELB uses DNS record TTL of 60 sec to ensure updates are disseminated to clients
-         When stress-testing from a single client – need to make sure DNS re-resolution is enabled on the machine which is the source of the stress messages. This will make sure that as new ELB nodes are added due to increase in traffic, the client is aware of these new nodes

-         ELB Connection Timeout default – 60 sec. Need to make sure the apps on the back end have time out of 60 sec or greater. Otherwise the app will be dropping the connection prior to ELB realizing that there is a need to drop. ELB will interpret this like a problem with EC2

Termination Policy
-         Scale in:https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-termination.html
-         Default Termination Policy:
          §  Determine which instances to terminate so as to align the remaining instances to the allocation strategy for the On-Demand or Spot Instance that is terminating
          §  Determine whether any of the instances use the oldest launch template or configuration

          §  After applying all of the above criteria, if there are multiple unprotected instances to terminate, determine which instances are closest to the next billing hour. If there are multiple unprotected instances closest to the next billing hour, terminate one of these instances at random