Amazon Aurora 常見問答集

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

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

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

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

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

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

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

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

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

您可以在此處查看 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 文件。

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

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

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

不需要，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% 資料庫叢集大小的備份費用。在為資料庫叢集設定的備份保留期間，您也無需支付快照費用。

是的，您可以為 Amazon Aurora 用量購買資料庫 Savings Plans，只要承諾在 1 年期內維持固定用量，即可節省高達 35% 的成本。 關於符合資格用量的其他資訊，請參閱資料庫 Savings Plans 定價頁面。

不是，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 定價頁面。

最低儲存為 10GiB。根據您的資料庫使用量，您的 Aurora 儲存將以 10 GiB 的增量自動增長到 256 TiB，而不會影響資料庫效能。 無需提前佈建儲存。 Aurora 使用 Amazon Aurora PostgreSQL Limitless Database 提供自動化水平擴展功能，其中該資料庫將儲存擴展至超過 256 TiB。若要進一步了解，請瀏覽使用 Aurora PostgreSQL Limitless Database。

有三種方法可以擴展與 Amazon Aurora 資料庫關聯的運算資源：使用 Amazon Aurora Serverless、Aurora PostgreSQL Limitless Database 或手動擴展。無論您選擇哪個選項，您僅需按實際用量付費。

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

使用 Aurora PostgreSQL Limitless Database，您可以根據工作負載需求自動水平擴展運算資源，以支援大規模應用程式。它可協助您將應用程式擴展至超出單一資料庫執行個體的寫入輸送量和儲存限制，同時保持在單一資料庫內操作的簡便性。 

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

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

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

Amazon Aurora 會自動讓您的資料在一個區域內的三個可用區域 (AZ) 維持耐久，並自動嘗試在運作狀態良好的可用區域內恢復您的資料庫，不會遺失任何資料。在極少數的情況下，無法在 Amazon Aurora 儲存內找到您的資料，您可以從資料庫快照中進行恢復或對新執行個體執行 point-in-time 恢復操作。請注意，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 全球資料庫) 使用專用基礎設施，讓資料庫充分為您的應用程式提供服務，而且複寫到最多五個次要區域通常延遲時間不到一秒。它適用於 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 v2 的運作方式，與佈建的容錯移轉和其他高可用性功能相似。如需詳細資訊，請參閱 Aurora Serverless v2 和高可用性。
  
• 如果您沒有 Aurora 複本 (即單一執行個體) 且未執行 Aurora Serverless，Aurora 會嘗試在與原始執行個體相同的可用區域中建立新的資料庫執行個體。已盡力進行這種原始執行個體的取代操作，但可能不成功，例如，在出現會廣泛影響可用區域的問題時。

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

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

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

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

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

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

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

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

只要在 Amazon RDS 主控台按幾下，就能建立 Aurora 全球資料庫。或者，您可以使用 AWS 軟體開發套件 (SDK) 或 AWS Command-Line Interface (CLI)。您可以在主要和次要區域之間使用佈建或無伺服器執行個體類別類型的混合組態。您還可以將主要區域設定為 Aurora I/O 最佳化叢集組態，將次要區域設定為 Aurora 標準，或執行相反設定。若要進一步了解，請瀏覽建立 Amazon Aurora 全球資料庫。

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

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

否。如果您的主要區域無法使用，您可以使用受管的跨區域 Aurora 全球資料庫容錯移轉作業來提升次要區域，以獲得完整的讀取和寫入功能。您也可以使用 Aurora 全球資料庫寫入端點，進而無需變更應用程式程式碼，即可連線至新提升的區域。若要進一步了解，請瀏覽連線至 Amazon Aurora 全球資料庫。

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

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

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

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

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

是的，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 相容性資訊。

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

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

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

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

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

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

Aurora Serverless v2 支援已佈建 Aurora 的所有功能，包括僅供讀取複本、多可用區域組態、Aurora 全球資料庫、RDS Proxy 和 Performance Insights。

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

Aurora PostgreSQL Limitless Database 提供自動化水平擴展功能，以處理每秒數百萬筆寫入交易並管理 PB 級資料，同時確保單一資料庫內操作的簡便性。您可以專注於建置大規模的應用程式，而無需建置和維護複雜的解決方案，來跨多個資料庫執行個體擴展資料，以支援您的工作負載。Aurora PostgreSQL Limitless Database 會根據您的應用程式工作負載進行擴展，而您僅需按應用程式的實際用量付費。若要進一步了解，請瀏覽 Aurora PostgreSQL Limitless Database 使用者指南。

對於需要水平擴展並且需要比單一 Aurora 資料庫執行個體支援更多的寫入輸送量或資料儲存容量的應用程式，您應該使用 Aurora PostgreSQL Limitless Database。例如，會計應用程式可以由使用者水平分割，因為每個使用者的會計資料獨立於其他使用者。Aurora PostgreSQL Limitless Database 會自動擴展，以支援最大且成長最快的應用程式。 

有兩個現有的擴展功能：搭配 Aurora 複本使用 Amazon Aurora Auto Scaling 和 Aurora Serverless v2。

Aurora 複本讓您能夠將 Aurora 叢集的讀取容量增加至超出單一資料庫執行個體所能提供的限制。可以將其讀取工作負載與寫入工作負載分隔的應用程式最多可從 15 個讀取複本中受益，進而達到更高的整體讀取輸送量。Aurora 複本不需要應用程式水平分割其資料。所有資料在每個複本中都可用。Aurora 複本不會增加 Aurora 叢集的儲存容量或寫入輸送量。

Aurora Serverless v2 是 Aurora 的隨選垂直擴展組態，可根據應用程式需求在單一運算執行個體的容量限制內，自動擴展資料庫運算和記憶體。寫入器和讀取器執行個體支援 Aurora Serverless v2。但是，其不會增加 Aurora 叢集的儲存容量。如果您的應用程式設計為水平擴展，Aurora PostgreSQL Limitless Database 可讓您將資料庫的寫入輸送量和儲存容量擴展超出單一 Aurora 寫入器執行個體的限制

Aurora PostgreSQL Limitless Database 會使用資料表欄中客戶指定的值 (也稱為碎片索引鍵) 跨資料庫執行個體分割資料。例如，儲存使用者資訊的資料表可以使用 User-ID 欄作為碎片索引鍵來進行分割。從本質而言，Aurora PostgreSQL Limitless Database 是無伺服器節點的分散式部署。節點可以是路由器，也可以是碎片。路由器可管理資料庫的分散式性質。每個碎片都會存放資料的子集，從而支援並行處理以實現高寫入輸送量。

隨著運算或儲存需求的增加，Aurora 首先會自動向上擴展每個執行個體及其關聯的儲存，然後橫向擴充以滿足不同的碎片索引鍵值的資料庫工作負載。在任何時候，碎片索引鍵值都由單一無伺服器執行個體擁有及提供。當應用程式連線到 Aurora PostgreSQL Limitless Database 並發出請求時，會先分析該請求。然後，它可以傳送至擁有由請求指定的碎片索引鍵值的運算執行個體，或者協同運作跨多個執行個體的查詢。

多個運算執行個體 (每個都會提供不同的碎片索引鍵值) 可同時為同一個 Aurora PostgreSQL Limitless Database 提供應用程式請求。Aurora PostgreSQL Limitless Database 提供與單一寫入者 Aurora PostgreSQL 系統相同的交易語意，從而無需管理應用程式中不同交易網域的複雜性。

Aurora PostgreSQL Limitless Database 支援包含您資料的三種資料表類型：碎片、參考和標準。

碎片資料表：這些資料表分散在多個碎片中。資料會根據資料表中指定欄的值 (稱為碎片索引鍵)，在碎片間分割。它們對於擴展應用程式中最大、I/O 密集度最高的資料表非常有用。

參考資料表：這些資料會在每個碎片上完整複製資料，以便透過移除不必要的資料移動，來加快聯結查詢工作。它們通常用於不常修改的參考資料，例如產品目錄和郵遞區號。

標準資料表：這些資料表與常規 Aurora PostgreSQL 資料表類似。標準資料表全都放在單一碎片上，因此可以透過移除不必要的資料移動來加快聯結查詢工作。您可以從標準資料表建立碎片資料表和參考資料表。

若要進一步了解 PostgreSQL 相容性注意事項，請瀏覽 Aurora PostgreSQL Limitless Database 要求和注意事項。

您可以在 Amazon RDS 主控台或 Amazon API 中開始使用 Aurora PostgreSQL Limitless Database，以建立具有受支援引擎版本的新 Aurora PostgreSQL 叢集。若要進一步了解入門資訊，請瀏覽 Aurora PostgreSQL Limitless Database 使用者指南。

您的應用程式連線至 Aurora PostgreSQL Limitless Database 的方式與連線到標準 Aurora PostgreSQL 叢集的方式相同。您只需連線至叢集端點即可。若要進一步了解，請瀏覽使用 Aurora PostgreSQL Limitless Database。

是的，您可能需要調整資料庫結構描述以使用 Aurora PostgreSQL Limitless Database。所有碎片資料表都必須包含碎片索引鍵，因此可能需要回填這些資料。例如，會計應用程式可能會使用 User-ID 欄按使用者分割其資料，因為每個使用者都獨立於其他使用者。雖然使用者資料表本身自然包含此
欄，其他資料表可能沒有，例如包含發票明細行項目的資料表。由於這些資料表也需要按使用者分割，才能協同運作資料表以達到最佳查詢效能，因此需要將 User-ID 欄新增至資料表中。

用於分割資料的欄上沒有命名條件約束，但欄定義必須相符。您需要將碎片索引鍵新增至應用程式查詢，也可能需要調整查詢和交易以實現最佳效能。例如，當資料表僅按 User-ID 分割時，使用 Invoice-ID 查找發票會很慢，因為需要在所有資料庫執行個體上執行查詢。但是，如果查詢還指定 User-ID，則查詢會路由到包含該 User-ID 的所有訂單的單一資料庫執行個體，從而減少查詢的延遲。

是。當您將 Aurora PostgreSQL Limitless Database 的運算備援設定為大於零時，您可以選擇高可用性選項，從而提供 99.99% 的可用性。存放和存取 Aurora PostgreSQL Limitless Database 資料的每個運算執行個體都可以有一或兩個備用執行個體，以便在主要執行個體無法使用時可以接管請求。路由器將自動重新導向流量，以將對應用程式的影響降至最低。

Aurora PostgreSQL Limitless Database 可用於與 PostgreSQL 16.4 相容的 Aurora I/O 最佳化叢集組態。有關 Aurora PostgreSQL Limitless Database 的 AWS 區域可用性的其他資訊，請參閱 Aurora 定價頁面。

在 Aurora PostgreSQL Limitless Database 中，資料庫容量是以 ACU 計算。按每秒 ACU 用量的固定費率付費。適用 Aurora I/O 最佳化組態儲存費率。如需詳細資訊，請瀏覽 Aurora 定價頁面。

Amazon Aurora 平行查詢是指將單一查詢運算負載下推並分散到 Aurora 儲存層中數千個 CPU 的能力。不使用平行查詢，針對 Amazon Aurora 資料庫發出的查詢將完全在資料庫叢集的一個執行個體內執行；這與大多數資料庫操作的方式類似。

平行查詢非常適合需要新資料和絕佳查詢效能的分析工作負載使用，即使在大型表格也很適用。這種類型的工作負載本質上通常是可操作的。

平行查詢可帶來更快速的效能，將分析查詢的速度最高提升兩個數量級。還可帶來操作簡便性並持續取得最新的資料，因為您可以在 Aurora 叢集直接對目前的交易資料發出查詢。此外，平行查詢還支援相同資料庫上的交易和分析工作負載，讓 Aurora 在執行並行分析查詢的同時，維持高交易輸送量。

尚未在緩衝集區的大部分大型資料集查詢都可受益於這項功能。平行查詢的最初版本可下推和橫向擴充超過 200 個 SQL 函數、對等連結和投影的處理。

特定查詢的效能提升取決於可將多少的查詢計畫下推到 Aurora 儲存層。客戶已回報超過 1 個數量級的查詢延遲提升。

是，不過我們預期這種情況很少出現。

不需要變更查詢語法。查詢最佳化工具會自動決定是否對特定查詢使用平行查詢。若要檢查查詢是否使用平行查詢，可以執行 EXPLAIN 命令以查看查詢執行計畫。如果您希望略過啟發法並強制執行平行查詢以做測試之用，可使用 aurora_pq_force 工作階段變數。

您可以使用 aurora_pq 參數在全域和工作階段層級動態啟用和停用平行查詢。

否。除了您已支付的執行個體、輸入/輸出和儲存費用之外，無須支付其他費用。

否，查詢的平行查詢 IO 費用在儲存層進行計費，開啟平行查詢功能會產生相同或更高的費用。您所獲得的好處是查詢效能方面的提升。

使用平行查詢可能會產生更高輸入/輸出費用的原因有兩個。第一，即使表格中的部分資料位於緩衝集區，平行查詢還是需要在儲存層掃描所有資料，因此產生更多輸入/輸出。第二，避免緩衝集區發生爭用的副作用，也就是執行平行查詢無法為緩衝集區暖機。因此，連續執行相同的平行查詢會產生大量的輸入/輸出費用。

若要進一步了解平行查詢，請參閱文件。

否。目前，您可以將平行查詢與 R* 執行個體系列中的執行個體搭配使用。

平行查詢適用於與 MySQL 5.7 和 MySQL 8.0 相容的 Amazon Aurora 版本。

平行查詢與 Aurora Serverless v2 和回溯相容。

否。雖然我們預期在大多數的情況下平行查詢可改善查詢延遲，但這可能會產生較高的輸入/輸出成本。建議您在啟用和停用該功能的情況下徹底進行工作負載測試。一旦決定平行查詢是正確的選擇，即可仰賴查詢最佳化工具來自動決定哪些查詢要使用平行查詢。當最佳化工具無法做出最佳的決定時，這種情況很少發生，您可以覆寫該設定。

Aurora 平行查詢不是資料倉儲，無法提供這類產品特有的功能。此功能的設計旨在加速關聯式資料庫的查詢效能，適用於操作分析等使用案例，以及當您需要對資料庫的新資料執行快速的分析查詢時。

對於 EB 級雲端資料倉儲，請考慮 Amazon Redshift。

適用於 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 相容版本提供支援。

您可以使用 pgvector 在資料庫中存放、搜尋、索引和查詢從機器學習 (ML) 和人工智慧 (AI) 模型中產生的數十億個嵌入項目，例如 Amazon Bedrock 或 Amazon SageMaker 中的模型。向量嵌入是一種數字呈現，表示文字、影像和影片等內容的語義含義。

使用 pgvector，您可以查詢 Aurora PostgreSQL 資料庫中的內嵌項目，以便對這些資料類型 (以向量表示、與 Aurora 中的其他表格資料結合) 執行有效的語意相似性搜尋。這可讓您將生成式 AI 和其他 AI/ML 系統用於新的應用程式類型，例如根據類似文字描述或影像提供個人化建議、根據面試備註、機器人進行候選人比對，根據成功的文稿或聊天工作階段對話方塊提供客服的下一個最佳行動建議，等等。 

請閱讀我們向量資料庫功能部落格，了解如何在 Aurora PostgreSQL 資料庫中使用 pgvector 延伸來存放嵌入項目、建立互動式問題回答聊天機器人，以及使用 pgvector 與 Aurora 機器學習之間的原生整合進行情緒分析。

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

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

是。有兩種方法可將 Amazon Aurora 資料庫與 Amazon Bedrock 整合，以支援生成式 AI 應用程式。首先，Amazon Aurora ML 可直接透過適用於 Aurora MySQL 和 Aurora PostgreSQL 的 SQL，存取 Amazon Bedrock 中可用的基礎模型。其次，只需點按一下即可將 Aurora 設定為 Amazon Bedrock 知識庫中的向量存放區，並在 Aurora 上存放 Bedrock 產生的嵌入項目。Amazon Bedrock 知識庫支援 Aurora PostgreSQL，做為檢索增強生成 (RAG) 等使用案例的向量存放區。請閱讀我們的部落格和文件，了解如何使用 Aurora PostgreSQL 做為 Amazon Bedrock 的知識庫。

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

請閱讀我們的部落格和文件，了解如何透過 Aurora Optimized Reads 來改善 Aurora PostgreSQL 的查詢效能。

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

Amazon Aurora 與 Amazon SageMaker 的零 ETL 整合，讓您能近乎即時地將營運資料庫和應用程式中的資料匯入資料湖倉。透過 SageMaker 的資料湖倉架構，您可在現有資料投資的基礎上建構開放式資料湖倉，無需變更資料架構，並能使用您偏好的分析工具與查詢引擎，例如 SQL、Apache Spark、BI 和 AI/ML 工具。

Aurora 與 Amazon Redshift 的零 ETL 整合可在 Aurora MySQL 3.05.2 版本 (與 MySQL 8.0.32 相容) 及更高版本的 Aurora MySQL 相容版上使用。Aurora 與 Amazon Redshift 的零 ETL 整合適用於 Aurora PostgreSQL 16.4 版及更高版本的 Aurora PostgreSQL 相容版本。

Aurora 與 Amazon SageMaker 的零 ETL 整合可在 Aurora MySQL 3.05.0 版本 (與 MySQL 8.0.32 相容) 及更高版本的 Aurora MySQL 相容版上使用。Aurora 與 Amazon SageMaker 的零 ETL 整合適用於 Aurora PostgreSQL 相容版本的 Aurora PostgreSQL 16.4 及更高版本，以及 Aurora PostgreSQL 17.4 及更高版本。

請瀏覽 AWS 區域和 Aurora 資料庫引擎中支援的 Aurora 功能，以進一步了解 Aurora 零 ETL 整合的 AWS 區域可用性。

Aurora 與 Amazon Redshift 與 Amazon SageMaker 的零 ETL 整合可移除建置和維護複雜資料管道的需求。您可以將來自各種 Aurora 資料庫叢集的多個資料表合併到單一 Amazon Redshift 資料庫叢集或 SageMaker 的資料湖倉架構，並在 Aurora 的作業資料上執行近乎即時分析和 ML。

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

Aurora 與 Amazon SageMaker 的零 ETL 整合與 Aurora Serverless v2 相容。

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

透過零 ETL 整合持續處理資料變更，無需額外費用。您需要為使用資源，建立和處理做為零 ETL 整合一部分而產生的變更資料付費。這些資源可能包括：

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

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

是，您可以使用 AWS CloudFormation，管理和自動化 Aurora 零 ETL 整合所需資源的設定和部署。如需詳細資訊，請瀏覽 CloudFormation 零 ETL 整合範本。

CloudWatch Database Insights 是一種監控和指標解決方案，可簡化及增強資料庫疑難排解。它可以自動化遙測收集，包括指標、日誌和追蹤，從而消除手動設定和組態的需要。透過將這項遙測整合到 Amazon CloudWatch 中，CloudWatch Database Insights 可提供資料庫效能和運作狀態的統一檢視。

CloudWatch Database Insights 的主要優勢包括：

1. 輕鬆遙測收集：自動收集資料庫指標、日誌和追蹤，從而最大限度地減少設定時間。
2. 精選洞察：提供預先建置的儀表板、警示和洞察，以監控和最佳化資料庫效能，並且只需最少的組態即可開始使用。
3. 統一的 CloudWatch 檢視：將多個資料庫的遙測結合為一個檢視，以簡化監控。
4. AI/ML 功能：使用 AI/ML 偵測異常，減少手動疑難排解操作。
5. 應用程式內容監控：允許使用者將資料庫效能與應用程式效能建立關聯。
6. 機群和執行個體層級檢視：提供高層級的機群監控和詳細的執行個體檢視，以進行根本原因分析。
7. 無縫 AWS 整合：與 Amazon CloudWatch Application Signals 和 AWS X-Ray 整合，實現全面的可觀測性體驗。

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 主控台啟用 Performance Insights，然後只需為您的 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 旨在監控這些指標，偵測您的資料庫何時遇到效能問題，分析指標，然後告訴您發生什麼問題，以及您可以採取什麼措施。

CloudWatch Database Insights 會即時監控 Aurora 資源和應用程式，並透過可自訂的儀表板顯示資料。相比之下，Amazon DevOps Guru 是一種機器學習 (ML) 服務，可分析 CloudWatch 指標，以了解應用程式在一段時間內的行為、偵測異常，並提供解決問題的洞察和建議。此外，DevOps Guru 會分析來自多個來源的資料，包括 AWS Config、AWS CloudFormation 和 AWS X-Ray。您可以使用 CloudWatch 儀表板，透過 AWS/DevOps-Guru 命名空間中發布的指標來監控 DevOps Guru 洞察。這可協助您在 CloudWatch 主控台中的單一窗格視圖下檢視所有洞察和異常。

RDS Performance Insights 是資料庫效能調校和監控功能，讓客戶能夠評估資料庫的負載，並判斷採取行動的時機和位置。CloudWatch Database Insights 是一項全新的資料庫可觀測性功能，它繼承了 Performance Insights 的所有功能，以及機群層級監控、與應用程式效能監控的整合，還有資料庫指標與日誌和事件的關聯性。

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

您可以在我們的文件中，查閱針對 Aurora Serverless v2 和 Aurora 佈建執行個體的資料 API AWS 區域和資料庫版本可用性相關資訊。

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

適用於 Aurora Serverless v2 的 Data API 和 Aurora 佈建執行個體支援 Aurora 全球資料庫寫入器執行個體。

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

適用於 Aurora Serverless v2 的資料 API 和 Aurora 佈建執行個體依 API 請求量定價，如 Aurora 定價頁面上所述。適用於 Aurora Serveless v2 的 Data API 和 Aurora 佈建執行個體使用 AWS CloudTrail 資料平面事件而非管理事件來記錄活動。

如果您想要追蹤此活動，可以透過 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 定價頁面所述支付資料 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 藍/綠部署的轉換防護機制會在切換前阻止寫入您的藍色和綠色環境，直至您的綠色環境追趕上進度為止。藍/綠部署還會對您的藍色和綠色環境中的主要和複本執行運作狀態檢查。它還會執行複寫運作狀態檢查。例如，確定複寫是否已停止或是否有錯誤。它會偵測藍色和綠色環境之間的長時間交易異動。您可以指定最長的容許停機時間，最短為 30 秒，而且當您進行中的交易超出此值，轉換將會逾時。

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

是，Amazon RDS 藍/綠部署支援 Aurora 全球資料庫。 若要進一步了解，請閱讀 Amazon Aurora 全球資料庫藍/綠部署使用者指南。

否，Amazon RDS 藍/綠部署不支援 Amazon RDS Proxy 或跨區域讀取複本。 

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

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

PostgreSQL 擴展在相同的程序空間執行以獲得高效能。然而，擴展可能存在可導致資料庫崩潰的軟體缺陷。

TLE for PostgreSQL 可提供多層保護來降低這種風險。TLE 的設計可限制對系統資源的存取。rds_superuser 角色可確定允許誰安裝特定擴展。不過，這些變更只能透過 TLE API 進行。TLE 的設計可限制擴展缺陷對單一資料庫連線的影響。除了這些保護措施之外，TLE 的設計還可為 rds_superuser 角色中的 DBA 提供細粒度線上控制，以控制誰可以安裝擴展，並且他們可以建立執行這些擴展的許可模型。使用者只有具有足夠的許可，才能在 TLE 擴展上使用「CREATE EXTENSION」命令來執行和建立。DBA 還可將更複雜的擴展所需的「PostgreSQL 勾點」列入允許清單，這些擴展可修改資料庫的內部行為，並且通常需要提升的許可。

TLE for PostgreSQL 可用於 Amazon Aurora PostgreSQL 相容版本 14.5 以上版本。TLE 本身以 PostgreSQL 延伸模組形式實作，您可從與 Aurora 上支援的其他延伸模組相似的 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 專案的資訊。