Tag: sla

Route 53 提供 100% SLA，而 Route 53 Resolver 提供 99.99% SLA

AWS 宣佈 Route 53 提供 100% 的 SLA，而 Route 53 Resolver 則提供 99.99% 的 SLA：「Amazon Route 53 Resolver Endpoints announces 99.99% Service Level Agreement and updates its Service Level Agreement for Route 53 hosted zones」。

Route 53 的部份指的是 hosted zone，參考「Amazon Route 53 Service Level Agreement」這邊，可以看到是 2022/08/29 更新的條款。

Route 53 Resolver 的部份可以參考「Amazon Route 53 Resolver Endpoints Service Level Agreement」這邊，也是 2022/08/29 更新的條款。

要注意 99.99% 是指 Multi-AZ Resolver Endpoints SLA；如果是 Single-AZ Resolver Endpoints SLA 看起來是設定在 99.5%。

不確定是不是 AWS 的第一個 100% SLA 條款...

Amazon RDS 推出了 Connection Pool 的產品

Amazon RDS 推出了 Connection Pool 的產品，叫做 Amazon RDS Proxy：「Introducing Amazon RDS Proxy (Preview)」。

目前支援 MySQL (包括了傳統的與 Aurora 版本的)：

Amazon RDS Proxy supports Amazon RDS for MySQL and Amazon Aurora with MySQL compatibility, with support for additional RDS database engines coming soon.

定價策略看起來是依照後端資料庫的 vCPU 計算：

Pricing is simple and predictable: you pay per vCPU of the database instance for which the proxy is enabled.

翻了一下價錢頁是 USD$0.015/vCPU (用 us-east-1 的資料)，而如果是 t2 系列的機器，最低是以 2 vCPUs 計算，不是照使用比例算：

RDS Proxy pricing correlates to the number of vCPUs of the database instance for which it is enabled, with a minimum charge for 2 vCPUs.

這樣一個 vCPU 一個月大約要 USD$21.6，算起來頗貴的... 如果 SLA 允許的話，用基本的方式 failover 也許就 ok 了...

如果 SLA 真的要追求到這麼高的話，可以在這些區域測試：

Amazon RDS Proxy is available in preview for RDS MySQL and Aurora MySQL in US East (N. Virginia), US East (Ohio), US West (Oregon), EU West (Ireland), and Asia Pacific (Tokyo) regions. Support for RDS PostgreSQL and Aurora PostgreSQL is coming soon.

Amazon S3 的 Replication 也給出 SLA 了

Amazon S3 的 cross-region replication 與 same-region replication 也提供 SLA 了：「S3 Replication Update: Replication SLA, Metrics, and Events」。

  • Most of the objects will be replicated within seconds.
  • 99% of the objects will be replicated within 5 minutes.
  • 99.99% of the objects will be replicated within 15 minutes.

對應的賠償是：

When you enable this feature, you benefit from the associated Service Level Agreement. The SLA is expressed in terms of a percentage of objects that are expected to be replicated within 15 minutes, and provides for billing credits if the SLA is not met:

  • 99.9% to 98.0% – 10% credit
  • 98.0% to 95.0% – 25% credit
  • 95% to 0% – 100% credit

不過只保證 99% 的物件在五分鐘內會被 replicate 有點低，應該跟底層的網路 latency 有關？

在 AWS 上用 pfSense 串接的細節

這邊講的是在 AWS 上想要串接不同帳號的流量 (也就是 site-to-site VPN)，不使用 AWS 自己提供的串接服務，而是用 pfSense 串接。

會自己搞主要有幾個考慮：

  • 考慮到 AWS Transit Gateway 的費用，每掛一個上去就要多收一次錢，另外上面處理的流量要再收費。
  • 應用的流量不大，所以用個 t2.nano 跑也有個 100Mbps 左右的 capacity，算是夠用了。
  • 而且應用在寫的時候也考慮到斷線後的處理，加上用戶端的網路本來就不怎麼穩定，AWS Transit Gateway 的 SLA 再怎麼高，我也還是得處理斷線時的後續機制，不如就不要那麼緊張...

在設定的時候要注意的事情：

  • EC2 的 Source IP/Destination IP 檢查要關掉，這算是基本盤。
  • VPC 內的 Routing 要確認過一輪。
  • EC2 上的 Security Group 對於 pfSense 的主機得全開，因為 pfSense 會丟出不屬於他自己 IP address 的封包，也會接收不屬於自己 IP address 的封包 (透過上面提到的 routing)，這些都還是會經過 Security Group 的檢查，而 Security Group 能設定的數量有限，基本上應該會全開...
  • pfSense 在設完 IPsec 後，同樣在 pfSense 上面的 firewall 需要手動加開，因為預設是關的。

其實這套作法就是在 AWS 還沒推出 Transit Gateway 前的作法，只是老方法還是很好用...

Braintree (PayPal) 用 PostgreSQL 的方式

RDBMS 最困難的事情都圍繞在「怎麼不中斷服務」(很多事情在不用考慮 uptime/downtime 的前提下很好做，不論是 ALTER 或是 failover，到備份還原計畫)，而 PayPal 的 Braintree 在「PostgreSQL at Scale: Database Schema Changes Without Downtime」這邊討論修改 PostgreSQL 的 database schema 時怎麼不中斷服務。

文章內的大部份都是給 DBA 知道的細節 (e.g. 怎麼樣才不會觸發大規模的 lock 導致服務中斷)，而不是開發者面向的事情... 但開頭的部份，也是我認為最重要的部份，則是需要 Developer 參與的：

For all code and database changes, we require that:

  • Live code and schemas be forward-compatible with updated code and schemas: this allows us to roll out deploys gradually across a fleet of application servers and database clusters.
  • New code and schemas be backward-compatible with live code and schemas: this allows us to roll back any change to the previous version in the event of unexpected errors.

為了符合這兩個要素，可能會在 schema 設計上有好幾個階段的操作，而非一次到位。而且也才能避免要關站從 backup 倒資料回來的情況...

建議可以研究看看要怎麼玩，常見的情境知道怎麼設計步驟後，真的遇到的時候會比較熟練。

AWS Lambda 也提供 SLA 了

在「AWS Lambda announces service level agreement」這邊看到 AWS Lambda 提供 99.95% 的 SLA ：

We have published a service level agreement (SLA) for AWS Lambda. We will use commercially reasonable efforts to make Lambda available with a Monthly Uptime Percentage for each AWS region, during any monthly billing cycle, of at least 99.95% (the “Service Commitment”).

不過這種東西都是宣示意味比較重 (至少表示 AWS 認為產品穩定度夠上 SLA)，倒不是希望會用到...

Amazon ECS 與 AWS Fargate 都納入 Amazon Compute SLA 計算

AWS 宣佈的這兩個服務 (Amazon ECS 與 AWS Fargate) 都納入 99.99% 的 SLA 合約範圍：「Amazon Compute Service Level Agreement Extended to Amazon ECS and AWS Fargate」。

Amazon Elastic Container Service (Amazon ECS) and AWS Fargate are now included in the Amazon Compute Service Level Agreement (SLA) for 99.99% uptime and availability.

ECS 已經跑一陣子了可以理解，但 Fargate 的概念算比較新，剛出來沒多久就決定放進去比較意外...

AWS 主動提高 Amazon EC2 與 Amazon EBS 的 SLA

AWS 主動提高 Amazon EC2 與 Amazon EBS 的 SLA：「Announcing an increased monthly service commitment for Amazon EC2」。

Amazon EC2 is announcing an increase to the monthly service commitment in the EC2 Service Level Agreement (“SLA”), for both EC2 and EBS, to 99.99%. This increased commitment is the result of continuous investment in our infrastructure and quality of service. This change is effective immediately in all regions, and is available to all EC2 customers.

之前是 99.95% monthly (參考前幾天的頁面：「Amazon EC2 SLA」)，現在拉到 99.99% 了。第一階的賠償條件也從 99.95%～99% 改成 99.99%～99% 了 (賠 10%)。

Amazon 詳細說明 AWS EBS/RDS 故障的原因...

Amazon 在網頁上說明了在 4/21 美東地區 EBS/RDS 故障的原因：「Summary of the Amazon EC2 and Amazon RDS Service Disruption in the US East Region」。

整篇文章相當長，但整個連鎖反應是起於操作時的人為疏失。而 RDS 因為是基於 EBS 上，所以也跟著大爆炸...

另外文章最後面也提到賠償的方式：

For customers with an attached EBS volume or a running RDS database instance in the affected Availability Zone in the US East Region at the time of the disruption, regardless of whether their resources and application were impacted or not, we are going to provide a 10 day credit equal to 100% of their usage of EBS Volumes, EC2 Instances and RDS database instances that were running in the affected Availability Zone.

另外，AWS 的 SLA 中有要求當未滿 SLA 條件時，必須由使用者提出退款要求，但這次則是例外，符合條件的會主動在下次的帳單上，或是系統的頁面上看到：

These customers will not have to do anything in order to receive this credit, as it will be automatically applied to their next AWS bill. Customers can see whether they qualify for the service credit by logging into their AWS Account Activity page.

Google Apps 的 Uptime 計算方式調整 (對使用者有利的方向)

Google 改變了 Google Apps 對 Uptime 的計算方式：「Google Apps Removes Scheduled Downtime Clause From SLA; Gmail Had 99% Uptime in 2010」(TC)、「Destination: Dial Tone -- Getting Google Apps to 99.99%」(Google 官方新聞稿)。

之前的條款內允許 Google 將「排定的維護停機」排除在 downtime 計算外，現在 Google 決定拿掉這條例外條款。然後在文章下面故意提到 Microsoft 的服務：

Comparable data for Microsoft BPOS® is unavailable, though their service notifications show 113 incidents in 2010: 74 unplanned outages, and 33 days with planned downtime.

有興趣看新版 SLA 的人可以連結到英文版的頁面上：「Google Apps Service Level Agreement」。