AWS ROUTE 53 AND ELB

Syed Sameer
AWS Enterprise Architect

Reference from AWS Documentation

Reference from AWS Documentation
HOW DNS WORKS

A user opens a web browser, enters www.example.com in the address bar, and presses Enter.

The request for www.example.com is routed to a DNS resolver, which is typically managed by
the user's Internet service provider (ISP), such as a cable Internet provider, a DSL broadband
provider, or a corporate network.

The DNS resolver for the ISP forwards the request for www.example.com to a DNS root name
server.

The DNS resolver for the ISP forwards the request for www.example.com again, this time to
one of the TLD name servers for .com domains.
The name server for .com domains responds to the request with the names of the four Amazon
Route 53 name servers that are associated with the example.com domain.

The DNS resolver for the ISP chooses an Amazon Route 53 name server and forwards the
request for www.example.com to that name server.
Reference from AWS Documentation
The Amazon Route 53 name server looks in the example.com hosted zone for the
www.example.com record, gets the associated value, such as the IP address for a web server,
The DNS resolver for the ISP finally has the IP address that the user needs.
The resolver returns that value to the web browser. The DNS resolver also
caches (stores) the IP address for example.com for an amount of time that
you specify so that it can respond more quickly the next time someone
browses to example.com. For more information, see time to live (TTL).

The web browser sends a request for www.example.com to the IP address

that it got from the DNS resolver. This is where your content is, for example,
a web server running on an Amazon EC2 instance or an Amazon S3 bucket
that's configured as a website endpoint.

The web server or other resource at 192.0.2.44 returns the web page for
www.example.com to the web browser, and the web browser displays the
page.
Reference from AWS Documentation
Reference from AWS Documentation
Reference from AWS Documentation
Reference from AWS Documentation
Choosing a Routing Policy
When you create a record, you choose a routing policy, which determines how Amazon Route 53
responds to queries:

Simple routing policy – Use for a single resource that performs a given function for your domain,
for example, a web server that serves content for the example.com website.

Failover routing policy – Use when you want to configure active-passive failover.

Geolocation routing policy – Use when you want to route traffic based on the location of your
users.

Geoproximity routing policy – Use when you want to route traffic based on the location of your
resources and, optionally, shift traffic from resources in one location to resources in another.

Latency routing policy – Use when you have resources in multiple AWS Regions and you want to
route traffic to the region that provides the best latency.

Multivalue answer routing policy – Use when you want Route 53 to respond to DNS queries with up
to eight healthy records selected at random.

Weighted routing policy – Use to route traffic to multiple resources in proportions that you specify
Reference from AWS Documentation
Load Balancer

 Elastic Load Balancing automatically distributes incoming application traffic

across multiple targets, such as Amazon EC2 instances, containers, and IP
addresses.
 It can handle the varying load of your application traffic in a single
Availability Zone or across multiple Availability Zones.
 Elastic Load Balancing offers three types of load balancers that all feature the
high availability, automatic scaling, and robust security necessary to make
your applications fault tolerant.

Reference from AWS Documentation

Reference from AWS Documentation
Reference from AWS Documentation
Reference from AWS Documentation
Reference from AWS Documentation
Reference from AWS Documentation
Reference from AWS Documentation
Reference from AWS Documentation
Reference from AWS Documentation
Reference from AWS Documentation
Reference from AWS Documentation
Reference from AWS Documentation
Reference from AWS Documentation
Reference from AWS Documentation
Reference from AWS Documentation
Reference from AWS Documentation
Reference from AWS Documentation
Reference from AWS Documentation
Application Load balancer

An Application Load Balancer makes routing decisions at the application layer

(HTTP/HTTPS), supports path-based routing, and can route requests to one or
more ports on each container instance in your cluster. Application Load Balancers
support dynamic host port mapping.

Reference from AWS Documentation

Application Load Balancer operates at the request level
(layer 7), routing traffic to targets – EC2 instances,
containers, IP addresses and Lambda functions based on
the content of the request.

Ideal for advanced load balancing of HTTP and HTTPS

traffic, Application Load Balancer provides advanced
request routing targeted at delivery of modern
application architectures, including microservices and
container-based applications. Application Load Balancer
simplifies and improves the security of your application,
by ensuring that the latest SSL/TLS ciphers and protocols
Reference from AWS Documentation

are used at all times.

Key Features
Layer-7 Load Balancing
You can load balance HTTP/HTTPS applications and use layer 7-specific features, such as X-Forwarded-For
headers.

HTTPS Support
An Application Load Balancer supports HTTPS termination between the clients and the load balancer.
Application Load Balancers also offer management of SSL certificates through AWS Identity and Access
Management (IAM) and AWS Certificate Manager for pre-defined security policies.

Server Name Indication (SNI)

Server Name Indication (SNI) is an extension to the TLS protocol by which a client indicates the hostname to
connect to at the start of the TLS handshake. The load balancer can present multiple certificates through the
same secure listener, which enables it to support multiple secure websites using a single secure listener.
Application Load Balancers also support a smart certificate selection algorithm with SNI. If the hostname
indicated by a client matches multiple certificates, the load balancer determines the best certificate to use
based on multiple factors including the capabilities of the client.

IP addresses as Targets
You can load balance any application hosted in AWS or on-premises using IP addresses of the application
backends as targets. This allows load balancing to an application backend hosted on any IP address and any
interface on AWS
Reference from anDocumentation
instance. Each application hosted on the same instance can have an associated security group
and use the same port. You can also use IP addresses as targets to load balance applications hosted in on-
premises locations (over a Direct Connect or VPN connection), peered VPCs and EC2-Classic (using ClassicLink).
Lambda functions as Targets
Application Load Balancers support invoking Lambda functions to serve HTTP(S) requests enabling users to
access serverless applications from any HTTP client, including web browsers. You can register Lambda
functions as targets for a load balancer and leverage the support for content-based routing rules to route
requests to different Lambda functions. You can use an Application Load Balancer as a common HTTP
endpoint for applications that use servers and serverless computing. You can build an entire website using
Lambda functions or combine EC2 instances, containers, on-premises servers and Lambda functions to build
applications.

High Availability
An Application Load Balancer requires you to specify more than one Availability Zone. You can distribute
incoming traffic across your targets in multiple Availability Zones. An Application Load Balancer automatically
scales its request handling capacity in response to incoming application traffic.

Security Features
When using Amazon Virtual Private Cloud (VPC), you can create and manage security groups associated with
Elastic Load Balancing to provide additional networking and security options. You can configure an Application
Load Balancer to be Internet facing or create a load balancer without public IP addresses to serve as an
internal (non-internet-facing) load balancer.

Reference from AWS Documentation

 Host-based Routing
You can route a client request based on the Host field of the HTTP header allowing you to
route to multiple domains from the same load balancer.

Path-based Routing
You can route a client request based on the URL path of the HTTP header.

HTTP header-based routing

You can route a client request based on the value of any standard or custom HTTP header.

HTTP method-based routing

You can route a client request based on any standard or custom HTTP method.

Query string parameter-based routing

You can route a client request based on query string or query parameters.

Source IP address CIDR-based routing

You can route a client request based on source IP address CIDR from where the request
originates.

Reference from AWS Documentation

Containerized Application Support
Application Load Balancer provides enhanced container support by load balancing across
multiple ports on a single Amazon EC2 instance. Deep integration with the Amazon EC2
Container Service (ECS), provides a fully-managed container offering. ECS allows you to
specify a dynamic port in the ECS task definition, giving the container an unused port
when it is scheduled on the EC2 instance. The ECS scheduler automatically adds the task
to the load balancer using this port.

HTTP/2 Support
HTTP/2 is a new version of the HyperText Transfer Protocol (HTTP) that uses a single,
multiplexed connection to allow multiple requests to be sent on the same connection. It
also compresses header data before sending it out in binary format and supports SSL
connections to clients.

WebSockets Support
WebSockets allows a server to exchange real-time messages with end-users without the
end users having to request (or poll) the server for an update. The WebSockets protocol
provides bi-directional communication channels between a client and a server over a
long-running TCP connection.

Native IPv6
Reference from Support
AWS Documentation

Application Load Balancers support native Internet Protocol version 6 (IPv6) in aVPC. This
Sticky Sessions
Sticky sessions are a mechanism to route requests from the same client to the same target.
Application Load Balancer supports sticky sessions using load balancer generated cookies. If
you enable sticky sessions, the same target receives the request and can use the cookie to
recover the session context. Stickiness is defined at a target group level.

Health Checks
An Application Load Balancer routes traffic only to healthy targets. With an Application Load
Balancer, you get improved insight into the health of your applications in two ways: (1)
health check improvements that allow you to configure detailed error codes from 200-499.
The health checks allow you to monitor the health of each of your services behind the load
balancer; and (2) new metrics that give insight into traffic for each of the services running on
an EC2 instance.

Operational Monitoring
Amazon CloudWatch reports Application Load Balancer metrics such as request counts, error
counts, error types, and request latency.

Logging
You can use the Access Logs feature to record all requests sent to your load balancer, and
store the logs in Amazon S3 for later analysis. The logs are compressed and have a gzip file
extension. The compressed logs save both storage space and transfer bandwidth and are
useful for diagnosing application failures and analyzing web traffic.
Reference from AWS Documentation
Web Application Firewall
You can now use AWS WAF to protect your web applications on your Application Load Balancers. AWS
WAF is a web application firewall that helps protect your web applications from common web exploits
that could affect application availability, compromise security, or consume excessive resources.

Slow Start Mode with Load-Balancing Algorithm

Application Load Balancer supports a round-robin load-balancing algorithm. Additionally, Application
Load Balancer supports a slow start mode with the round-robin algorithm that allows you to add new
targets without overwhelming them with a flood of requests. With the slow start mode, targets warm
up before accepting their fair share of requests based on a ramp-up period that you specify. Slow start
is very useful for applications that depend on cache and need a warm-up period before being able to
respond to requests with optimal performance.

User Authentication
You can offload the authentication functionality from your apps into Application Load Balancer.
Application Load Balancer will securely authenticate users as they access cloud applications.
Application Load Balancer is seamlessly integrated with Amazon Cognito, which allows end users to
authenticate through social identity providers such as Google, Facebook, and Amazon, and through
enterprise identity providers such as Microsoft Active Directory via SAML or any OpenID Connect-
compliant identity provider (IdP). If you already have a custom IdP solution that is OpenID Connect-
Reference from AWS Documentation
compatible, Application Load Balancer can also authenticate enterprise users by directly connecting
with your identity provider.
Network Load Balancer operates at the connection level (Layer 4),
routing connections to targets - Amazon EC2 instances,
microservices, and containers – within Amazon Virtual Private Cloud
(Amazon VPC) based on IP protocol data. Ideal for load balancing of
both TCP and UDP traffic, Network Load Balancer is capable of
handling millions of requests per second while maintaining ultra-
low latencies. Network Load Balancer is optimized to handle
sudden and volatile traffic patterns while using a single static IP
address per Availability Zone. It is integrated with other popular
AWS services such as Auto Scaling, Amazon EC2 Container Service
(ECS), Amazon CloudFormation and AWS Certificate Manager (ACM).

Reference from AWS Documentation

Key Features

Connection-based Load Balancing

You can load balance both TCP and UDP traffic, routing connections to
targets - Amazon EC2 instances, microservices, and containers.
High Availability
Network Load Balancer is highly available. It accepts incoming traffic
from clients and distributes this traffic across the targets within the same
Availability Zone. The load balancer also monitors the health of its
registered targets and ensures that it routes traffic only to healthy
targets. When the load balancer detects an unhealthy target, it stops
routing traffic to that target and reroutes traffic to remaining healthy
targets. If all of your targets in one Availability Zone are unhealthy, and
you have set up targets in another Availability Zone, Network Load
Balancer will automatically fail-over to route traffic to your healthy
targets in the other Availability Zones.

High Throughput
Network Load Balancer is designed to handle traffic as it grows and can
load balance millions of requests/sec. It can also handle sudden volatile
Reference from AWS Documentation

traffic patterns.
Low Latency
Network Load Balancer offers extremely low latencies for latency-sensitive
applications.

Preserve source IP address

Network Load Balancer preserves the client side source IP allowing the back-
end to see the IP address of the client. This can then be used by applications
for further processing.

Static IP support
Network Load Balancer automatically provides a static IP per Availability
Zone (subnet) that can be used by applications as the front-end IP of the
load balancer.

Elastic IP support
Network Load Balancer also allows you the option to assign an Elastic IP per
Availability Zone (subnet) thereby providing your own fixed IP.
Reference from AWS Documentation
Health Checks
Network Load Balancer supports both network and application target health checks.
Network-level health is based on the overall response of your target to normal traffic.
If the target becomes unable, or too slow, to respond to new connections then the load
balancer will mark the target as unavailable. Application-level health checks can also
be used to go deeper. By periodically probing a specific URL on a given target, it can
integrate the health of the actual application. For quick diagnosis and powerful
debugging, full visibility into health checks and why they may be failing is also
available through ‘reason codes’ in the Network Load Balancer API, and the Amazon
CloudWatch metrics attached to target health checks.

DNS Fail-over
If there are no healthy targets registered with the Network Load Balancer or if the
Network Load Balancer nodes in a given zone are unhealthy, then Amazon Route 53 will
direct traffic to load balancer nodes in other Availability Zones.

Integration with Amazon Route 53

In the event that your Network Load Balancer is unresponsive, integration with Route
53 will remove the unavailable load balancer IP address from service and direct traffic
toReference
an alternate Network Load Balancer in another region.
from AWS Documentation
Classic Load Balancer provides basic load balancing across multiple Amazon EC2 instances
and operates at both the request level and connection level. Classic Load Balancer is
intended for applications that were built within the EC2-Classic network. We recommend
Application Load Balancer for Layer 7 and Network Load Balancer for Layer 4 when using
Virtual Private Cloud (VPC).

Key Features
High Availability
You can distribute incoming traffic across your Amazon EC2 instances in a single Availability Zone or
multiple Availability Zones. Classic Load Balancer automatically scales its request handling capacity
in response to incoming application traffic.

Health Checks
Classic Load Balancer can detect the health of Amazon EC2 instances. When it detects unhealthy EC2
instances, it no longer routes traffic to those instances and spreads the load across the remaining
healthy instances.

Security Features
When using Amazon Virtual Private Cloud (Amazon VPC), you can create and manage security groups
Reference from AWS Documentation
associated with Classic Load Balancer to provide additional networking and security options. You can
also create a Classic Load Balancer without public IP addresses to serve as an internal (non-internet-
Reference from AWS Documentation
Pricing

https://aws.amazon.com/elasticloadbalancing/pricing/

Reference from AWS Documentation