- https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html
- A load balancer serves as the single point of contact for clients. The load balancer distributes incoming application traffic across multiple targets, such as EC2 instances, in multiple Availability Zones. This increases the availability of your application. You add one or more listeners to your load balancer
- Functions on Layer 7
- Supports HTTP, HHTPS, HTTP/2, WebSockets
- Able to load balance across applications – target groups – groups of EC2’s/ECS/client-on-premise-IP’s, each group running a specific application. ALB references the groups by IP’s/ports, not by EC2 names.
- There is no one-to-one mapping between front end and back end listeners. A single front end listener can route to one of many destinations based on a rule
- ALB Rules define how and where the requests are to be sent. Can have up to 100 rules
- Supports HTTP, HHTPS, HTTP/2, WebSockets
- Able to load balance across applications – target groups – groups of EC2’s/ECS/client-on-premise-IP’s, each group running a specific application. ALB references the groups by IP’s/ports, not by EC2 names.
- There is no one-to-one mapping between front end and back end listeners. A single front end listener can route to one of many destinations based on a rule
- ALB Rules define how and where the requests are to be sent. Can have up to 100 rules
- Receives connections request from clients, forwards onto target groups
- Content-based load balancing
- HTTP/HTTPS, 1-65535
Target Group
- REGIONAL
- A group can be associated with only one load balance
- A single target can be member of multiple Target Groups
- A group is specified by a one protocol and one port
§ The port that will receive the traffic can be overridden on each
registered target in a group if needed
-
Health Check done on each
Target GroupTargets
- Endpoints registered with a group
§ EC22 instance
§ Microservice
§ ECS container
§ IP address
§ Lambda function (limit of one per group)
- Can’t have a destination with a public IP as a target
- Can register came EC2 with the same group multiple times – using sperate ports
- Up to a 1000 targets per group
- When addressing by IP, the target can be:
§ An IP in a peered VPC
§ AWS destination with an IP (ex: database)
§ On-premise destination connected via Direct Connect or VPN
- Endpoints registered with a group
§ EC22 instance
§ Microservice
§ ECS container
§ IP address
§ Lambda function (limit of one per group)
- Can’t have a destination with a public IP as a target
- Can register came EC2 with the same group multiple times – using sperate ports
- Up to a 1000 targets per group
- When addressing by IP, the target can be:
§ An IP in a peered VPC
§ AWS destination with an IP (ex: database)
§ On-premise destination connected via Direct Connect or VPN
Rules
- Connects listeners and target groups
- Defined on listeners – can have up to 100
§ Condition
§ Target group
§ Action
§ Priority
- Rules have priority, small to large; default rule is last – non removable
- Once a rule is met, target from the determined group is selected using round robin
- Content-based routing – can define rules that route based on a condition
- A rule can optionally have 1 path condition and 1 host condition
- Host-based (domain-based) routing – route to a group based on the Domain value and optionally the Port number in the HTTP header. This allows routing to multiple domains from one load balancer
- Path-based routing – routing based on the path in the domain name. Ex: myhost.com/videos sent to one group and myhost.com/pictures to another. Can combine the two
Containers
- Microservices– app using series of services that can operate and be developed independently
- https://aws.amazon.com/premiumsupport/knowledge-center/dynamic-port-mapping-ecs/
- Dynamic container-to-host port mapping – the load balancer can see only the external port of the container application. There could be multiple containers run within the app though. ELS can atomically register each container with ALB taking care of the external-to-internal port mapping:
§ When Adding a container to a Task – specify the Host port of 0
§ The Host port gets automatically assigned from the ephemeral range
§ The task is registered, and load balanced by ALB as a combination of instance id and port for each container
- Connects listeners and target groups
- Defined on listeners – can have up to 100
§ Condition
§ Target group
§ Action
§ Priority
- Rules have priority, small to large; default rule is last – non removable
- Once a rule is met, target from the determined group is selected using round robin
- Content-based routing – can define rules that route based on a condition
- A rule can optionally have 1 path condition and 1 host condition
- Host-based (domain-based) routing – route to a group based on the Domain value and optionally the Port number in the HTTP header. This allows routing to multiple domains from one load balancer
- Path-based routing – routing based on the path in the domain name. Ex: myhost.com/videos sent to one group and myhost.com/pictures to another. Can combine the two
Containers
- Microservices– app using series of services that can operate and be developed independently
- https://aws.amazon.com/premiumsupport/knowledge-center/dynamic-port-mapping-ecs/
- Dynamic container-to-host port mapping – the load balancer can see only the external port of the container application. There could be multiple containers run within the app though. ELS can atomically register each container with ALB taking care of the external-to-internal port mapping:
§ When Adding a container to a Task – specify the Host port of 0
§ The Host port gets automatically assigned from the ephemeral range
§ The task is registered, and load balanced by ALB as a combination of instance id and port for each container
§ This allows running multiple
tasks as a single same service on same EC2 on same port
- Microservices– app using series of services that can operate and be developed independently
- https://aws.amazon.com/premiumsupport/knowledge-center/dynamic-port-mapping-ecs/
- Dynamic container-to-host port mapping – the load balancer can see only the external port of the container application. There could be multiple containers run within the app though. ELS can atomically register each container with ALB taking care of the external-to-internal port mapping:
§ When Adding a container to a Task – specify the Host port of 0
§ The Host port gets automatically assigned from the ephemeral range
§ The task is registered, and load balanced by ALB as a combination of instance id and port for each container.
§ This allows running multiple tasks as a single same service on same EC2 on same port
§ Source: https://medium.com/faun/understanding-d ynamic-port-mapping-in-amazon-ecs-with-application-load-balancer-bf705ee0ca8e
ALB vs CLB
Both:
- Cross-zone load balancing enabled by default – load balancing across zones w different number of targets distributing load to each target equally. When ALB is enabled in an AZ – it creates a load-balancing node in that AZ; without such node, the balancing is in home AZ only
ALB supports (in comparison to
CLB):
- WebSockets (duplex – two-way communication b/w client and server)
- HTTP/2 (sending multiple, up to 128, requests at same time)
o LB treats each request as HTTP/1.1 and round-robins across the target group
- Enhanced health checks and cloud watch metrics
- additional info in access logs plus allows for detailed error codes
- WAF
- External – Ipv4 and DualStack; internal IPv4
- IP - Can access targets by IP addresses
- SSL/TLS certificate - each target application can give its own SSL/TLS certificate – all served by the same ALB
- ACM - Integrates with AWS ACM – certificate manager
- Connection timeout – 60 sec default. Keep connection alive for XXX sec since the last message is received. Used mainly for front-end connections
- Keep-alive – recommended for back end connections
- Deregistration delay – connection draining. Wait for in-flight messages to be processed and send no more. 300 sec default. Up to 1 hour – 3600 sec.
- Sticky sessions – support only for ALB generated cookies (not client’s) – encrypted and non-modifiable
- WebsSocket connections are all sticky only during the handshake
- Fail Open – if none of the availably zones respond with a healthy target, send client requests to ALL hoping one would pick it up and process
- Health Reason Codes – if a target is unhealthy, a descriptive reason code is returned
- AutoScaling – can auto-scale on the target group level, but only when targets are EC2 and not IPs.
CLB supports (in comparison to ALB):
- Back end server authentication – authentication of instances w their own specific keys. ALB authenticates only when the instance’s public key presented to the load balancer matches the requester’s presented key
- EC2 classic
Monitoring
- CloudWatch – ALB sends metrics to every 60 sec, but only when these exist (ex: traffic flows, etc.)
- Request Tracing - You can use request tracing to track HTTP requests from clients to targets or other services. When the load balancer receives a request from a client, it adds or updates the X-Amzn-Trace-Id header before sending the request to the target (https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-request-tracing.html)
- CloudTrail – API call logs delivered to S3; no cost for the service – S3 fees only
- Access Logs – captures requests from clients: time, requester IP, latency, etc.
§ Log files stored in S3 compressed – if viewing from within AWS, AWS will uncompressed for you; outside applications will need to preform uncompressing
§ Pay for S3 storage only; not for transfer to S3
§ IMPORTANT: logs are best-effort; can me missing messages – not to be used for accounting purposes
Both:
- Cross-zone load balancing enabled by default – load balancing across zones w different number of targets distributing load to each target equally. When ALB is enabled in an AZ – it creates a load-balancing node in that AZ; without such node, the balancing is in home AZ only
- WebSockets (duplex – two-way communication b/w client and server)
- HTTP/2 (sending multiple, up to 128, requests at same time)
o LB treats each request as HTTP/1.1 and round-robins across the target group
- Enhanced health checks and cloud watch metrics
- additional info in access logs plus allows for detailed error codes
- WAF
- External – Ipv4 and DualStack; internal IPv4
- IP - Can access targets by IP addresses
- SSL/TLS certificate - each target application can give its own SSL/TLS certificate – all served by the same ALB
- ACM - Integrates with AWS ACM – certificate manager
- Connection timeout – 60 sec default. Keep connection alive for XXX sec since the last message is received. Used mainly for front-end connections
- Keep-alive – recommended for back end connections
- Deregistration delay – connection draining. Wait for in-flight messages to be processed and send no more. 300 sec default. Up to 1 hour – 3600 sec.
- Sticky sessions – support only for ALB generated cookies (not client’s) – encrypted and non-modifiable
- WebsSocket connections are all sticky only during the handshake
- Fail Open – if none of the availably zones respond with a healthy target, send client requests to ALL hoping one would pick it up and process
- Health Reason Codes – if a target is unhealthy, a descriptive reason code is returned
- AutoScaling – can auto-scale on the target group level, but only when targets are EC2 and not IPs.
CLB supports (in comparison to ALB):
- Back end server authentication – authentication of instances w their own specific keys. ALB authenticates only when the instance’s public key presented to the load balancer matches the requester’s presented key
- EC2 classic
Monitoring
- CloudWatch – ALB sends metrics to every 60 sec, but only when these exist (ex: traffic flows, etc.)
- Request Tracing - You can use request tracing to track HTTP requests from clients to targets or other services. When the load balancer receives a request from a client, it adds or updates the X-Amzn-Trace-Id header before sending the request to the target (https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-request-tracing.html)
- CloudTrail – API call logs delivered to S3; no cost for the service – S3 fees only
- Access Logs – captures requests from clients: time, requester IP, latency, etc.
§ Log files stored in S3 compressed – if viewing from within AWS, AWS will uncompressed for you; outside applications will need to preform uncompressing
§ Pay for S3 storage only; not for transfer to S3
§ IMPORTANT: logs are best-effort; can me missing messages – not to be used for accounting purposes
-
Can report health on the target
group level
No comments:
Post a Comment