AWS EC2 - ALB/NLB/GLB

发布时间 2023-05-10 01:40:48作者: apolloextra

 

Application Load Balancers can route traffic to different Target Groups based on the following
  Hostname
  Request URL Path
  Source IP Address

 

Network Load Balancer has one static IP address per AZ and you can attach an Elastic IP address to it.

Application Load Balancers and Classic Load Balancers as a static DNS name.

AWSALB      AWS ALB
AWSALBTG    AwS ALB Target Group
AWSALBAPP   AWS ALB Application

 

 

When Cross-Zone Load Balancing is enabled, ELB distributes traffic evenly across all registered EC2 instances in all AZs.

EC2 > Load balancers > DemoNLB > Edit load balancer attributes

Target selection configuration
Cross-zone load balancing: By default, each Network Load Balancer Elastic Network Interface (ENI) only distributes traffic across the registered targets in its Availability Zone. If you enable cross-zone load balancing, each load balancer node distributes traffic across the registered targets in all enabled Availability Zones.
Regional data transfer charges may apply when cross-zone load balancing is turned on.



Application Load Balancers Now Support Multiple TLS Certificates With Smart Selection Using SNI
Network     Load Balancers Now Support Multiple TLS Certificates using Server Name Indication (SNI)

SNI is integrated with AWS Certificate Manager (ACM) and AWS Identity and Access Management (IAM) for certificate management. You can associate up to 25 certificates to a load balancer in addition to a default certificate per listener.  


Server Name Indication (SNI) 是TLS协议(旧SSL协议)的扩展,该协议在HTTPS中使用。它包含在TLS/SSL握手流程中,以确保客户端设备能够看到他们尝试访问的网站的正确SSL证书。该扩展使得可以在TLS握手期间指定网站的主机名或域名 ,而不是在握手之后打开HTTP连接时指定。


With SNI support we’re making it easy to use more than one certificate with the same ALB. The most common reason you might want to use multiple certificates is to handle different domains with the same load balancer. It’s always been possible to use wildcard and subject-alternate-name (SAN) certificates with ALB, but these come with limitations. Wildcard certificates only work for related subdomains that match a simple pattern and while SAN certificates can support many different domains, the same certificate authority has to authenticate each one. That means you have reauthenticate and reprovision your certificate everytime you add a new domain.
借助 SNI 支持,我们可以轻松地使用具有相同 ALB 的多个证书。您可能希望使用多个证书的最常见原因是使用相同的负载均衡器处理不同的域。始终可以将通配符和主题备用名称 (SAN) 证书与 ALB 一起使用,但这些证书都有限制。通配符证书仅适用于与简单模式匹配的相关子域,虽然 SAN 证书可以支持许多不同的域,但同一证书颁发机构必须对每个子域进行身份验证。这意味着每次添加新域时,您都必须重新进行身份验证并重新预配证书。

Smart Certificate Selection on ALB
ALB’s smart certificate selection goes beyond SNI. In addition to containing a list of valid domain names, certificates also describe the type of key exchange and cryptography that the server supports, as well as the signature algorithm (SHA2, SHA1, MD5) used to sign the certificate. To establish a TLS connection, a client starts a TLS handshake by sending a “ClientHello” message that outlines the capabilities of the client: the protocol versions, extensions, cipher suites, and compression methods. Based on what an individual client supports, ALB’s smart selection algorithm chooses a certificate for the connection and sends it to the client. ALB supports both the classic RSA algorithm and the newer, hipper, and faster Elliptic-curve based ECDSA algorithm. ECDSA support among clients isn’t as prevalent as SNI, but it is supported by all modern web browsers. Since it’s faster and requires less CPU, it can be particularly useful for ultra-low latency applications and for conserving the amount of battery used by mobile applications. Since ALB can see what each client supports from the TLS handshake, you can upload both RSA and ECDSA certificates for the same domains and ALB will automatically choose the best one for each client.
ALB的智能证书选择超越了SNI。除了包含有效域名的列表外,证书还描述了服务器支持的密钥交换和加密类型,以及用于签署证书的签名算法(SHA2、SHA1、MD5)。若要建立 TLS 连接,客户端通过发送概述客户端功能的“ClientHello”消息来启动 TLS 握手:协议版本、扩展、密码套件和压缩方法。根据单个客户端支持的内容,ALB的智能选择算法为连接选择一个证书并将其发送到客户端。ALB 既支持经典的 RSA 算法,也支持更新、更时髦、更快的基于椭圆曲线的 ECDSA 算法。客户端中的 ECDSA 支持并不像 SNI 那样普遍,但所有现代 Web 浏览器都支持它。由于它速度更快且需要更少的 CPU,因此对于超低延迟应用程序和节省移动应用程序使用的电池量特别有用。由于 ALB 可以从 TLS 握手中看到每个客户端支持的内容,因此您可以为相同的域上传 RSA 和 ECDSA 证书,ALB 将自动为每个客户端选择最佳证书。

 

Using SNI with ALB

 


 

How to Help Achieve Mobile App Transport Security (ATS) Compliance by Using Amazon CloudFront and AWS Certificate Manager

 

  1. ACM automates the creation and renewal of SSL/TLS certificates and deploys them to AWS resources such as CloudFront distributions and Elastic Load Balancing load balancers at your instruction.
  2. Users communicate with CloudFront over HTTPS. CloudFront terminates the SSL/TLS connection at the edge location.
  3. You can configure CloudFront to communicate to the origin over HTTP or HTTPS.

 

Server Name Indicator (SNI) on NLB Demo

    Server Name Indication (SNI) is an extension to the Transport Layer Security (TLS) computer networking protocol by which a client indicates which hostname it is attempting to connect to at the start of the handshaking process.
    You can verify that the name on the cert is the same as the site name, and the only cert served. Change hostname and you'll get a different cert. Hostnames other than www will use the wildcard cert, so you'll see an * as the hostname.
    This site is hosted behind an Network Load Balancer and is using Server Name Indication (SNI).
    This allows it to serve multiple, independent, TLS certificates based on the hostname indicated by clients.
    It's a few simple web pages hosted on servers in EC2 running Nginx behind and NLB. The real fun is nothing magical, just changing which certificate is provided based on what you try to connect to.
    NLB uses Smart Certificate Selection to choose the best certificate whenever there are multiple matches.
    The table below shows you the certificate used by this Network Load Balancer. Use the drop down menus below to explore links to different Fully Qualified Domain Names (FQDNs) that SNI is configured for on the Network Load Balancer. When you select a domain name, for example, "network.exampleloadbalancer.com", the Network Load Balancer selects the certificate of "network.exampleloadbalancer.com" for the TLS connection and present its certificate information in the table below.
The table below shows you the certificate used by this Network Load Balancer. Use the drop down menus below to explore links to different Fully Qualified Domain Names (FQDNs) that SNI is configured for on the Network Load Balancer. When you select a domain name, for example, "network.exampleloadbalancer.com", the Network Load Balancer selects the certificate of "network.exampleloadbalancer.com" for the TLS connection and present its certificate information in the table below.

 



You can configure the Auto Scaling Group to determine the EC2 instances' health based on Application Load Balancer Health Checks instead of EC2 Status Checks (default). When an EC2 instance fails the ALB Health Checks, its marked unhealthy and will be terminated while the ASG launches a new EC2 instance.

 


Your boss asked you to scale your Auto Scaling Group based on the number of requests per minute your application makes to your database. What should you do?
There's no CloudWatch Metric for "requests per minute" for backend-to-database connections. You need to create a CloudWatch Custom Metric, then create a CloudWatch Alarm.

 


 

For each Auto Scaling Group, there's a Cooldown Period after each scaling activity. In this period, the ASG doesn't launch or terminate EC2 instances. This gives time to metrics to stabilize. The default value for the Cooldown Period is 300 seconds (5 minutes).

scale in/down time slow -- Default cooldown -> it waits for 300 seconds before triggering the next check

Max Scale Time = Check Period + Cooldown Period

 

Set the health check grace period for an Auto Scaling group

 


 

An application is deployed with an Application Load Balancer and an Auto Scaling Group. Currently, you manually scale the ASG and you would like to define a Scaling Policy that will ensure the average number of connections to your EC2 instances is around 1000. Which Scaling Policy should you use?

 

Dynamic scaling policies
    Target tracking scaling
        Metric type -- Average CPU utilization
        Metric type -- Average network in (bytes)
        Metric type -- Average network out (bytes)
        Metric type -- Application Load Balancer request count per target
    Step scaling
        Take the action -- Add/Remove/Set to
    Simple scaling
        Take the action -- Add/Remove/Set to
Predictive scaling policies 
Scheduled actions