Friday, July 10, 2020

ELB Listeners


ELB Listeners
-         https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-listener-config.html
-         A listener is a process that checks for connection requests. It is configured with a protocol and a port for front-end (client to load balancer) connections, and a protocol and a port for back-end (load balancer to back-end instance) connections.
-         Support Layer 4 (TCP/SSL) and Layer 7 (HTTP/S) for both front and back end
-         The ELB and target EC2 protocols should be of same layer (HTTP->HTTP or TCP->TCP). Can’t mismatch and have HTTP->TCP

Layer 4 (TCP/SSL)
-         EC2 sees ELB address as the source IP at the received packets
-         to expose connection request detail – originator’s IP/Port:
          §  enable proxy protocol on ELB (available only on layer4, i.e. TCL/SSL not HTTP/S)
-         Potential issue: if there is another Proxy on the way into ELB (upstream), this would double up the proxy headers. It will confuse EC2 as it will not know which one of the two proxy headers to read to extract the originator’s detail
Layer 7 (HTTP/S)
-         SSL Offloading – have ELB decrypt HTTPS
          To use HTTPS ELB needs to have X.059 SSL/TLS certificate – to terminate the https client session, decrypt and send HTTP to EC2
          ELB will terminate the incoming session, decrypt the HTTPS traffic and establish a new session into EC2
Advantages:
          §  SSL handshake is most CPU/Hardware intensive part of the encryption – offload to ELB
          §  Can inspect traffic before sending it to the server – intrusion protection
Disadvantage:
          §  Traffic is not encrypted end-to-end – decrypting in the middle

-         SSL certificate can be purchased from AWS or uploaded
-         To expose connection request detail – i.e. originator’s IP/Port:
          §  can't use Proxy on HTTP/S. 
          §  need HTTP X-Forwarded-for header enabled on ELB when HTTP/S is used. EC2 will need to parse and filter based on this header.
-         The X-Forwarded-For request header helps you identify the IP address of a client when you use an HTTP or HTTPS load balancer. Because load balancers intercept traffic between clients and servers, your server access logs contain only the IP address of the load balancer. To see the IP address of the client, use the X-Forwarded-For request header. Elastic Load Balancing stores the IP address of the client in the X-Forwarded-For request header and passes the header to your server (https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/x-forwarded-headers.html)
Also: X-Forwarded-Proto, X-Forwarded-Port.

To filter out specific sources from accessing EC2 choices are:
-         NACL – can disallow
-         Security Group – can only do allow, if the question is to allow specific sources. Cannot Disallow.
-         Proxy protocol on Layer 4
-         X-Forwarded-For on Layer 7

Connection Draining
-         For the duration of the configured timeout, the load balancer will allow existing, in-flight requests made to an instance to complete, but it will not send any new requests to the instance. During this time, the API will report the status of the instance as InService, along with a message stating that “Instance deregistration currently in progress.” Once the timeout is reached, any remaining connections will be forcibly closed. (https://aws.amazon.com/blogs/aws/elb-connection-draining-remove-instances-from-service-with-care/)

Monitoring
-         Can Configure Access Logs and select an S3 bucket to dump logs into. By default – checks are done every 1 minute


No comments:

Post a Comment