Amazon Aurora 常見問答集

Amazon Aurora 是一種現代化關聯式資料庫服務，可大規模提供效能和高可用性、完全開放原始碼 MySQL (和 PostgreSQL) 相容版本，以及一系列用於建置無伺服器和機器學習 (ML) 驅動型應用程式的開發人員工具。

Aurora 具有分散式、容錯和自我修復的儲存系統，該系統與運算資源分離並將每個資料庫執行個體自動擴展至 128 TiB。它提供高效能和可用性，以及高達 15 個低延遲僅供讀取複本、時間點復原、持續備份至 Amazon Simple Storage Service (Amazon S3)，還可以跨三個可用區域 (AZ) 複寫。

Aurora 也是一項全受管服務，可自動執行硬體佈建、資料庫設定、修補和備份等耗時的管理任務，同時以十分之一的成本提供商業資料庫的安全性、可用性和可靠性。

Amazon Aurora 與現有的 MySQL 開源資料庫直接相容，並定期新增對新版本的支援。這意味著您可以使用標準匯入/匯出工具或快照輕鬆地將 MySQL 資料庫遷移至 Aurora 或從 Aurora 遷移。它還意味著您目前在 MySQL 資料庫使用的大部分程式碼、應用程式、驅動程式和工具只需進行少量變更或不需變更，即可與 Aurora 搭配使用。這使得在兩個引擎之間移動應用程式變得很容易。

您可以在文件中查看當前 Amazon Aurora 與 MySQL 版本的相容性資訊。

Amazon Aurora 與現有的 PostgreSQL 開源資料庫直接相容，並定期新增對新版本的支援。這意味著您可以使用標準匯入/匯出工具或快照輕鬆地將 PostgreSQL 資料庫遷移至 Aurora 或從 Aurora 遷移。它還意味著您目前在 PostgreSQL 資料庫使用的大部分程式碼、應用程式、驅動程式和工具只需進行少量變更或不需變更，即可與 Aurora 搭配使用。

您可以在文件中查看當前 Amazon Aurora 與 PostgreSQL 版本的相容性資訊。

Amazon 全力支援 Aurora PostgreSQL 以及 Aurora 可用的所有擴充功能。如果您需要 Aurora PostgreSQL 的支援，請聯絡 AWS Support。如果您擁有有效的 AWS Premium Support 帳戶，可以聯絡 AWS Premium Support 解決 Aurora 的特定問題。

若要試用 Aurora，請登入 AWS 管理主控台，選取資料庫類別下的 RDS，然後選擇 Amazon Aurora 作為您的資料庫引擎。如需詳細指導和資源，請查看我們的 Aurora 入門頁面。

您可以在此處查看 Aurora 的區域可用性。

如果您想從 MySQL 遷移到 Aurora 或反向遷移，則有幾種選擇：

• 您可以使用標準的 mysqldump 公用程式將資料從 MySQL 中匯出，並用 mysqlimport 公用程式將資料匯入 Aurora，或者反向遷移。
• 您還可以使用 Amazon RDS 資料庫快照遷移功能，透過 AWS 管理主控台將 Amazon RDS for MySQL 資料庫快照遷移至 Aurora。

雖然持續時間取決於格式和資料集大小，但大多數客戶可以在一小時內完成到 Aurora 的遷移。如需詳細資訊，請參閱將 MySQL 資料庫遷移至 Amazon Aurora 的最佳實務。

如果您想從 PostgreSQL 遷移到 Aurora 或反向遷移，則有幾種選擇：

• 您可以使用標準 pg_dump 公用程式將資料從 PostgreSQL 匯出，以及使用 pg_restore 公用程式將資料匯入 Aurora，或者反向遷移。
• 您還可以使用 RDS 資料庫快照遷移功能，透過 AWS 管理主控台將 Amazon RDS for PostgreSQL 資料庫快照遷移至 Aurora。

雖然持續時間取決於格式和資料集大小，但大多數客戶可以在一小時內完成到 Aurora 的遷移。

若要將 SQL Server 資料庫遷移至 Amazon Aurora PostgreSQL 相容版本，您可以使用 Babelfish for Aurora PostgreSQL。您的應用程式無需任何變更即可執行。如需詳細資訊，請參閱 Babelfish 文件。

不需要，Aurora 可與標準的 PostgreSQL 資料庫驅動程式搭配使用。

Amazon Aurora 透過將資料庫引擎與為資料庫工作負載建構的 SSD 虛擬化儲存層緊密整合、減少儲存系統的寫入操作、大幅降低鎖定爭用並消除資料庫處理執行緒所產生的延遲，使效能大幅超越 MySQL。

我們使用 SysBench 測試 r3.8xlarge 執行個體的結果顯示，Amazon Aurora 每秒傳送超過 500,000 個 SELECT 和 100,000 個 UPDATE，比在同一硬體上執行同一基準的 MySQL 高出五倍。如需此基準及如何自行複製此基準的詳細說明，請參閱 Amazon Aurora MySQL 相容版本效能基準指南。

Amazon Aurora 透過將資料庫引擎與為資料庫工作負載建構的 SSD 虛擬化儲存層緊密整合、減少儲存系統的寫入操作、大幅降低鎖定爭用並消除資料庫處理執行緒所產生的延遲，使效能大幅超越 PostgreSQL。

我們使用 SysBench 測試 r4.16xlarge 執行個體的結果顯示，Amazon Aurora 每秒傳送的 SELECT 和 UPDATE 比在同一硬體上執行同一基準的 PostgreSQL 高出三倍。如需此基準及如何自行複製此基準的詳細說明，請參閱 Amazon Aurora PostgreSQL 相容版本效能基準指南。

Amazon Aurora 的設計與 MySQL 相容，因此現有 MySQL 應用程式和工具無須修改即可執行。不過，Amazon Aurora 針對 MySQL 加強了一個區域，那就是高度並行工作負載。若要最大化 Amazon Aurora 上的工作負載輸送量，建議您將應用程式建置為可驅動大量並行查詢和交易。

Amazon Aurora 的設計與 PostgreSQL 相容，因此現有的 PostgreSQL 應用程式和工具無須修改即可執行。不過，Amazon Aurora 針對 PostgreSQL 加強了一個區域，那就是高度並行工作負載。若要最大化 Amazon Aurora 上的工作負載輸送量，建議您將應用程式建置為可驅動大量並行查詢和交易。

請參閱 Aurora 定價頁面了解最新的定價資訊。

目前沒有適用於 Aurora 的 AWS 免費方案產品。不過，Aurora 會將您的資料持久儲存在一個區域中的三個可用區域，而且只需支付一份資料副本的費用。您不需要支付高達 100% 資料庫叢集大小的備份費用。在為資料庫叢集設定的備份保留期間，您也無需支付快照費用。

不是，Aurora 複寫的價格已捆綁在定價中。我們將根據資料庫在資料庫層消耗的儲存量向您收費，而非根據在 Aurora 虛擬儲存層消耗的儲存量收費。

I/O 操作由 Aurora 資料庫引擎在其 SSD 虛擬儲存層中執行。每個資料庫頁面讀取操作視為一個輸入/輸出。
Aurora 資料庫引擎發出讀取儲存層請求，以擷取不在快取記憶體中的資料庫頁面：

• 如果您的查詢流量能完全以記憶體或快取滿足，不會因您自記憶體擷取任何資料頁面而收費。
• 如果您的查詢流量無法完全以記憶體滿足，會按照需要自儲存區擷取的資料頁面向您收費。
  每個資料庫頁面在 Amazon Aurora MySQL 相容版本中為 16 KB，在 Aurora PostgreSQL 相容版本中為 8 KB。

Aurora 的設計目的是為了移除不必要的 I/O 操作，以降低成本及確保有足夠的資源可供讀取/寫入流量使用。會消耗寫入 I/O 操作的情形僅限於為使寫入耐久，Aurora MySQL 相容版本中對儲存層的持續重做日誌記錄或 Aurora PostgreSQL 相容版本中對儲存層的預寫日誌記錄。

寫入 I/O 操作以 4KB 為單位計算。例如，1024 位元組的日誌記錄當作一個寫入 I/O 操作計算。然而，如果日誌記錄大於 4KB，需要不只一次寫入 I/O 操作方能持久。

日誌記錄小於 4KB 的並行寫入操作可透過 Aurora 資料庫引擎併在一起，以最佳化 I/O 耗用量。有別於傳統資料庫引擎，Aurora 從不將已變更的資料頁面排清至儲存區。

您可以在 AWS 管理主控台查看 Aurora 執行個體耗用的輸入/輸出請求 數。若要了解輸入/輸出的耗用量，前往主控台的 Amazon RDS 區段，查看執行個體清單，選取 Aurora 執行個體，然後在監控區段尋找 “VolumeReadIOPs” 和 “VolumeWriteIOPs” 指標。

如需 I/O 操作定價的詳細資訊，請造訪 Aurora 定價頁面。將資料庫叢集設定為 Aurora 標準組態時，需支付讀取和寫入 I/O 操作的費用。將資料庫叢集設定為 Amazon Aurora I/O 最佳化時，不需支付讀取和寫入 I/O 操作的費用。

Aurora 依據您的價格效能比和價格可預測性需求，讓您在兩種組態選項之間進行選擇，從而提供最佳化資料庫支出的彈性。這兩種組態選項是「Aurora 標準」和「Aurora I/O 最佳化」。這兩種選項都不需要預先佈建 I/O 或儲存，而且兩者都可以擴展 I/O 操作來支援最嚴苛的應用程式。

Aurora 標準是一種資料庫叢集組態，可為絕大多數低至適中 I/O 用量的應用程式提供具成本效益的定價。使用 Aurora 標準，您可以支付資料庫執行個體、儲存和按請求付費 I/O 的費用。

Aurora I/O 最佳化是一種資料庫叢集組態，可為支付處理系統、電子商務系統和財務應用程式等 I/O 密集型應用程式提供改善的價格效能比。此外，如果您的 I/O 支出超過 Aurora 資料庫總支出的 25%，則可以使用 Aurora I/O 最佳化來節省高達 40% 的 I/O 密集型工作負載成本。讀取和寫入 I/O 操作不收取費用，因此 Aurora I/O 最佳化為所有應用程式提供可預測的定價，這使其非常適合具有高 I/O 可變性的工作負載。

當您需要任何應用程式的可預測成本時，Aurora I/O 最佳化是理想的選擇。對於需要高寫入輸送量或執行處理大量資料的分析查詢，I/O 密集型應用程式可提供改善的價格效能比。針對 I/O 支出超過 Aurora 帳單 25% 的客戶，您可以使用 Aurora I/O 最佳化，對於 I/O 密集型工作負載可節省高達 40% 的成本。

可以使用 AWS 管理主控台提供的一鍵式體驗，將現有資料庫叢集的儲存類型變更為 Aurora I/O 最佳化。也可以叫用 AWS Command Line Interface (AWS CLI) 或 AWS 軟體開發套件來進行此變更。

可以每 30 天將現有的資料庫叢集切換至 Aurora I/O 最佳化一次。您可以隨時切換回 Aurora 標準。

是，Aurora I/O 最佳化適用於現有的 Aurora 預留執行個體。Aurora 會自動說明對於預留執行個體，Aurora 標準和 Aurora I/O 最佳化之間的價格差異。使用 Aurora I/O 最佳化的預留執行個體折扣，您可以節省更多的 I/O 支出。

使用 Aurora I/O 最佳化功能時，回溯、快照、匯出或持續備份的價格不會有任何變更。

是，將繼續收取跨區域複寫資料所需的 I/O 操作費用。Aurora I/O 優化不會收取讀取和寫入 I/O 操作的費用，這與資料複寫不同。

除了以 Intel 為基礎的 R6id 執行個體和以 Graviton 為基礎的 R6gd 執行個體的價格外，適用於 Aurora PostgreSQL 的 Amazon Aurora Optimized Reads 不會收取額外費用。如需詳細資訊，請瀏覽 Aurora 定價頁面。

最低儲存為 10 GB。根據您的資料庫使用量，您的 Amazon Aurora 儲存將以 10 GB 的增量自動增長到 128 TiB，而不會影響資料庫的效能。無需提前佈建儲存。

有兩種方法可以擴展與我的 Amazon Aurora 資料庫執行個體相關聯的運算資源 – 透過 Aurora Serverless 和透過手動調整。

您可以使用 Aurora Serverless (Amazon Aurora 的隨需自動擴展組態) 根據應用程式需求擴展資料庫運算資源。它可讓您在雲端執行資料庫，而不必擔心資料庫容量管理。您可以指定所需的資料庫容量範圍，並且您的資料庫將根據應用程式的需求進行擴展。詳情請參閱《Aurora Serverless 使用者指南》。

您還可以透過在 AWS 管理主控台中選取所需的資料庫執行個體類型來手動擴展與資料庫關聯的運算資源。您請求的變更將在您指定的維護時段內套用，或者您可以使用 "Apply Immediately" (立即應用) 旗標來立即變更資料庫執行個體類型。

在執行擴展操作期間，這兩個選項將會對可用性造成幾分鐘的影響。請注意，這也會同時套用任何其他待定系統變更。

Amazon Aurora 資料庫執行個體的持續自動備份會一直處於啟用的狀態。備份不會影響資料庫效能。

是，拍攝快照並不影響效能。請注意，從資料庫快照中恢復資料需要建立新的資料庫執行個體。

Amazon Aurora 會自動讓您的資料在一個區域內的三個可用區域 (AZ) 維持耐久，並自動嘗試在運作狀態良好的可用區域內恢復您的資料庫，不會遺失任何資料。在極少數的情況下，無法在 Amazon Aurora 儲存內找到您的資料，您可以從資料庫快照中進行恢復或對新執行個體執行 point-in-time 恢復操作。請注意，時間點還原操作的最近可還原時間最多為 5 分鐘之前。

您可以選擇在刪除資料庫執行個體時建立最終的資料庫快照。如果進行此操作，之後便可以使用此資料庫快照恢復已刪除的資料庫執行個體。刪除資料庫執行個體之後，Amazon Aurora 會保留這個使用者建立的最終資料庫快照與所有其他手動建立的資料庫快照。刪除資料庫執行個體後只會保留資料庫快照 (即，不會保留為 point-in-time 恢復建立的自動備份)。

是。Aurora 讓您能夠建立資料庫的快照，稍後您可用它來恢復資料庫。您可以與不同的 AWS 帳戶共享快照，收件人帳戶的擁有者可以使用您的快照來恢復包含您資料的資料庫。您甚至可以選擇讓快照成為公有，也就是說，任何人都可以恢復包含您 (公有) 資料的資料庫。

您可以使用這個功能，在各個具備不同 AWS 帳戶的環境 (生產、開發/測試、分段等) 之間共享資料，這個功能還能在個別帳戶保護所有資料備份的安全，以因應萬一出現主 AWS 帳戶被盜的情況。

在帳戶間共享快照不需付費。不過，可能需要支付快照本身的費用，以及從共享快照恢復任何資料庫的費用。進一步了解 Aurora 定價。

我們不支援自動共享資料庫快照。若要共享快照，您必須手動建立快照複本，然後共享複本。

您最多可以與 20 個 AWS 帳戶 ID 共享手動快照。如果想要與 20 個以上帳戶共享快照，可將快照當做公有共享，或聯絡支援以提高您的配額。

您可以在提供 Aurora 的各 AWS 區域共享 Aurora 快照。

否。只有與共享快照的帳戶位於同一個區域中的帳戶可以存取共享的 Aurora 快照。

是，您可以共享加密的 Aurora 快照。

Amazon Aurora 會將您的資料庫磁碟區自動分成 10 GB 的區段並分散在多個磁碟上。資料庫磁碟區的每個 10 GB 區塊都能在三個可用區域間以六種方法進行複寫。Amazon Aurora 的設計可完全透明化的處理最多兩個資料副本的損失，而不會影響資料庫寫入可用性；最多三個資料副本的損失，而不會影響資料庫讀取可用性。

Amazon Aurora 儲存還具有自我修復能力。可持續掃描資料區塊和磁碟有無錯誤並自動修復。

與其他資料庫不同的是，Amazon Aurora 在資料庫損毀之後不需重新執行最後一個資料庫檢查點 (通常為 5 分鐘) 的重做日誌，且不需要在資料庫運作之前確認已套用所有變更。在大多數情況下，這可將資料庫的重新啟動時間降低到 60 秒以下。

Amazon Aurora 將緩衝區快取從資料庫處理程序中移出，以便在重新啟動時立即使用。如此一來，您就不需要在重新匯入快取時限制存取，以避免發生暫時低壓。

Amazon Aurora MySQL 相容版本和 Amazon Aurora PostgreSQL 相容版本都支援 Amazon Aurora 複本，該複本與相同 AWS 區域中的主執行個體共享同一個基礎磁碟區。所有 Amazon Aurora 複本都可看見主執行個體做出的更新。

透過 Amazon Aurora MySQL 相容版本，您還可以根據 MySQL 的 binlog 複寫引擎建立跨區域 MySQL 僅供讀取複本。在 MySQL 僅供讀取複本中，主執行個體的資料會作為交易在您的複本上重新執行。對於大多數使用案例，包括讀取擴展和高可用性，我們建議使用 Amazon Aurora 複本。

您可以根據應用程式需求，靈活搭配這兩種複本類型：

除了上面列出的選項之外，還有另外兩個複寫選項。您可以使用 Amazon 全球資料庫，在不同區域的 Aurora 叢集之間進行更快的實體複寫。對於 Aurora 和非 Aurora MySQL 相容版本資料庫之間的複寫 (甚至在 AWS 之外)，您可以設定自己的自我管理 binlog 複寫。

是，您可以透過實體複寫或邏輯複寫來設定跨區域 Aurora 複本。實體複寫 (稱為 Amazon Aurora Global Database) 使用專用基礎設施，讓資料庫充分為您的應用程式提供服務，而且複寫到最多五個次要區域通常延遲時間不到一秒。它適用於 Aurora MySQL 相容版本和 Aurora PostgreSQL 相容版本。

針對低延遲全球讀取和災難復原，我們建議使用 Amazon Aurora Global Database。
Aurora 支援在各資料庫引擎進行原生邏輯複寫 (MySQL 和 PostgreSQL 的 binlog，以及 PostgreSQL 的複寫位置)，您可以複寫至 Aurora 和非 Aurora 資料庫，甚至跨區域複寫。

Aurora MySQL 相容版本也提供易於使用的邏輯跨區域讀取複本功能，支援最多五個次要 AWS 區域。其以單一緒行緒的 MySQL binlog 複寫為基礎，因此複寫延遲會受到特定所選區域之間網路通訊中的變更/套用速率和延遲的影響。

是，您可以在每一個跨區域叢集最多新增 15 個 Aurora 複本，這些複本會與跨區域複本共用相同的基礎儲存。跨區域複本做為叢集的主複本，而叢集上的 Aurora 複本一般會比主複本延遲數十毫秒。

是，您可以從 Amazon RDS 主控台將跨區域複本提升成新的主複本。至於邏輯 (binlog) 複寫，提升程序一般需要幾分鐘，取決於您的工作負載。一旦啟動提升程序，跨區域複寫將會停止。

利用 Amazon Aurora 全球資料庫，您可以在一分鐘內提升次要區域，以取得完整的讀/寫工作負載。

是。您可以在叢集中對每個執行個體指派提升優先順序方案。在主執行個體失敗時，Amazon RDS 會將具有最高優先順序的複本提升成主要執行個體。如果兩個或多個 Aurora 複本共享相同的優先級，則 Amazon RDS 會升級最大的複本。如果兩個或多個 Aurora 複本共享相同的優先級和大小，則 Amazon RDS 會在同一促銷方案中推廣任意複本。

如需容錯移轉邏輯的詳細資訊，請閱讀 Amazon Aurora 使用者指南。

是，您可以隨時修改執行個體的優先順序方案。只修改優先順序方案不會觸發容錯移轉。

您可以指派較低優先順序的方案給不想提升成主執行個體的複本。然而，如果叢集上較高優先順序複本出於某些原因而運作狀況不佳或無法使用，則 Amazon RDS 會提升較低優先順序的複本。

您可以新增 Amazon Aurora 複本。同一個 AWS 區域中的 Aurora 複本會與主執行個體共用相同的基礎儲存。任何 Aurora 複本都可在不損失任何資料的情況下提升為主執行個體，因此，可用於在主要資料庫執行個體故障時提高容錯能力。

若要提高資料庫可用性，只需在 3 個可用區域中的任何一個建立 1 到 15 個複本，Amazon RDS 將在發生資料庫執行中斷時將其納入容錯移轉主選擇中。如果希望資料庫跨越多個 AWS 區域，則可以使用 Amazon Aurora Global Database。這會複寫您的資料且不會影響資料庫效能，並從全區域故障提供災難復原。

Amazon Aurora 會自動處理容錯移轉，所以您的應用程式可以儘快恢復資料庫操作，而無須人為管理介入。

• 如果您在相同或不同可用區域中有一個 Aurora 複本，當容錯移轉時，Aurora 會翻轉資料庫執行個體的正規名稱記錄 (CNAME) 以指向執行狀態正常的複本，該複本會提升成新的主複本。容錯移轉從開始到結束通常可在 30 秒內完成。為改善彈性和更快進行容錯移轉，請考慮使用 Amazon RDS Proxy，該服務會自動連線至容錯移轉資料庫執行個體，同時保留應用程式連線。Proxy 可讓容錯移轉對您的應用程式而言是透明的，並減少多達 66% 的容錯移轉時間。
• 如果您執行的是 Aurora Serverless v1，且資料庫執行個體或可用區域無法使用，Aurora 會自動在不同的可用區域中重新建立資料庫執行個體。Aurora Serverless v2 的運作方式，與佈建的容錯移轉和其他高可用性功能相似。如需詳細資訊，請參閱 Aurora Serverless v2 和高可用性。 
• 如果您沒有 Aurora 複本 (即單一執行個體) 且未執行 Aurora Serverless，Aurora 會嘗試在與原始執行個體相同的可用區域中建立新的資料庫執行個體。已盡力進行這種原始執行個體的取代操作，但可能不成功，例如，在出現會廣泛影響可用區域的問題時。
  

您的應用程式應在連線中斷時重試資料庫連線。跨區域災難復原是一個手動程序，您可以在此提升次要區域，以取得讀/寫工作負載。

Amazon Aurora 會自動偵測主執行個體的問題並觸發容錯移轉。如果您使用的是叢集端點，您的讀取/寫入連線會自動重新導向至將提升成主執行個體的 Amazon Aurora 複本。

此外，Aurora 複本提供的讀取流量將短暫中斷。如果您使用叢集讀取者端點將讀取流量導向至 Aurora 複本，會將唯讀連線導向至新提升的 Aurora 複本，直至將舊的主節點復原為複本。

由於 Amazon Aurora 複本與相同 AWS 區域中的主執行個體共享同一個資料磁碟區，因此幾乎不會有複寫延遲的情況。據我們觀察，延遲時間一般為數十毫秒。

對於跨區域複寫，以二進位日誌為基礎的邏輯複寫延遲會因變更/應用率以及網路通訊而無限制延長延遲時間。然而，在一般條件下，一分鐘以內的複寫延遲很常見。使用 Amazon Aurora 全球資料庫實體複寫的跨區域複本，其一般延遲在一秒內。

是，您可以在 Aurora MySQL 相容版本執行個體和外部 MySQL 資料庫之間設定 binlog 複寫。另一個資料庫可以在 Amazon RDS 上執行，也可以作為 AWS 上的自我管理資料庫執行，也可以完全在 AWS 之外執行。

如果您正在執行 Aurora MySQL 相容版本 5.7，請考慮設定以 GTID 為基礎的 binlog 複寫。這將提供完整的一致性，因此即使在容錯移轉或停機後，您的複寫也不會錯過交易或產生衝突。

Amazon Aurora 全球資料庫是一項功能，可讓單一 Amazon Aurora 資料庫跨越多個 AWS 區域。它會複寫您的資料且不會影響資料庫效能，讓每個區域都有不到一秒一般延遲的快速本機讀取，並從全區域故障提供災難復原。在極少見的區域性降低或故障情況下，可以在不到 1 分鐘的時間內提升次要區域，使其能夠完整讀取/寫入。此功能適用於 Aurora MySQL 相容版本和 Aurora PostgreSQL 相容版本。

只要在 Amazon RDS 主控台按幾下，就能建立 Aurora 全球資料庫。或者，您可以使用 AWS 軟體開發套件 (SDK) 或 AWS Command-Line Interface (CLI)。您需要在 Amazon Aurora 全球資料庫中，為每個區域至少佈建一個執行個體。

您最多可以為 Amazon Aurora 全球資料庫建立五個二級區域。

是。如果您的目標是分析資料庫活動，請考慮改用 Aurora 進階稽核、一般日誌和慢速查詢日誌，以避免影響資料庫的效能。

否。如果您的主區域不可用，可以從 Amazon Aurora 全球資料庫手動移除次要區域，並提升該區域以取得完整讀取和寫入功能。您也需要將應用程式指向新提升的區域。

是，所有 Amazon Aurora 資料庫執行個體都必須在 VPC 中建立。透過 Amazon VPC，您可以定義一個與自己資料中心內執行的傳統網路非常相似的虛擬網路拓撲。這樣一來，您可以完全控制存取您的 Amazon Aurora 資料庫的人員。

是。Amazon Aurora 使用 SSL (AES-256) 保護資料庫執行個體和應用程式之間的連線安全。Amazon Aurora 可讓您使用透過 AWS Key Management Service (AWS KMS) 管理的金鑰加密資料庫。

在以 Amazon Aurora 加密執行的資料庫執行個體上，於基礎儲存中存放的靜態資料，以及其在同一個叢集中的自動備份、快照和複本都會加密。加密和解密的處理完全無縫。如需以 Amazon Aurora 使用 AWS KMS 的詳細資訊，請參閱 Amazon RDS 使用者指南。

目前不支援加密現有未加密的 Aurora 執行個體。若要在現有未加密的資料庫使用 Amazon Aurora 加密，請建立已啟用加密的新資料庫執行個體，再將資料移轉至其中。

您必須透過建立資料庫時輸入的資料庫連接埠存取 Aurora 資料庫。這可為您的資料安全性提供多一層保護。如需連線至 Amazon Aurora 資料庫的逐步說明，請參閱 Amazon Aurora Connectivity 指南。

是的，Aurora 的 MySQL 和 PostgreSQL 相容版本均符合 HIPAA 規範。您可以使用它們建立符合 HIPAA 規範的應用程式及存放醫療保健相關資訊，包括與 AWS 共同履行的商業夥伴合約 (BAA) 下的受保護醫療資訊 (PHI)。如果您已經和 AWS 簽訂 BAA，則您不需要執行進一步動作，就能透過 BAA 涵蓋的帳戶開始使用這些服務。如需有關使用 AWS 建置合規應用程式的詳細資訊，請參閱醫療保健供應商。

您目前可以在以下網頁找到 CVE 清單：Amazon Aurora 安全性更新。

Aurora 與 Amazon GuardDuty 整合，可協助您識別在 Aurora 資料庫中的資料所面臨的潛在威脅。「GuardDuty RDS 防護」可分析並監控您帳號中的登入活動和新設資料庫，並使用量身訂製的 ML 模型偵測 Aurora 資料庫中可疑的登入活動。如需詳細資訊，請參閱透過 GuardDuty RDS 防護監控威脅及 GuardDuty RDS 防護使用者指南。

Aurora Serverless 是 Amazon Aurora 的隨需、自動調整規模組態。 藉助 Aurora Serverless，您可以在雲端中執行資料庫，而無需管理資料庫容量。手動管理資料庫容量可能非常耗時，而且會導致資料庫資源的使用效率不佳。使用 Aurora Serverless，您可以建立資料庫、指定所需的資料庫容量範圍，然後連接應用程式。Aurora 會根據您的應用程式需求在指定的範圍內自動調整容量。

資料庫處於作用中狀態時使用的資料庫容量需按秒付費。進一步了解 Aurora Serverless，在 Amazon RDS 管理主控台中執行幾個步驟即可開始使用。

從開發、測試環境、網站和工作負載，以及具有不頻繁、間歇或不可預測工作負載的應用程式，到需要高度擴展、高可用性的要求最嚴苛的業務關鍵型應用程式，Aurora Serverless v2 支援各種類型的資料庫工作負載。它透過新增更多 CPU 和記憶體來進行適當擴展，而無需將資料庫容錯移轉至更大或更小的資料庫執行個體。因此，即使存在長時間執行的交易、資料表鎖定等，它也可以擴展。

此外，它還能以低至 0.5 個 Aurora 容量單位 (ACU) 的增量擴展資料庫容量，因此您的資料庫容量接近符合您的應用程式需求。

Aurora Serverless v1 為不頻繁、間歇或不可預測的工作負載提供了一種簡便、經濟高效的選擇。它會自動啟動、擴展運算容量以符合您的應用程式的用量，並在不使用時關閉。請瀏覽《Aurora 使用者指南》以進一步了解相關資訊。

Aurora Serverless v2 支援已佈建 Aurora 的所有功能，包括僅供讀取複本、異地同步備份組態、Aurora 全球資料庫、RDS Proxy 和 Performance Insights。

是，您可以開始使用 Aurora Serverless v2 來管理現有 Aurora 資料庫叢集中的資料庫運算容量。同時包含佈建執行個體和 Aurora Serverless v2 的叢集稱為混合組態叢集。您可以選擇在叢集中使用佈建的執行個體和 Aurora Serverless v2 的任何組合。

若要測試 Aurora Serverless v2，請將讀取器新增至 Aurora 資料庫叢集並選取 Serverless v2 作為執行個體類型。一旦讀取器建立並可用，您就可以開始將其用於唯讀工作負載。確認讀取器如預期般工作後，您可以啟動容錯移轉以開始使用 Aurora Serverless v2 進行讀取和寫入。此選項提供了最短停機時間體驗以開始使用 Aurora Serverless v2。

是，您可以從 Aurora Serverless v1 遷移至 Aurora Serverless v2。請參閱《Aurora 使用者指南》以進一步了解相關資訊。

可在此處查看 Aurora Serverless v1 相容性資訊。可以在此處查看 Aurora Serverless v2 相容性資訊。

是，您可以從現有 Aurora 佈建置群集取得的快照，還原到 Aurora Serverless 資料庫叢集 (反之亦然)。

您可以從同一個 VPC 中執行的用戶端應用程式存取 Aurora Serverless 資料庫叢集。您無法為 Aurora Serverless 資料庫提供公有 IP 地址。

雖然 Aurora Serverless 會根據有效的資料庫工作負載而自動擴展，但在某些情況下，容量可能無法快速擴展以滿足突然的工作負載變化，例如大量新事務。在這些情況下，您可以使用 AWS 管理主控台、AWS CLI 或 Amazon RDS API，將容量明確設定為特定的值。

啟動擴展操作後，Aurora Serverless 會嘗試尋找擴展點，該擴展點是資料庫可以安全地完成擴展的時間點。如果您正在進行長時間執行的查詢或事務，或者正在使用臨時表格或表格鎖定，則 Aurora Serverless 可能無法找到擴展點。

在 Aurora Serverless 中，資料庫容量是以 ACU 計算。按每秒 ACU 用量的固定費率付費。在 Aurora Serverless 上執行工作負載的運算成本將取決於您選擇的資料庫叢集組態：Aurora 標準或 Aurora I/O 最佳化。如需有關定價和區域可用性的資訊，請造訪 Aurora 定價頁面。

適用於 Aurora PostgreSQL 的 Amazon Aurora Optimized Reads 是一項全新的衡量價格效能比的選項，相較於沒有執行個體，可改善高達 8 倍的查詢延遲，並節省高達 30% 的成本。這項功能非常適合具有大型資料集，且超過資料庫執行個體的記憶體容量的應用程式。

Amazon Aurora Optimized Reads 執行個體使用以 NVMe 為基礎的本機 SSD 區塊層級儲存 (可用於以 Graviton 為基礎的 r6gd 和 Intel r6id 執行個體)，以改善資料集超過資料庫執行個體記憶體容量的應用程式的查詢延遲。Optimized Reads 包括效能增強功能，例如分層快取和臨時物件。

分層快取可改善高達 8 倍的查詢延遲，並節省高達 30% 的成本，適用於高讀取量、I/O 密集型應用程式，例如操作儀表板、異常偵測，以及以向量為基礎的相似性搜尋。快取資料可自動從記憶體資料庫緩衝區快取移至本機儲存，以加快該資料的後續存取速度，進而實現這些優勢。分層快取僅適用於搭載 Aurora I/O 優化組態的 Amazon Aurora PostgreSQL 版本。

臨時物件可將 Aurora PostgreSQL 產生的臨時資料表置於本機儲存，藉此改善涉及排序、雜湊彙總、高負載聯結和其他資料密集型操作的查詢效能，以實現更快的查詢處理。

適用於 Aurora PostgreSQL 的 Amazon Aurora Optimized Reads 為客戶 (使用延遲敏感應用程式和大型工作集) 提供令人驚歎的價格效能替代方案，以滿足他們的業務 SLA，並使用其執行個體進行更多操作。

Amazon Aurora Optimized Reads 適用於以 Intel 為基礎的 R6id 執行個體和以 Graviton 為基礎的 R6gd 執行個體。您可以在此處查看 Aurora 的區域可用性。

Amazon Aurora Optimized Reads 適用於 R6id 和 R6gd 執行個體上的 Aurora 的 PostgreSQL 相容版本。在 Aurora PostgreSQL 上支援的引擎版本為 15.4 以上版本及 14.9 以上版本。

Amazon Aurora Optimized Reads 不適用於 Aurora Serverless v2 (ASv2)。

是，Amazon Aurora Optimized Reads 適用於這兩種組態。使用這兩種組態時，啟用 Optimized Reads 的執行個體會自動將臨時資料表映射至以 NVMe 為基礎的本機儲存，以改善分析查詢和索引重建的效能。

若是高讀取量 I/O 密集型工作負載，Aurora PostgreSQL 上啟用 Optimized Reads 的執行個體會設定為使用 Aurora I/O 優化，自動將快取資料從記憶體移至以 NVMe 為基礎的本機儲存，以改善高達 8 倍的查詢延遲，並節省高達 30% 的成本，這適用於所用大型資料集超過資料庫執行個體記憶體容量的應用程式。

客戶可透過 AWS 管理主控台、CLI 和 SDK 開始使用 Amazon Aurora Optimized Reads。依預設，所有 R6id 和 R6gd 執行個體都可使用 Optimized Reads。若要使用此功能，客戶只需修改現有的 Aurora 資料庫叢集，以包括 R6id 和 R6gd 執行個體，或使用這些執行個體來建立新的資料庫叢集。請參閱 Amazon Aurora Optimized Reads 文件以開始使用。

R6id 和 R6gd 執行個體上約 90% 的可用本機儲存可用於 Optimized Reads，Aurora 保留 10% 的 NVMe 儲存，以減少 SSD 寫入放大的影響。可用儲存的配置取決於啟用哪些 Optimized Reads 功能。

若同時搭配臨時物件和分層快取功能使用 Optimized Reads，本機儲存中臨時物件的可用空間相當於這些資料庫執行個體上可用記憶體大小的兩倍。這與 Aurora PostgreSQL 上的臨時物件儲存的目前大小相符。剩餘的本機儲存磁碟空間可用於快取資料。

若僅搭配臨時物件功能使用 Optimized Reads，所有可用的本機儲存磁碟空間都可用於臨時物件。例如，搭配臨時物件和分層快取功能使用 r6gd.8xlarge 執行個體時，會為臨時物件保留 534 GiB (2 倍記憶體容量)，而 1054 GiB 則用於分層快取。

如果本機儲存失敗，Aurora 會自動執行主機取代。在多節點資料庫叢集中，這會觸發區域內容錯移轉。

在發生資料庫容錯移轉的情況下，容錯移轉之後的查詢延遲會暫時增加。這種延遲增加會隨著時間的推移而減少，並最終追回到容錯移轉之前的查詢延遲。啟用叢集快取管理 (CCM) 可加速此追趕時間。使用 CCM，客戶可將特定的 Aurora PostgreSQL 資料庫執行個體指定為容錯移轉目標。

啟用 CCM 後，指定容錯移轉目標的本機儲存快取會緊密反映主要執行個體的本機儲存快取，從而縮短容錯移轉後的追趕時間。然而，如果指定的容錯移轉目標也正用於提供與寫入器執行個體的工作負載分開的讀取工作負載，則啟用 CCM 可能會影響本機儲存快取的長期有效性。

因此，客戶若執行需要將讀取器指定為待命容錯移轉的工作負載，必須讓 CCM 增加容錯移轉後快速恢復查詢延遲的可能性。客戶若在其指定的容錯移轉目標上執行單獨的工作負載，可能希望平衡容錯移轉後立即復原延遲的需求，與啟用 CCM 之前快取效能的長期有效性。

pgvector 是 PostgreSQL 的開放原始碼延伸，由 Amazon Aurora PostgreSQL 相容版本提供支援。

是。Aurora 機器學習 (ML) 將 ML 模型公開為 SQL 函數，允許您使用標準 SQL 來呼叫 ML 模型，將資料傳遞給它們，並將預測做為查詢結果傳回。pgvector 要求將向量內嵌項目存放在資料庫中，這需要在來源文字或影像資料上執行 ML 模型才能產生內嵌項目，然後將批次內嵌項目移至 Aurora PostgreSQL 中。

Aurora ML 可定期呼叫 Amazon Bedrock 或 Amazon SageMaker，這會傳回模型中的最新內嵌項目，讓此成為即時程序，使內嵌項目在 Aurora PostgreSQL 中保持最新狀態。

Amazon Aurora PostgreSQL Optimized Reads 使用 pgvector，在超過可用執行個體記憶體的工作負載中，每秒進行向量搜尋的查詢可增加高達 9 倍。由於 Optimized Reads 提供分層快取功能，可自動將快取資料從記憶體資料庫緩衝區快取移至本機儲存，以加速該資料的後續存取。

若您需要近乎即時地存取交易資料，則應使用 Amazon Aurora 與 Amazon Redshift 的零 ETL 整合。此整合可讓您透過簡單的 SQL 命令，充分利用 Amazon Redshift ML 的優勢。

Aurora MySQL 與 Amazon Redshift 的零 ETL 整合可在以下區域適用於 Aurora MySQL 3.05 以上版本 (與 MySQL 8.0.32 相容) 的 Aurora MySQL 相容版本提供：美國東部 (俄亥俄)、美國東部 (維吉尼亞北部)、美國西部 (奧勒岡)、亞太區域 (新加坡)、亞太區域 (雪梨)、亞太區域 (東京)、歐洲 (法蘭克福)、歐洲 (愛爾蘭) 和歐洲 (斯德哥爾摩) 區域。Aurora 與 Amazon Redshift 的零 ETL 整合適用於美國東部 (俄亥俄) 區域中 Aurora PostgreSQL 15.4 的 Aurora PostgreSQL 相容版本。

Aurora 與 Amazon Redshift 的零 ETL 整合可移除建置和維護複雜資料管道的需求。您可以將單一或多個 Aurora 資料庫叢集的資料整合至單一 Amazon Redshift 資料庫叢集，並使用 Amazon Redshift 對 Aurora 的 PB 級交易資料執行近乎即時的分析和 ML 處理。 

Aurora 與 Amazon Redshift 的零 ETL 整合與 Aurora Serverless v2 相容。同時使用 Aurora Serverless v2 和 Amazon Redshift Serverless 時，您可以針對交易資料產生近乎即時的分析，而無需管理任何資料管道的基礎設施。

您可以使用 Amazon RDS 主控台，並指定 Aurora 來源和 Amazon Redshift 目的地來建立零 ETL 整合，即可開始使用。建立整合後，Aurora 資料庫會複寫到 Amazon Redshift，您即可在初始植入完成後開始查詢資料。如需詳細資訊，請參閱 Aurora 與 Amazon Redshift 的零 ETL 整合入門指南。

免費提供零 ETL 整合和持續處理資料變更。您需要為使用現有的 Amazon RDS 和 Amazon Redshift 資源，建立和處理做為零 ETL 整合一部分而產生的變更資料付費。這些資源可能包括：

• 藉由啟用增強的 binlog 使用的額外 I/O 和儲存
• 初始資料匯出至做為 Amazon Redshift 資料庫種子的快照匯出成本
• 用於儲存複寫資料的額外 Amazon Redshift 儲存
• 將資料從來源移至目標的跨可用區域資料傳輸成本

如需詳細資訊，請瀏覽 Aurora 定價頁面。

Amazon DevOps Guru for RDS 是 Amazon RDS (包含 Amazon Aurora) 的一項採用 ML 技術的新功能，旨在自動偵測和診斷資料庫效能和操作問題，讓您能夠在幾分鐘而不是幾天內解決問題。

Amazon DevOps Guru for RDS 是 Amazon DevOps Guru 的一項功能，旨在偵測所有 Amazon RDS 引擎和數十種其他資源類型的操作和效能問題。DevOps Guru for RDS 擴展了 DevOps Guru 的功能，以偵測、診斷和修復 Amazon RDS 中與資料庫相關的各種問題 (例如資源過度使用和某些 SQL 查詢的不當行為)。

當出現問題時，Amazon DevOps Guru for RDS 可立即通知開發人員和 DevOps 工程師，並提供診斷資訊、問題程度的詳細資訊和智慧修復建議，以協助客戶快速解決與資料庫相關的效能瓶頸和操作問題。

Amazon DevOps Guru for RDS 旨在消除手動工作，並縮短偵測和解決關聯式資料庫工作負載中難以發現的效能瓶頸的時間 (從幾小時和數天縮短到幾分鐘)。

您可以為每個 Amazon Aurora 資料庫啟用 DevOps Guru for RDS，它會自動偵測工作負載的效能問題，就每個問題向您傳送提醒，解釋問題清單並推薦解決措施。
DevOps Guru for RDS 讓非專家更容易進行資料庫管理，並協助資料庫專家管理更多資料庫。

Amazon DevOps Guru for RDS 使用 ML 來分析由 Amazon RDS Performance Insights (PI) 收集的遙測資料。DevOps Guru for RDS 不會在其分析中使用您存放在資料庫中的任何資料。PI 測量資料庫負載，該指標可表徵應用程式如何在資料庫中花費時間，以及資料庫產生的選定指標，例如 MySQL 中的伺服器狀態變數和 PostgreSQL 中的 pg_stat 表。

若要開始使用 DevOps Guru for RDS，請確保透過 RDS 主控台啟用績效詳情，然後只需為您的 Amazon Aurora 資料庫啟用 DevOps Guru。使用 DevOps Guru，您可以選擇分析覆蓋範圍作為整個 AWS 帳戶，指定您希望 DevOps Guru 分析的特定 AWS CloudFormation 堆疊，或使用 AWS 標籤建立您希望 DevOps Guru 分析的資源分組。

Amazon DevOps Guru for RDS 有助於識別可能影響應用程式服務品質的各種效能問題，例如鎖定堆積、連線風暴、SQL 迴歸、CPU 和輸入/輸出爭用以及記憶體問題。

Amazon RDS Performance insights 是一項資料庫效能調校和監控功能，可收集和視覺化 Amazon RDS 資料庫效能指標，協助您快速評估資料庫負載，並確定何時何地採取行動。Amazon DevOps Guru for RDS 旨在監控這些指標，偵測您的資料庫何時遇到效能問題，分析指標，然後告訴您發生什麼問題，以及您可以採取什麼措施。

您應該對新的現代應用程式使用 Data API，尤其是那些採用 AWS Lambda 建置，而且需要在請求/回應模型中存取 Aurora 的現代應用程式。當現有應用程式與資料庫驅動程式高度耦合、有長時間執行的查詢，或者當開發人員想要利用臨時資料表等資料庫功能或使用工作階段變數時，您應該使用資料庫驅動程式而非 Data API，並且管理持久性資料庫連線。

您可以在我們的文件中，查閱針對 Aurora Serverless v2 和 Aurora 佈建執行個體的 Data API AWS 區域和資料庫版本可用性相關資訊。若客戶目前使用適用於 Aurora Serverless v1 的 Data API，我們建議他們遷移至 Aurora Serverless v2，以便利用重新設計的 Data API 和更精細的 Aurora Serverless v2 擴展。

Data API 將讓您簡化與加快現代應用程式開發。Data API 是一種簡單易用且安全的 HTTP 型 API，可消除部署資料庫驅動程式的必要性，管理客戶端連線集區或在應用程式和資料庫之間設定複雜的 VPC 聯網。Data API 還透過自動建立資料庫連線集區並進行共用來提高可擴展性，從而幫助需頻繁開啟和關閉連線的應用程式減少運算開銷。 

針對 Aurora 的 PostgreSQL 相容版本和 MySQL 相容版本，現有適用於 Aurora Serverless v1 的 Data API 將繼續做為 Aurora Serverless v1 的一項功能。適用於 Aurora Serverless v2 的 Data API 和 Aurora 佈建執行個體不支援 Aurora Serverless v1。適用於 Aurora Serverless v2 的 Data API 和 Aurora 佈建執行個體支援 Aurora 全球資料庫寫入器執行個體。

使用者只有在得到授權時才能調用 Data API 操作。管理員可以透過附加定義使用者權限的 AWS Identity and Access Management (IAM) 政策授予其使用 Data API 的許可。如果您使用 IAM 角色，也可以對某個角色附加政策。呼叫 Data API 時，您可以透過在 AWS Secrets Manager 中使用機密為 Aurora 資料庫叢集傳送憑證。 

Aurora Serverless v1 仍可使用 Data API，而不會產生額外費用。適用於 Aurora Serverless v2 的 Data API 和 Aurora 佈建執行個體依 API 請求量定價，如 Aurora 定價頁面上所述。適用於 Aurora Serveless v2 的 Data API 和 Aurora 佈建執行個體使用 AWS CloudTrail 資料平面事件而非管理事件來記錄活動，這與適用於 Aurora Serverless v1 的 Data API 相同。

如果您想要追蹤此活動，可以透過 CloudTrail 主控台、CLI 或 SDK 啟用資料事件記錄。這樣做將產生費用，詳細資訊請見 CloudTrail 定價頁面。此外，使用 AWS Secrets Manager 也會產生費用，請參閱 AWS Secrets Manager 以了解更多資訊。 

AWS CloudTrail 會將 AWS API 活動擷取為管理事件或資料事件。CloudTrail 管理事件 (又稱為「控制平面操作」) 顯示在 AWS 帳戶中的資源上執行的管理操作，例如建立、更新和刪除某項資源。CloudTrail 資料事件 (又稱為「資料平面操作」) 顯示在 AWS 帳戶中的資源上或資源內執行的資源操作。

Data API 會執行資料平面操作，因為它會對 Aurora 資料庫中的資料執行查詢。因此，我們會將 Data API 活動記錄為資料事件，因為這是正確的事件分類。如果您啟用資料事件記錄，只有 CloudTrail 資料事件才會產生費用。

是的，Data API 免費方案包括第一年每個月一百萬個請求，這是跨所有 AWS 區域的彙總用量。 一年後，客戶將開始按 Aurora 定價頁面所述支付 Data API 費用。

Amazon Aurora MySQL 相容版本 5.6 及更高版本，以及 Amazon Aurora PostgreSQL 相容版本 11.21 及更高版本、12.16 及更高版本、13.12 及更高版本、14.9 及更高版本和 15.4 及更高版本中均提供 Amazon RDS 藍/綠部署。請參閱 Aurora 文件，進一步了解可用的版本。

Amazon RDS 藍/綠部署可在所有適用的 AWS 區域和 AWS GovCloud 區域使用。

Amazon RDS 藍/綠部署可讓您進行更安全、更簡單、更快速的資料庫變更。藍/綠部署非常適合主要或次要版本資料庫引擎升級、作業系統更新、綠色環境中的結構描述變更等不會破壞邏輯複寫的使用案例，例如在表末尾新增新欄或資料庫參數設定變更。

您可以使用藍/綠部署透過單一轉換同時進行多個資料庫更新。這可讓您隨時掌握安全修補程式的最新資訊、改善資料庫效能，並以短暫且可預測的停機時間存取較新的資料庫功能。如果您只想在 Aurora 上執行次要版本升級，我們建議您使用 Aurora Zero Downtime Patching (ZDP)。

在綠色或藍色執行個體上執行您的工作負載所產生的成本相同。在藍色和綠色執行個體上執行的成本包括我們的資料庫執行個體的目前標準定價、儲存成本、讀取/寫入 I/O 的成本，以及任何已啟用功能的成本，如備份和 Amazon RDS Performance Insights 的成本。 實際上，在藍/綠部署的使用壽命內，您要支付的費用大約是在資料庫執行個體上執行工作負載成本的 2 倍。

例如，您有 Aurora MySQL 相容版本 5.7 叢集在兩個 r5.2xlarge 資料庫執行個體 (一個主要寫入器執行個體和一個讀取器執行個體) 上執行，它們位於 us-east-1 AWS 區域。每個 r5.2xlarge 資料庫執行個體都設定有 40 GiB 儲存體，每月執行 2,500 萬次 I/O。您要使用 Amazon RDS 藍/綠部署建立藍色執行個體拓撲的複製項目，執行它 15 天 (360 小時)，而每個綠色執行個體在該期間執行 300 萬次 I/O 讀取。然後，您要在成功轉換後刪除藍色執行個體。藍色執行個體 (寫入器和讀取器) 的隨需價格為每小時 1.179 美元 (執行個體 + 儲存 + I/O)，所以 15 天的成本為 849.2 美元。綠色執行個體 (寫入器和讀取器) 的隨需價格為每小時 1.167 美元 (執行個體 + 儲存 + I/O)，所以 15 天的成本為 840.40 美元。這 15 天使用藍/綠部署的總成本為 1689.60 美元，是在該期間執行藍色執行個體所產生成本的大約 2 倍。

Amazon RDS 藍/綠部署可協助您更安全、更輕鬆，並且更快速地執行資料庫變更，例如，主要或次要版本升級、結構變更、執行個體擴展、引擎參數變更和維護更新等。

在 Amazon RDS 藍/綠部署中，藍色環境是您當前的生產環境。綠色環境是您的預備環境，它將在轉換後成為您的新生產環境。

當 Amazon RDS 藍/綠部署啟動轉換後，它會同時阻止寫入到藍色和綠色環境，直至轉換完成為止。 在轉換期間，綠色環境 (或稱預備環境) 會追趕上生產系統，確保預備環境與生產環境的資料保持一致。生產和預備環境完成同步後，藍/綠部署會將流量重新引導至新升級的生產環境，使預備環境成為新的生產環境。

Amazon RDS 藍/綠部署的設計允許轉換完成後在綠色環境上執行寫入，從而確保轉換流程中不會遺失任何資料。

Amazon RDS 藍/綠部署不會刪除您的舊生產環境。如果需要，您可以對它進行存取，以執行額外的驗證和效能/迴歸測試。如果不再需要舊生產環境，您可以將其刪除。標準帳單費用包含您將舊生產執行個體刪除為止前的費用。

如果您的藍色環境是自我管理邏輯複本或訂閱用戶，我們將封鎖轉換。我們建議您先停止複寫至藍色環境，繼續轉換，然後繼續複寫。相反，如果您的藍色環境是自我管理邏輯複本或發布者的來源，您可以繼續轉換。但是，您將需要更新自我管理複本，以在轉換後從綠色環境進行複寫。

否，Amazon RDS 藍/綠部署不支援 Amazon Aurora 全球資料庫、Amazon RDS Proxy 或跨區域僅供讀取複本。

不可以，您暫時無法使用 Amazon RDS 藍/綠部署來轉返變更。

Trusted Language Extensions (TLE) for PostgreSQL 可讓開發人員建立高效能 PostgreSQL 延伸模組，並在 Amazon Aurora 上安全執行該模組。這樣一來，TLE 可縮短您的上市時間，並減輕資料庫管理員在驗證用於生產資料庫工作負載的自訂和第三方程式碼方面的負擔。一旦確定延伸模組符合您的需求，就能繼續進行。獨立軟體開發廠商 (ISV) 採用 TLE 後，即可向在 Aurora 上執行的客戶提供全新 PostgreSQL 延伸模組。

TLE for Aurora PostgreSQL 可用於 Amazon Aurora PostgreSQL 相容版本 14.5 以上版本。TLE 本身以 PostgreSQL 延伸模組形式實作，您可從與 Arora 上支援的其他延伸模組相似的 rds_superuser 角色將其啟動。

您可在 Amazon Aurora 中執行 PostgreSQL 14.5 以上版本的 TLE for PostgreSQL。

TLE for PostgreSQL 目前可用於所有 AWS 區域 (不包括 AWS 中國區域) 和 AWS GovCloud 區域。

TLE for PostgreSQL 可供 Aurora 客戶免費使用。

Aurora 和 Amazon RDS 支援超過 85 個經策管的 PostgreSQL 擴展集。AWS 在 AWS 共同責任模式下管理每個擴展的安全風險。實作 TLE for PostgreSQL 的延伸套件包含在這個集合中。您編寫或從第三方來源獲得並安裝在 TLE 中的擴展，會被視為應用程式的程式碼的一部分。您須對使用 TLE 擴展的應用程式的安全負責。

您可以建置開發人員功能，例如點陣圖壓縮和差分隱私權 (如保護個人隱私權的可公開存取的統計查詢)。

TLE for PostgreSQL 目前支援 JavaScript、PL/pgSQL、Perl 和 SQL。

一旦 rds_superuser 角色啟用 TLE for PostgreSQL，即可使用來自任何 PostgreSQL 用戶端 (例如 psql) 的 SQL CREATE EXTENSION 命令部署 TLE 擴展。這種方式類似於建立以程序語言 (例如 PL/pgSQL 或 PL/Perl) 編寫的使用者定義函數。您可以控制哪些使用者具有部署 TLE 擴展並使用特定擴展的許可。

TLE for PostgreSQL 透過 TLE API 來專門存取您的 PostgreSQL 資料庫。TLE 支援的受信任語言包括 PostgreSQL 伺服器程式設計介面 (SPI) 的所有函數，以及對 PostgreSQL 掛鉤的支援，包括檢查密碼掛鉤。

您可以前往官方 TLE GitHub 頁面，進一步了解有關 TLE for PostgreSQL 專案的資訊。