本節概述我們的最佳做法，並提供將 OPDK 與 AWS 雲端搭配使用的建議。
Cassandra 可做為幾乎所有政策的後端和資料儲存庫使用，而且是 Apigee Edge 執行階段環境的重要部分。本文件的重點是最佳化 AWS 環境的 Cassandra，
儲存空間和 I/O 需求
大部分的 Cassandra I/O 會依序進行，但在某些情況下，您可能需要隨機 I/O。例如在讀取作業期間讀取已排序的字串資料表。SSD 是 Cassandra 的儲存機制，因為這項服務可為隨機讀取作業提供極低延遲的回應時間，同時為壓縮作業提供足夠的依序寫入效能。此處也會考量複製作業。
AWS EC2 中許多執行個體都隨附本機儲存空間，硬碟會實際連接至託管於 EC2 執行個體的硬體。Apigee 建議在實際工作環境中執行 Cassandra 時，同時使用 SSD 和執行個體儲存庫。使用具有超過 1 個 SSD 的執行個體類型時，您可以使用 RAID0 來取得更高的處理量和儲存空間容量。
網路需求
Cassandra 使用 Gossip 通訊協定與其他節點交換網路拓撲的資訊。使用 Gossip 加上 Cassandra 的分散式特性 (涉及讀取和寫入作業的多個節點) 會導致透過網路傳輸大量資料。Apigee 建議針對實際工作環境系統使用至少 1 GB 的網路頻寬和超過 1 GB 的執行個體類型。
使用 CIDR 為 /16 的虛擬私有雲。由於 AWS 中的子網路不能跨越超過 1 AZ，因此 Apigee 建議採取下列做法：
- 每個可用性可用區 (AZ) 建立 1 個子網路
- 使用 3 個私人子網路進行 Apigee 安裝作業，每個 AZ 各有一個 Cassandra 節點。3 個子網路應有足夠的 CIDR 區塊，以配合 Cassandra 叢集的水平擴充。
- 設定 3 個公開子網路，其中包含 Cassandra 的專屬 NAT，以便與網際網路通訊，進行軟體下載和安全性更新。
與舊版主從架構不同的是，Cassandra 具有無主架構的架構，其中所有節點都扮演相同的角色，因此不會出現單點故障的情形。請考慮將 Cassandra 節點分散到多個 AZ，以啟用高可用性。只要將節點分散至 AZ 即可，在發生災難時仍可維持可用性和運作時間。
選擇執行個體系列
查看 Cassandra CPU 需求時，請留意，插入大量使用 CPU 的工作負載在 Cassandra 中會受 CPU 限制，接著再受到 IO 限制。換句話說，所有寫入作業都會歸入修訂版本記錄，但 Cassandra 的寫入效率相當高，因此 CPU 會成為限制因素。Cassandra 具備高度並行的特性，並盡可能使用最多的 CPU 核心。
Apigee 建議使用具備 CPU 與記憶體平衡的執行個體系列。具體來說，如果您的 AWS 區域與 C3 都提供 C5 系列執行個體，則建議您使用 C5 系列執行個體做為備用選項。在某些情況下，4x2 是最適合在價格/效能係列的系列產品中最理想的執行個體。
Apigee 也建議為 Cassandra 執行個體使用預設用戶群。當您每 AZ 擴充為超過 1 個執行個體時，如果您將用戶群設為專用，則所有 Cassandra 執行個體很可能會都放在相同的基礎硬體上。因此，當硬體故障時 您可能會失去 AZ 中的所有執行個體
建議摘要
下表摘要列出將 AWS 與 Apigee Edge 搭配使用的 Apigee 建議：
| 執行個體系列 | C5d (建議) 或 C3 |
| 執行個體類型 | C(x).4xlarge |
| 執行個體存放區 | 配備 RAID0 的 SSD (本機儲存空間) |
| 用戶群類型 | 預設 |
| 節點位置 | 每 AZ 1 個 Cassandra 節點 |
| 虛擬私有雲與子網路 | 每個 AZ 僅限 1 個子網路，每個區域 1 個虛擬私有雲 |
詳情請參閱「Amazon 執行個體類型」。