幹壞事是進步最大的原動力
AWS 的 ALB 宣佈支援 TLS 1.3：「Application Load Balancer now supports TLS 1.3」。
本來以為早就支援了，翻了一下發現應該是太多產品線的關係搞混了：
ALB 則是到了 2023 才支援 TLS 1.3...
又是一個以為很久前就已經支援，但實際上沒支援的功能...
ALB 支援使用 cookie 實現 sticky session 功能：「Application Load Balancer now supports Application Cookie Stickiness」。
使用者的 session 通常會使用 cookie 記錄，而如果有多台 server 提供服務時，session 裡的資訊就需要找一個 shared session storage 放，以確保使用者在連到不同的 server 時都還是可以讀到對應的 session，比較傳統的方案就是直接把 session 塞進資料庫，後來發展出 memcached 或是 Redis 可以用。
但有些買來的軟體並沒有考慮到這點 (常常都是內部系統)，導致前面放 load balancer 時，必須想個辦法記錄使用者使用後端的哪台機器，這樣就可以在後端不支援 shared session storage 的情況下，還是可以讓應用正常運作。
透過 cookie 實做的 sticky session 算是蠻常見的作法，只是以為早就有了...
AWS 的 ALB 總算提供「最少連線數」的功能了：「Application Load Balancer now supports Least Outstanding Requests algorithm for load balancing requests」。
先前只有 Round robin (RR)，現在支援 Least outstanding requests (LOR) 後可以往比較少的塞了，這個方法在大多數的應用上比 RR 合理多了，現有的 ALB 應該都可以考慮換過去...
補功能不算快，但有種已知用火的感覺 XD
AWS 這次對 Lambda 還發表了不少功能，除了前面提到透過 Layout 支援其他語言以外 (e.g. Ruby)，這邊要再提到另外一個重要的功能。
這次是 ALB 可以直接呼叫 lambda function 了：「Lambda functions as targets for Application Load Balancers」。
以前還得靠 API Gateway 整半天 (因為版本設定)，現在直接用 ALB 接就可以了？而且 ALB 這邊有規劃對應的 quota：
There is no change to the hourly price of ALB. The load balancer capacity units (LCUs) of ALB now include 0.4 GB per hour of data processing to AWS Lambda targets.
這樣就更接近 serverless 了...
這個功能在 ELB Classic 年代時有跟 AWS 提過，到 ALB 支援了 (總算...)：「Application Load Balancer Announces Slow Start Support for its Load Balancing Algorithm」。
Application Load Balancers now support a slow start mode 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.
然後時間可以設定，從 30 秒到 15 分鐘：
Slow start mode can be enabled by target group and can be configured for a duration of 30 seconds to 15 minutes. The load balancer linearly increases the number of requests sent to a new target in a target group up to its fair share during the slow start ramp-up window.
就之前的經驗來說，這在跑 PHP 的時候會很需要這個功能 (之前是在 F5 的設備上設定)。其他的語言因為性質不太一樣，可能不會這麼吃這個功能。
主要是因為 PHP 是在 request 進來時 compile 並且 cache。所以在機器剛起來時，儘量將 CPU 留給 opcache，把常用的頁面 compile 完並且放進 cache，而不是讓大量的連線灌進來，這樣對使用體驗不會太好... (要避免 CPU 吃滿 100% 很久，造成每個連線都很慢才跑完)
AWS 推出 Slow Start 後對 auto scaling 時的順暢度會好不少...
AWS 應該是希望大家趕快把能換的 ELB 都換成新的 ALB 與 NLB，所以推出這個功能：「New One-step Migration Wizard to Migrate a Classic Load Balancer」。
Today, AWS announced the ability to migrate from a Classic Load Balancer to an Application Load Balancer or a Network Load Balancer in one step using a console-based migration wizard.
不過 ELB 有一些功能是目前 ALB 與 NLB 沒有的，像是一般性的 SSL offload (而非 HTTPS offload)，以及舊客戶會有的 EC2-Classic：
不知道這兩個問題之後會推出什麼樣的方案解決...
AWS 宣佈 ALB 支援 SNI 了：「Application Load Balancers Now Support Multiple TLS Certificates With Smart Selection Using SNI」。
不過這篇比較有趣的是，他範例用的是 VimIsBetterThanEmacs.com 與 VimIsTheBest.com 這兩個網域名稱 XDDD：
I’ll use a few example websites like VimIsBetterThanEmacs.com and VimIsTheBest.com. I’ve purchased and hosted these domains on Amazon Route 53, and provisioned two separate certificates for them in AWS Certificate Manager (ACM). If I want to securely serve both of these sites through a single ALB, I can quickly add both certificates in the console.
月初的時候 AWS ALB 支援 IP address 當後端 (AWS ALB 可以設定 IP address 當作後端伺服器了)，然後推出 AWS NLB (AWS 推出新的 Load Balancer：NLB (Network Load Balancer))，然後這個功能也被做到 NLB 上了：「Elastic Load Balancing: Network Load Balancer now supports load balancing to IP addresses as targets for AWS and on-premises resources」。
就如同說明的，這樣可以透過 VPN 架構 (無論是 AWS Direct Connect 或是一般的 IPsec VPN) 共用機房與雲端上的資源：
We are pleased to announce that Network Load Balancers can now distribute traffic to AWS resources using their IP addresses as targets in addition to the instance IDs. You can now also load balance to resources in on-premises locations reachable over AWS Direct Connect and resources in EC2-Classic. Load balancing across AWS and on-premises resources using the same load balancer makes it easy for you to migrate-to-cloud, burst-to-cloud, or failover-to-cloud.
除了中國區以外的 region 都可以用這個功能了：
Load balancing using IP addresses is available today for existing and new Network Load Balancers in all public AWS regions except the China (Beijing) region. You can get started using the AWS Management Console, AWS Command Line Interface (CLI), or AWS SDK.
AWS ALB 推出直接設定 IP address 當作後端伺服器的功能：「New – Application Load Balancing via IP Address to AWS & On-Premises Resources」。
ip – Targets are registered as IP addresses. You can use any IPv4 address from the load balancer’s VPC CIDR for targets within load balancer’s VPC and any IPv4 address from the RFC 1918 ranges (10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16) or the RFC 6598 range (100.64.0.0/10) for targets located outside the load balancer’s VPC (this includes Peered VPC, EC2-Classic, and on-premises targets reachable over Direct Connect or VPN).
這樣就能拿 ALB 當 load balancer 把部份內容接到自己機房內的伺服器群了，一種隨便串的概念... (可以透過 AWS Direct Connect 或是 VPN 直接串，所以對外的部份就直接是 AWS 端，對內要怎麼接就隨便接...)
看到 CodeDeploy 跟 ELB/ALB 整合的消息：「AWS CodeDeploy now integrates with Elastic Load Balancer」。
不過看同事在「AWS 替 CodeDeploy 加入 Load balancer 的功能」這邊提到的效能問題，看起來頗慘...
至少是個整合後的方法... 也許之後會改善吧。