使用 AWS CDK 開發和部署雲端基礎設施的最佳實務

大多數最佳實務的指導原則是盡可能讓事情簡單，但不會更簡單。只有在您的需求要求更複雜的解決方案時，才增加複雜性。使用 AWS CDK，您可以視需要重構程式碼，以支援新的需求。您不需要預先為所有可能案例進行架構。

AWS Well-Architected Framework 將元件定義為一起根據需求交付的程式碼、組態 AWS 和資源。一個元件往往是技術擁有的單元，並自其他元件所解偶。術語工作負載是指一組一起提供業務價值的元件。工作負載通常是商業和技術領導人溝通所談及的最細節的內容。

AWS CDK 應用程式會映射至 AWS Well-Architected Framework. AWS CDK 應用程式定義的元件。CDK 應用程式是一種機制，可編寫和提供 Well-Architected 雲端應用程式最佳實務。您也可以透過成品儲存庫，例如 AWS CodeArtifact，建立和共用元件做為可重複使用的程式碼庫。

單一套件是 AWS CDK 應用程式的進入點。在這裡，您可以定義部署應用程式不同邏輯單位的方式和位置。您也可以定義 CI/CD 管道來部署應用程式。應用程式建構定義解決方案的邏輯單位。

針對您在多個應用程式中使用的建構使用其他套件。（共享建構也應該有自己的生命週期和測試策略。) 相同儲存庫中套件之間的相依性是由您儲存庫的建置工具管理。

雖然可以，但不建議在同一個儲存庫中放置多個應用程式，尤其是在使用自動化部署管道時。這樣做會增加部署期間變更的「爆量半徑」。當儲存庫中有多個應用程式時，變更一個應用程式會觸發其他應用程式部署 （即使其他應用程式尚未變更）。此外，一個應用程式中的中斷可防止部署其他應用程式。

當套件開始用於多個應用程式時，請將它們移至自己的儲存庫。如此一來，使用它們的應用程式建置系統就可以參考套件，也可以在獨立於應用程式生命週期的節奏上進行更新。不過，一開始將所有共用建構放在一個儲存庫中可能很合理。

此外，在不同團隊處理時，將套件移至自己的儲存庫。這有助於強制執行存取控制。

若要跨儲存庫界限使用套件，您需要一個私有套件儲存庫，類似於 NPM、PyPi 或 Maven Central，但在您的組織內部。您也需要一個發行程序，來建置、測試和發佈套件到私有套件儲存庫。CodeArtifact 可以託管大多數熱門程式設計語言的套件。

套件儲存庫中套件的相依性是由語言的套件管理員管理，例如 TypeScript 或 JavaScript 應用程式的 NPM。您的套件管理員有助於確保組建是可重複的。它透過記錄應用程式依賴的每個套件的特定版本來執行此操作。它還可讓您以受控制的方式升級這些相依性。

共用套件需要不同的測試策略。對於單一應用程式，將應用程式部署到測試環境並確認它仍然有效，可能就足夠了。但共用套件必須獨立於取用應用程式進行測試，就像是公開發行一樣。（您的組織可能會選擇實際將一些共用套件發行給大眾。)

請記住，建構可以是任意簡單或複雜的。Bucket 是建構，但也可以CameraShopWebsite是建構。

除了用於部署基礎設施的 generating AWS CloudFormation 範本之外， AWS CDK 還綁定執行期資產，例如 Lambda 函數和 Docker 映像，並將其與您的基礎設施一起部署。這可讓您將定義基礎設施的程式碼，以及實作執行時間邏輯的程式碼，結合到單一建構中。這是最佳實務。這兩種類型的程式碼不需要存在於不同的儲存庫中，甚至在不同的套件中。

若要一起發展這兩種類型的程式碼，您可以使用獨立式建構來完全描述功能，包括其基礎設施和邏輯。使用獨立建構，您可以單獨測試兩種類型的程式碼、跨專案共用和重複使用程式碼，以及同步對所有程式碼進行版本。

堆疊是部署單位：堆疊中的所有項目都會一起部署。因此，從多個 AWS 資源建置應用程式的更高層級邏輯單位時， 會將每個邏輯單位表示為建構，而非堆疊。僅使用堆疊來描述應如何針對各種部署案例撰寫和連線您的建構。

例如，如果其中一個邏輯單位是網站，則構成它的建構 （例如 Amazon S3 儲存貯體、API Gateway、Lambda 函數或 Amazon RDS 資料表） 應該組成單一高階建構。然後，該建構應該在一或多個堆疊中執行個體化以進行部署。

透過使用建構和堆疊進行部署，您可以提高基礎設施的重複使用潛力，並提高部署方式的靈活性。

建構和堆疊內的環境變數查詢是常見的反模式。建構和堆疊都應該接受屬性物件，以允許完全在程式碼中設定。否則， 會對程式碼執行所在的機器引入相依性，這會建立更多您必須追蹤和管理的組態資訊。

一般而言，環境變數查詢應限於 AWS CDK 應用程式的頂層。它們也應該用來傳入在開發環境中執行 所需的資訊。如需詳細資訊，請參閱 AWS CDK 的環境。

若要在所有環境中的建置時間持續執行完整的單元測試套件，請避免在合成期間進行網路查詢，並在程式碼中建立所有生產階段的模型。（以下將介紹這些最佳實務。) 如果任何單一遞交一律會產生相同的產生範本，您可以信任您寫入的單位測試，以確認產生的範本看起來像您預期的方式。如需詳細資訊，請參閱測試 AWS CDK 應用程式。

變更資源的邏輯 ID 會導致資源在下次部署時被新的資源取代。對於資料庫和 S3 儲存貯體等具狀態資源，或 Amazon VPC 等持久性基礎設施，這很少是您想要的。請注意可能導致 ID 變更的任何 AWS CDK 程式碼重構。撰寫單位測試，宣告具狀態資源IDs 保持靜態。邏輯 ID 衍生自id您在執行個體化建構結構時指定的 ，以及建構結構在建構樹中的位置。如需詳細資訊，請參閱邏輯 IDs。

許多企業客戶為 L2 建構模組 （代表具有內建 Sane 預設值和最佳實務的個別 AWS 資源的「策劃」建構模組） 編寫自己的包裝函式。這些包裝函式會強制執行安全最佳實務，例如靜態加密和特定 IAM 政策。例如，您可以建立您在應用程式中使用的 MyCompanyBucket，以取代一般的 Amazon S3 Bucket 建構。此模式對於在軟體開發生命週期的早期出現安全指導很有用，但不要依賴它作為唯一強制執行方法。

反之，請使用服務控制政策和許可界限等 AWS 功能，在組織層級強制執行您的安全防護機制。在部署之前，使用 Aspects 和 AWS CDK 或 CloudFormation Guard 等工具來宣告基礎設施元素的安全屬性。將 AWS CDK 用於其最佳用途。

最後，請記住，撰寫您自己的 "L2+" 建構可能會阻止您的開發人員利用 AWS CDK 套件，例如AWS 解決方案建構或第三方建構。這些套件通常以標準 AWS CDK 建構模組為基礎，且無法使用您的包裝函式建構模組。

雖然 AWS CloudFormation 可讓您在部署時間 （使用 Conditions、 和 Parameters) 做出決策{ Fn::If }，而 AWS CDK 可讓您存取這些機制，我們建議您不要使用這些機制。相較於一般用途程式設計語言中可用的值，您可以使用的值類型和可以對其執行的操作類型會受到限制。

反之，請嘗試使用程式設計語言的if陳述式和其他功能，在 AWS CDK 應用程式中做出所有決策，例如要執行個體化的建構。例如，常見的 CDK 慣用詞，在清單上反覆運算，並使用清單中每個項目的值來執行個體化建構，只是無法使用 AWS CloudFormation 表達式。

將 AWS CloudFormation 視為 AWS 實作詳細資訊，CDK 用於強大的雲端部署，而不是語言目標。您不是在 TypeScript 或 Python 中撰寫 AWS CloudFormation 範本，而是撰寫使用 CloudFormation 進行部署的 CDK 程式碼。

名稱是寶貴的資源。每個名稱只能使用一次。因此，如果您將資料表名稱或儲存貯體名稱硬式編碼到您的基礎設施和應用程式中，您就無法在同一個帳戶中部署該基礎設施兩次。（此處討論的名稱是由 Amazon S3 儲存貯體建構的 bucketName 屬性所指定的名稱。)

更糟的是，您無法變更需要取代的資源。如果屬性只能在資源建立時設定，例如 Amazon DynamoDB 資料表KeySchema的 ，則該屬性是不可變的。變更此屬性需要新的資源。不過，新資源必須具有相同的名稱，才能真正取代。但當現有資源仍在使用該名稱時，它不能具有相同的名稱。

更好的方法是盡可能少地指定名稱。如果您省略資源名稱， AWS CDK 將以不會造成問題的方式為您產生它們。假設您有資料表做為資源。然後，您可以將產生的資料表名稱做為環境變數傳遞至 AWS Lambda 函數。在 AWS CDK 應用程式中，您可以將資料表名稱參考為 table.tableName。或者，您可以在啟動時在 Amazon EC2 執行個體上產生組態檔案，或將實際資料表名稱寫入 AWS Systems Manager 參數存放區，讓您的應用程式可以從該處讀取。

如果您需要的地方是另一個 AWS CDK 堆疊，這更直接。假設一個堆疊定義資源，而另一個堆疊需要使用它，則適用以下條件：

AWS CDK 會預設為保留您建立的所有項目的政策，以嘗試防止您遺失資料。例如，包含資料之資源 （例如 Amazon S3 儲存貯體和資料庫資料表） 的預設移除政策是在從堆疊移除資源時，不會將其刪除。反之，資源會從堆疊中孤立。同樣地，CDK 的預設值是永久保留所有日誌。在生產環境中，這些預設值可能會快速導致儲存您實際不需要的大量資料，以及對應的 AWS 帳單。

仔細考慮您希望每個生產資源的這些政策為何，並相應地指定它們。使用 Aspects 和 AWS CDK 驗證堆疊中的移除和記錄政策。

對於您的應用程式需要多少堆疊，沒有硬且快速的規則。您通常會根據部署模式做出決策。請記住下列準則：

確定性是成功部署 AWS CDK 的關鍵。每當 AWS CDK 應用程式部署到指定的環境時，其結果基本上應該相同。

由於您的 AWS CDK 應用程式是以一般用途程式設計語言撰寫，因此可以執行任意程式碼、使用任意程式庫，以及進行任意網路呼叫。例如，您可以使用 AWS SDK 從 AWS 您的帳戶擷取一些資訊，同時合成您的應用程式。認識到這樣做將導致額外的登入資料設定要求、增加的延遲，以及每次執行 時發生失敗的機率，無論多小cdk synth。

請勿在合成期間修改 AWS 您的帳戶或資源。合成應用程式不應有副作用。只有在產生 AWS CloudFormation 範本之後，才應該在部署階段變更基礎設施。如此一來，如果發生問題， AWS CloudFormation 可以自動轉返變更。若要進行無法在 AWS CDK 架構中輕鬆進行的變更，請使用自訂資源在部署時間執行任意程式碼。

即使是嚴格唯讀呼叫也不一定是安全的。考慮網路呼叫傳回的值變更時會發生什麼情況。這會影響基礎設施的哪個部分？ 已部署的資源會發生什麼情況？ 以下是兩個範例情況，其中值突然變更可能會導致問題。

這些情況可能很危險，因為 AWS端變更可能會在成功部署數月或數年後發生。突然，您的部署「無故」失敗，而且您很久之前忘記了您做了什麼和原因。

所幸， AWS CDK 包含稱為內容提供者的機制，可記錄非確定性值的快照。這可讓未來的合成操作產生與第一次部署時完全相同的範本。新範本中唯一的變更是您在程式碼中所做的變更。當您使用建構的 .fromLookup()方法時，呼叫的結果會快取在 中cdk.context.json。您應該將此與其餘程式碼一起遞交至版本控制，以確保 CDK 應用程式的未來執行使用相同的值。CDK Toolkit 包含管理內容快取的命令，因此您可以在需要時重新整理特定項目。如需詳細資訊，請參閱內容值和 AWS CDK。

如果您需要一些沒有原生 CDK 內容提供者的值 （來自 AWS 或其他位置），建議您撰寫單獨的指令碼。指令碼應該擷取 值並將其寫入檔案，然後在 CDK 應用程式中讀取該檔案。只有在您想要重新整理預存值時才執行指令碼，而不是作為一般建置程序的一部分。

使用 AWS CDK 建構程式庫的grant()便利方法，您可以建立 AWS Identity and Access Management 角色，使用最小範圍的許可將存取權授予另一個資源。例如，請考慮如下的行：

amzn-s3-demo-bucket.grantRead(myLambda)

此單行會將政策新增至 Lambda 函數的角色 （也會為您建立）。該角色及其政策是十幾行的 CloudFormation，您不需要撰寫。 AWS CDK 只會授予函數從儲存貯體讀取所需的最低許可。

如果您需要開發人員一律使用安全團隊建立的預先定義角色， AWS CDK 編碼會變得更加複雜。您的團隊在設計應用程式的方式上可能會失去許多彈性。更好的替代方案是使用服務控制政策和許可界限，以確保開發人員保持在護欄內。

在傳統 AWS CloudFormation 案例中，您的目標是產生參數化的單一成品，以便在套用這些環境特有的組態值之後，將其部署到各種目標環境。在 CDK 中，您可以且應該將該組態建置到原始程式碼中。為您的生產環境建立堆疊，並為每個其他階段建立個別的堆疊。然後，將每個堆疊的組態值放入程式碼中。使用 Secrets Manager 和 Systems Manager 參數存放區之類的服務，找出您不想透過這些資源的名稱或 ARNs 來簽入來源控制的敏感值。

當您合成應用程式時，在cdk.out資料夾中建立的雲端組件包含每個環境的個別範本。您的整個建置是確定性的。您的應用程式沒有out-of-band變更，任何指定的遞交一律會產生完全相同的 AWS CloudFormation 範本和隨附的資產。這使得單元測試更加可靠。

達成完全持續部署的目標，無需人為介入，需要高層級的自動化。只有大量監控才能實現該自動化。若要測量已部署資源的所有層面，請建立指標、警示和儀表板。請勿停止測量 CPU 用量和磁碟空間等項目。同時記錄您的業務指標，並使用這些測量來自動化部署決策，例如轉返。 AWS CDK 中的大多數 L2 建構都有方便的方法可協助您建立指標，例如 dynamodb.Table類別上的 metricUserErrors()方法。