Deep Dive on Elastic Load Balancing

© 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved.

Mariano Vecchioli – AWS Technical Account ManagerBen Doyle, Senior Infrastructure Engineer, Ensighten

July 2016

Deep Dive onElastic Load Balancing

Elastic Load Balancing

Security Scalability Availability

Security

SSL/TLS SSL Security Policies

• Same-day mitigation for POODLE

• Same-day mitigation for LogJam

• Same-day mitigation for Heartbleed

• RC4 removed in advance of ratings and compliance changes

SSL/TLS Management

https://github.com/awslabs/s2n

SSL/TLS Management

SSL/TLS Cipher Suites

• Always prefer perfect forward secrecy.

• Prefer AES over 3DES over RC4.

• Prefer GCM over CBC + HMAC.

• Compare against billions of connections from real-world clients.

SSL/TLS Cipher Suites

• Legacy clients can cause compatibility issues• Old firmware in embedded systems• TVs, controllers, web scrapers…

• ELB defaults strike a balance

• Access log gap analysis

• We recommend ELBSecurityPolicy-2015-05


2015-05-13T23:39:43.945958Z my-loadbalancer192.168.131.39:2817 10.0.0.1:80 0.000086 0.001048 0.001337 200 200 0 57 "GET https://www.example.com:443/ HTTP/1.1” "curl/7.38.0" DHE-RSA-AES128-SHA TLSv1.2

S3


2015-05-13T23:39:43.945958Z my-loadbalancer192.168.131.39:2817 10.0.0.1:80 0.000086 0.001048 0.001337 200 200 0 57 "GET https://www.example.com:443/ HTTP/1.1” "curl/7.38.0" DHE-RSA-AES128-SHA TLSv1.2

ELB and Security Compartmentalization

Public subnet

Private subnet

Threat Modeling

Scalability

Scalability

Latency = Load / Throughput

Scalability

Memory Latency

Scalability

Caching and cache misses

Scalability

Processing time

Cou

nt

Scalability

GET / HTTP/1.1

GET /monthly_report/ HTTP/1.1

Scalability

Processing time

Cou

nt

Scalability

Wait time

Cou

nt

Scalability

Scalability

Wait time

Cou

ntWeighed round robinSingle server

Scalability

Scalability

Wait time

Cou

ntWeighed round robinSingle server

Least connections

Scalability

Wait time

Cou

nt

Beware of blackholing

traffic

Weighed round robinSingle server

Least connections

ELB’s own scaling is a mix of pre-emptive, based on the instance capacity you add, and reactive,

based on the load you receive.

CloudWatch and Auto Scaling

All load balancer metrics can be used for Auto Scaling.

Allow you to scale dynamically based on the loadbalancers' view of the application.

Important to consider all metrics when using Auto Scaling; may not be aware of resource contention on another metric.

You may be at peak multiple times a day.

13 CloudWatch metrics provided for each load balancer.

Provide detailed insight into the health of the load balancer and application stack.

CloudWatch alarms can be configured to notify or take action, in case any metric goes outside of the acceptable range.

All metrics provided at 1-minute granularity.

Amazon CloudWatch metrics

Latency

Measures the time elapsed in seconds after the request leaves the load balancer until the response is received.

Test by sending requests to the back-end instance from another instance.

Using minimum, average, and maximum, CloudWatch stats provide upper and lower bounds for latency.

Debug individual requests using access logs.

SurgeQueue and Spillovers

Count of the number of requests that could not be sent to back-end instances.

Queue up to 1,024 requests per load balancernode, after which 503 errors will be returned.

Often caused by not being able to open connections to the back-end instance.

Normally a sign of an underscaled application.

• timestamp• elb name• client:port• backend:port• request_processing_time• backend_processing_time• response_processing_time• elb_status_code

• backend_state_code• received_bytes• sent_bytes• “request”• “User-Agent”• Ciphersuite• SSL/TLS protocol version

Access Logs

2015-05-13T23:39:43.945958Z my-loadbalancer 192.168.131.39:2817 10.0.0.1:80 0.000086 0.001048 0.001337 200 200 0 57 "GET https://www.example.com:443/ HTTP/1.1” "curl/7.38.0" DHE-RSA-AES128-SHA TLSv1.2

Global Scalability

ELB integrates with Amazon Route 53 latency–based routing and geo-based routing.

Useful for applications where latency is critical.

Online advertising bidding.

Trading 53

Availability

Ben DoyleSenior Infrastructure Engineer

Digital analytics company with 2 types of products:

- Data collection and analysis of web traffic- Website content (tag) management

Multiple global platforms for both

Seamless and graceful replacement of instances

with no downtime

Health Checks

ELB

EC2instance

EC2instance

EC2instance

Health Checks

Support for TCP and HTTP health checks.

Customize frequency and failure thresholds.

Must return a 200 response.

Think hard about health check “depth”.

Idle timeouts allow for connections to be closed by the load balancer when no

longer in use.

Length of time that an idle connection should be kept open

For both client and back-end connections

Defaults to 60 seconds but can be set between 1 and 3,600 seconds

Timeouts should decrease as you go up the stack

Idle Timeouts

15s

3s

3sELB

15sEC2instances

Amazon S3

Amazon RDS

Amazon SWF3s

9s

Idle Timeouts

Multiple Availability Zones

VPC

EC2instanceELB

ELB EC2instance

us-w

est-1

aus

-wes

t-1b

AmazonRoute 53

Protected by Route 53 Health Checks

All load balancers scaled to handle theloss of a single Availability Zone.

Amazon Route 53 health checks shift traffic away from the failed Availability Zone.

Completed within 150 seconds.

No other external or control plane dependencies.

Health checkers and edge locations perform the same volume of activity,whether endpoints are healthy or unhealthy.

Constant work

time

System activityTime to react

When nothing is failing, the volume of API calls is zero. When failure occurs, the volume of API calls spikes.

time

System activityTime to react

Work on failure

Always associate two or more subnets in

different zones with the load balancer

Using multiple Availability Zones does bring a few challenges

Req

uest

cou

nt

Time

Traffic Imbalances

DNS Caching and Spreading

DNS TTLs are generally honored.

But sometimes there simply are not enough DNS servers to spread load around fairly.

Mobile networks typically have a dozen or so top-level resolvers.

Enterprise networks may have as few as one.


VPC

EC2instanceELB

ELB EC2instance

us-w

est-1

aus

-wes

t-1b

AmazonRoute 53


EC2instanceELB

ELB

us-w

est-1

aus

-wes

t-1b

AmazonRoute 53

VPC

Req

uest

cou

nt

Time

Traffic Imbalances

Cross-zone enabled

Load balancer absorbs impact of DNS caching.

Eliminates imbalances in back-end instance utilization.

Requests distributed evenly across multipleAvailability Zones.

Check connection limits before enabling.

No additional bandwidth charge for cross-zone traffic.

Cross-zone Load Balancing

Integrated with AWS CloudFormation, AWS OpsWorks, AWS Elastic Beanstalk, Amazon ECS, Amazon API Gateway, and Asgard.

Load balancers are a common gateway for blue/green deployments.

Load balancers can be managed programmatically for immutable Deployments.

ELB and DevOps

Recap

Fully Managed SSL/TLS StackAWS Certificate ManagerCompartmentalisation

CloudWatch MetricsAccess LogsGlobal Scalability

Minimal DowntimeRoute53 Health ChecksCross-zone Load Balancing

Please remember to rate this session under My Agenda on

awssummit.london

Mariano VecchioliAWS Technical Account Manager

[email protected]@

Ben DoyleSenior Infrastructure Engineer

[email protected]__Doyle

Deep Dive on Elastic Load Balancing

Technology

Transcript of Deep Dive on Elastic Load Balancing