BLEA開発チームが学んだAWS CDKの開発プラクティス 2023年版

© 2023, Amazon Web Services, Inc. or its affiliates. All
rights reserved. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. BLEA 開発チームが学んだ AWS CDK の開発プラクティス⾼野賢司 B - 2 ソリューションアーキテクトアマゾンウェブサービスジャパン合同会社 2023 年版

rights reserved. ⾼野賢司ソリューションアーキテクト @名古屋アマゾンウェブサービスジャパン合同会社趣味こうの東海地⽅のこれから AWS を使い始めるエンタープライズ企業を⽀援得意分野 Infrastructure as Code (IaC), DevOps Baseline Environment on AWS (BLEA) 開発者 https://github.com/aws-samples/baseline-environment-on-aws けんじサウナ、⾃作キーボード、マンガ @konokenj AWS CDK のアップデート情報をつぶやいています #cdk_releases

rights reserved. このセッションで扱う課題サービス開発に集中したいのでできればセキュリティを考えたくない AWS CDK のスタック分割やパラメータ管理を雰囲気でやっている Infrastructure as Code のコードが複雑になってきた AWS CDK を使い始めた開発者 BLEA 開発チームが課題に取り組んだ過程をご紹介し、判断に迷った際の参考としていただくことが⽬的です AWS CDK でセキュリティ対応を楽にするアイデア AWS CDK の開発プラクティス

rights reserved. Builder への要求は⾼度化している⾼品質なソフトウェアの素早い提供と改善セキュリティとレジリエンスの強化既存の技術の活⽤と新しい技術への挑戦

rights reserved. 必要に応じて、必要なアプリケーションを、必要なタイミングでみずから構築 Builder を⽀えるのは Self Service Platform セキュリティとアジリティの両⽴が必要

rights reserved. 中央集権型の管理はアジリティを低下させる AWS アカウントセキュリティベースラインアプリケーションとデータインフラストラクチャ • セキュリティインシデントの低減に責任を持つ • 慎重にリリースしてほしい • AWS の機能拡張にルールが追従できない • 多量のセキュリティイベントと例外管理が集中してボトルネックにサービスチームの責任範囲プラットフォームチーム通知プラットフォームチームの責任範囲 Stop! サービスチーム • ビジネス上の指標に責任を持つ • 素早くリリースしたい • AWS の新しい機能を試したい • サービスをどんどん拡張したい Agility! 予防的統制が主体セキュリティとアジリティの両⽴が困難

rights reserved. Builder が求めるガバナンスをつくる 3 つのアイデア

rights reserved. ゲートキーパーでなくガードレール Guardrail Gatekeeper これまで来た道を⽌める存在であった⾨番からここから⾏く道を⽰す存在であるガードレールにセキュリティの役割が変わりつつある

rights reserved. • ⼿作業での設定ではミスが避けられず再現性がない • ⼿順書を読んで状態を理解するには脳内にインタープリタが必要 • Infrastructure as Code によってアプリやガードレールの構築を宣⾔的に⾏い、再現性と可視性を得る • コードであれば Builder が改善に協⼒できる⼿作業でなく Infrastructure as Code

rights reserved. 内部サービスがチーム間を疎結合にする『共通基盤』モデルセキュリティ機能の構築・運⽤を⼀元化 • サービスチームはセキュリティ機能の構築やレビュー、例外承認などの完了を待機 • プラットフォームチームは共通基盤の変更時にすべてのサービスチームとの調整が必要『内部サービス』モデル内部顧客にサービスやテンプレートを公開 • サービスチームは内部サービスをセルフサービスで利⽤して独⽴性を担保 • 各チームは所有するサービスに対してすべての責任を負う* § 例︓バックログ管理、セキュリティ通知や障害への対応プラットフォームチームサービスチーム App Security 内部サービス利⽤公開プラットフォームチームサービスチーム App Security 互いに依存 * 内部サービスやテンプレートは利⽤者の責任で利⽤

rights reserved. Builder が必要とするガバナンス 1. ガードレールで⾃由にサービスを使⽤ 2. Infrastructure as Code で継続的に改善 3. 権限委譲とセルフサービス Guardrail Infrastructure as Code Self-service ⽂書ではなくテンプレートによるガバナンス ※ テンプレート = IaC のコード

rights reserved. テンプレートによるガバナンスで Builder を守る AWS アカウントセキュリティベースラインアプリケーションとデータインフラストラクチャ • テンプレートの利⽤を通じたセキュリティインシデントの低減に責任を持つ • セキュリティ状況を確認し助⾔を提供 • ガードレールとベストプラクティスをテンプレート（コード）で提供サービスチームの責任範囲プラットフォームチームプラットフォームチームの責任範囲サービスチーム • セキュリティを含めたサービス全体に責任を持つ • セキュリティイベントに対応 • 提供されたテンプレートをセルフサービスで実⾏ Agility! 発⾒的統制が主体通知テンプレート Go! But ... セキュリティとアジリティの両⽴が可能

rights reserved. Baseline Environment on AWS (BLEA) AWS のセキュリティベストプラクティスを実装したサンプルテンプレート AWS アカウントセキュリティベースラインアプリケーションとデータインフラストラクチャ AWS Control Tower * ガバナンスベースゲストシステムサンプル https://github.com/aws-samples/baseline-environment-on-aws * スタンドアロン版では AWS Control Tower の機能を⼀部補完セキュリティベースラインをコードで提供 • AWS のセキュリティサービスを活⽤して軽量なガバナンスベースを提供 • AWS のセキュリティベストプラクティス** を満たす Web アプリなどのサンプルコードを提供スケーラブルなガバナンス運⽤モデル • 権限委譲と分散管理を実現するためにセキュリティ通知や CI/CD のサンプル実装を提供 AWS CDK によるシンプルな実装 • AWS CDK のリファレンス実装としても利⽤可能 • AWS Japan の SA がオープンソースで公開 • Linter やビルドスクリプトなど周辺ツールを設定済 ** AWS Foundational Security Best Practices と CIS Benchmark 1.2

rights reserved. • マネージドサービスを活⽤した軽量なガードレール • コードによるコラボレーション • セルフサービスと継続的改善のメカニズムを作る • 組織に合わせてカスタマイズ • 例: BLEA for FSI https://github.com/aws-samples/baseline- environment-on-aws-for-financial-services-institute BLEA のアイデアを活⽤する

rights reserved. • ガバナンスモデルや利⽤するセキュリティサービスには変更なし • 最新の AWS サービスへの追従と CDK のベストプラクティスに準拠 • v3 への移⾏時はスタックの再作成を許容する • ガバナンスベースは Semantic Versioning に従うフィードバックをもとに BLEA v3 をリリース

rights reserved. 参考にした AWS CDK のベストプラクティス https://docs.aws.amazon.com/cdk/v2/guide/ best-practices.html 2023/05/20 AWS CDK CONFERENCE JAPAN © 2023, Amazon Web Services, Inc. or its affiliates. Twitter: #jawsug_cdk © 2023, Amazon Web Services, Inc. or its affiliates. AWS CDKͷ͋Δ͋Δ͓೰Έʹ౴͍͑ͨ ։ൃ࣌ͷҙࢥܾఆΛߴ଎Խ͢ΔͨΊʹ ༑Ԭ խࢤ Prototyping Engineer Amazon Web Services Japan G.K. https://speakerdeck.com/ tmokmss/answering-cdk-faqs AWS Japan で CDK を⽇々活⽤しているプロトタイピングチームの知⾒を参考にした

rights reserved. サービスチームによるセルフサービスモデル • ガバナンスベースをサービスチーム⾃⾝がデプロイする、基本の運⽤モデル • プラットフォームチームはガバナンスベースのリファレンス実装やサンプルアプリを提供ゲストシステムガバナンスベースクローンしてカスタマイズ aws-samples/ baseline- environment- on-aws YOUR-ORG/ blea-for- my-company ゲストシステムサンプルガバナンスベース CDK CDK Public repository Private repository CDK CDK ゲストシステムサンプルガバナンスベース CDK CDK ゲストシステムサービスチームの責任範囲プラットフォームチームの責任範囲 Security / Infrastructure accounts AWS IAM Identity Center などガバナンスベース CDK 配布デプロイデプロイ適したユースケースの例 • セルフサービスによる疎結合化・独⽴デプロイ性を重視 • チームによるカスタマイズとベストプラクティスの共有

rights reserved. ガバナンスベースの運⽤モデルの検討お客様からのフィードバック • ガバナンスベースのデプロイを⾏えないユーザーがいる • 複数の環境に簡単かつ継続的にデプロイする⼿段がほしい BLEA 開発チームでの検討 • ガバナンスベースは継続的に改善するので、CI/CD は必要 • 中央集権的な管理とならないように留意する • デプロイの粒度とタイミングをユーザーが制御できるようにしたい • CDK Toolkit でも Bootstrap を適切に⾏えば複数環境へのデプロイは可能採⽤しなかったアイデア • AWS CloudFormation StackSets （デプロイ対象のコントロールが複雑になりやすいため）

rights reserved. CDK Pipelines からの⾃動デプロイモデル • ガバナンスベースを CDK Pipelines によって各 AWS アカウントに適⽤ • デプロイ先 AWS アカウントを任意の粒度でグルーピング可能クローンしてカスタマイズ aws-samples/ baseline- environment- on-aws YOUR-ORG/ blea-for- my-company ゲストシステムサンプルガバナンスベース CDK CDK Public repository Private repository CDK CDK ゲストシステムサンプルガバナンスベース CDK CDK ゲストシステムサービスチームの責任範囲プラットフォームチームの責任範囲 Security / Infrastructure accounts AWS IAM Identity Center などデプロイ BLEA v3 Pipeline account AWS CodePipeline CI/CD パイプラインからデプロイ Self Mutation でパイプラインを⾃動更新ガバナンスベースゲストシステム適したユースケースの例 • デプロイ対象のグループや段階をコントロールしたい • 更新頻度が⾼く、常に最新のガバナンスを適⽤したい

rights reserved. AFC からの選択的デプロイモデル • AWS Control Tower Account Factory Customization (AFC) で AWS アカウント発⾏時に⾃動適⽤ • ガバナンスベースの更新時は AFC のブループリントを AWS アカウント単位で更新クローンしてカスタマイズ aws-samples/ baseline- environment- on-aws YOUR-ORG/ blea-for- my-company ゲストシステムサンプルガバナンスベース CDK CDK Public repository Private repository CDK CDK ゲストシステムサンプルガバナンスベース CDK CDK ゲストシステムサービスチームの責任範囲プラットフォームチームの責任範囲 Security / Infrastructure accounts AWS IAM Identity Center などデプロイ BLEA v3 Baseline Hub account AWS Service Catalog AWS Control Tower からデプロイガバナンスベースゲストシステム適したユースケースの例 • プラットフォームチームが組織全体の状況を把握したい • 更新頻度が低く、デプロイの実⾏環境を管理したくない

rights reserved. マルチスタックからシングルスタックに変更 1つの CDK App を複数のスタックで構成 CDK App chatbot-stack config-rules-stack iam-stack x5 実装の背景 • デプロイの影響範囲を局所化。ライフサイクル別にスタック分割課題 • デプロイに時間がかかる • クロススタック参照多く、更新時に複雑な⼿順が必要 • Account Factory Customization (AFC) では1スタックのみデプロイ可能 BLEA v2 まで原則として 1 CDK App = 1スタックで構成するように変更 • ガバナンスベースは AFC 対応のためシングルスタックに • ゲストシステムサンプルも原則シングルスタックに • リージョンが異なる場合やリソース数などの制約に当たる場合は例外 • スタックではなくコンストラクトを使⽤して構造化、ファイル分割 CDK App ct-guest-stack x1 BLEA v3

rights reserved. ステートフルなリソースが壊れてしまわないか︖ Q. ミスによって誤ってリソースを削除してしまうのでは︖ A. スタックの削除保護, DeletionPolicy, UpdateReplacePolicy で保護 Q. コードに変更がなくてもリソースが変更されるのでは︖ A. テンプレートとパラメータが同じならリソースの操作は⾏われない ※ CloudFormation の SSM パラメータや動的参照はスタック実⾏時に評価されるためステートフルなリソースには使⽤しない。パラメータを含めたバージョン管理を推奨リポジトリ内のすべてのソースをデプロイして完全性と⼀貫性を担保

rights reserved. シングルスタック化によるデプロイ時間の短縮 686 562 308 230 blea-gov-base-standalone blea-gov-base-ct v2 v3 -55% -60% 9 スタック → 1 スタック 5 スタック → 1 スタック

rights reserved. マルチアプリからシングルアプリに変更ユースケース* ごとに複数の CDK App を定義 (bin/*.ts) --app オプションで切り替えて異なる CDK App をデプロイ実装の背景 • 共通のコードを再利⽤して、複数の実装パターンに対応課題 • CI/CD パイプラインの設計が複雑化 • 各アプリが複数のファイルに依存するため構成が複雑 CDK App dynamodb-stack lambda-nodejs-stack restapi-stack CDK App dynamodb-stack lambda-python-stack restapi-stack BLEA v2 まで • CDK App はデプロイ⽅法を選択する⽤途でのみ複数作成 • CDK において App はアプリケーション全体を表現。 App を分割するケースの多くはリポジトリの分割を伴う CDK App apiapp-sample-stack nodejs python ユースケースごとに 1つの CDK App に再構成 BLEA v3 * BLEA における Monorepo のサブプロジェクト（パッケージ）を指す

rights reserved. Construct ID と物理名 Construct ID ... コンストラクトを初期化するときに第２引数に指定する⽂字列のこと MyStack MyConstruct MyTable MyBucket $ npx aws-cdk ls MyStack AWS マネジメントコンソール上の表⽰（物理名） CDK CLI 上の表⽰（Stack の Construct ID） MyStack MyStack-MyTableXXXXXXXX-XXXXXXXX mystack-myconstructmybucketxxxxxxxx-xxxxxxxx • スタック名には Construct ID がそのまま使われる • 物理名には <Stack>- が前置され、リソースまでの Construct のパスが結合して使われる ※ App クラスには Construct ID がない ※ リソースごとの名前の制約に合わせて変換されることも（⼩⽂字化、区切り⽂字の変更など） • Stage で Stack をまとめるとさらに <Stage>- が前置される

rights reserved. クラスの役割と物理名を考慮した命名の例 • Construct ID は PascalCase で命名する • 短くシンプルな名前で可視性を向上 • 共通の prefix をつけない（Construct による構造化で繰り返し出現するため） • リソースごとの制約によって切り詰められて末尾が失われないようにする • Stage の Construct ID には環境名をつける例) Dev, Staging, Prod • Stack の Construct ID にはサービスの名前をつける例) AwsomePhotos, Dev-GovBase • リソースの Construct ID にはシンプルな名前をつける例) ItemTable 前提︓スタックはなるべく分割しない Stack より下には "-" などの区切り⽂字が⼊らない Dev-AwsomePhotos-ItemTableXXXXXXXX-XXXXXXXX prod-awsomephotos-userphotoslogbucketxxxxxxxx-xxxxxxxx Dev-AwsomePhotos Stage がない場合 "環境名-" を前置

rights reserved. AWS CDK で環境ごとにパラメータを変更するには 2 つの要素を検討する必要がある 1. パラメータを読み込んで渡す⽅法 • パラメータをファイルやコンテキストから取得し、それぞれの環境に渡したい • 例: Dev, Prod 環境で異なる Amazon Aurora のインスタンスタイプを使⽤する 2. スタックを環境ごとに定義する⽅法 • Synth 時に、環境ごとに異なる CloudFormation テンプレートを出⼒したい • 例: Dev 環境⽤と Prod 環境⽤のスタックを⼀度の Synth で出⼒する

rights reserved. 環境ごとのパラメータの指定⽅法を変更 { "context": { "dev": { "envName": "Development", "slackNotifier": { "workspaceId": "T8XXXXXXX", "channelIdSec": "C00XXXXXXXX" } }, "stage": { "env": { "account": "111111111111", "region": "ap-northeast-1" // CLI で渡されたコンテキストキー environment の値を取得 const envKey = app.node.tryGetContext('environment'); // 指定されたコンテキストを cdk.json から取得 const envVals = app.node.tryGetContext(envKey); const monitorAlarm = new BLEAMonitorAlarmStack(app, `MonitorAlarm`, { notifyEmail: envVals['monitoringNotifyEmail'], env: getProcEnv(), $ cdk deploy -c enviroment=dev cdk.json bin/sample.ts ※ getProcEnv はコンテキストか環境変数 CDK_DEFAULT_* のいずれかから env を返す独⾃関数 Synth 1回につき単⼀の環境⽤のスタックを動的に合成実装の背景 • Context パラメータによる環境切り替えが開発当時⼀般的だった課題 • パラメータを変更して Synth するたびに Cloud Assembly (cdk.out) が上書きされる • 別のシェルを開いて cdk deploy を並列実⾏すると、cdk.out が上書きされ思わぬパラメータでデプロイされる • 同時に複数の環境にデプロイする場合、 --output オプションでアーティファクトの分離が必要 • JSON では型チェックや補完がきかず、設定ミスに気付きづらい BLEA v2 まで

rights reserved. 最もミスが起こりづらい⽅法を選択 2023/05/20 AWS CDK CONFERENCE JAPAN ͋Δ͋Δ͓೰Έʹ౴͍͑ͨ © 2023, Amazon Web Services, Inc. or its affiliates. Twitter: #jawsug_cdk ؀ڥ͝ͱʹύϥϝʔλΛઃఆ͢Δํ๏ - ൺֱද 23 (ॱෆಉ) ֓ཁ Pros Cons 1. Context variable cdk.json΍ –c ΦϓγϣϯͰ ࢦఆ cdk deploy –c env=dev CDKඪ४ؔ਺ (tryGetContext) Ͱ஋ ΛऔಘͰ͖Δ͜ͱͷެࣜײ JSONʹΑΔinteroperabilityͷߴ͞ (ଞπʔϧͰJSONΛੜ੒ͨ͠ΓͳͲ) ஋ͷValidationʹҰ޻෉ඞཁ (JSON SchemaͳͲ) JSONͷදݱྗʹറΒΕΔ (CDKͷܕ DurationͳͲ͸࢖͑ͳ͍) 2. ؀ڥม਺ CDKίϚϯυ࣮ߦ࣌ʹ؀ڥ ม਺Λࢦఆ ENV=dev cdk deploy CDKҎ֎ͷք۾Ͱ΋ඪ४తͳํ๏ CIπʔϧͷઃఆͰ্ॻ͖Ͱ͖ΔͳͲ Ԡ༻ํ๏͸ଟ͍͔΋ ؀ڥม਺͸จࣈྻܕͷΈ ؀ڥม਺Λ؅ཧ͢Δ৔ॴΛߟ͑Δ ඞཁ͋Γ 3. ֤ݴޠͷ ΦϒδΣΫτ CDKͷݴޠͰύϥϝʔλΛ ϋʔυίʔυ͢Δ (e.g. TypeScriptͷobject) จࣈྻŋ਺ࣈҎ֎ͷܕ͕࢖͑Δ (Duration΍ec2.InstanceTypeͳͲ) खܰʹܕ҆શ ݴޠ͕ݻఆ͞ΕΔɺಈతͳੜ੒ʹෆ ޲͖ͳͲinteroperability͕ඞཁͳঢ় گͰ͸೉͍͕͠ɺك 4. Secrets Manager ParameterStore CDK֎ͰύϥϝʔλΛ࡞੒ deploy࣌ʹCFn͕஋Λಡࠐ ൿಗ৘ใ(API keyͳͲ)ΛCDKίʔυ ΍CFnςϯϓϨʔτ͔ΒӅṭͰ͖Δ ύϥϝʔλͷॳظԽʹ௥Ճखॱඞཁ ύϥϝʔλͷARNͷ؅ཧ΋ඞཁ 5. CfnParameter CloudFormationͷ ParameterػೳΛ࢖͏ synthޙʹσϓϩΠ಺༰ΛมߋՄೳ ߹੒ͨ͠CFnςϯϓϨʔτΛ഑෍͠ ͍ͨ৔߹ʹ͸༗ޮ CFnΛҙࣝ͢Δඞཁ͕͋ΓɺૉͷCDK ΑΓॻ͖ʹ͍͘ ಛघͳঢ়گΛআ͍ͯϝϦοτ͸ബ͍ ݸਓతͳ࢖͍෼͚: σϑΥϧτ͸3ɺඞཁʹԠͯ͡2/4/5 2023/05/20 AWS CDK CONFERENCE JAPAN ͋Δ͋Δ͓೰Έʹ౴͍͑ͨ © 2023, Amazon Web Services, Inc. or its affiliates. Twitter: #jawsug_cdk ؀ڥ͝ͱʹελοΫఆٛΛग़͠෼͚Δํ๏ ελοΫఆٛํ๏ͷ୅දྫ (௨ৗ bin/xxx.ts ʹॻ͘ΞϨ) • Dynamicύλʔϯ • 1ͭͷελοΫఆٛΛ࢖͍ճ͢ StackͷID͸֎෦͔Β஫ೖ • Staticύλʔϯ1 • ؀ڥͷ਺͚ͩελοΫΛϋʔυίʔυ͢Δ • DynamicΑΓApp಺ͷελοΫߏ੒͕෼͔Γ΍͍͢ • Staticύλʔϯ2 • ελοΫͷΫϥεఆٛࣗମΛ؀ڥ͝ͱʹ࢖͍෼͚Δ • ؀ڥ͝ͱʹϦιʔεͷߏ੒ŋελοΫ෼ׂΛม͍͑ͨ࣌ͳͲʹ༗ޮ • ؀ڥͷҰக౓͕௿Լ͢ΔϦεΫ͋Γ 25 ※ Staticύλʔϯ͸synthͷ͕࣌ؒ௕͘ͳΓ͕ͪɻ ؀ڥม਺౳Ͱ৚݅෼ذ͠ɺෆཁͳnew Stack()Λ ඈ͹͢ͳͲͰճආ͸Մೳɻ ※ CDK PipelinesΛ࢖͏৔߹͸ɺ εςʔδͱ͍͏֓೦Ͱ͞Βʹϥοϓ͞ΕΔ https://speakerdeck.com/tmokmss/answering-cdk-faqs TypeScript のコード内でパラメータをハードコード静的型付けの利点を活⽤すべてのスタックを静的に宣⾔して Synth 時の認証情報とパラメータの不⼀致を避ける

rights reserved. 環境ごとのパラメータの指定⽅法を変更 import { Environment } from 'aws-cdk-lib'; export interface MyParameter { env?: Environment; envName: string; securityNotifyEmail: string; chatbotWorkspaceId: string; chatbotChannelId: string; } export const devParameter: MyParameter = { envName: 'Development', securityNotifyEmail: '[email protected]', chatbotWorkspaceId: 'T8XXXXXXX', import { devParameter, stgParameter } from "../parameter" const app = new cdk.App(); new Stack(app, "DevStack", { securityNotifyEmail: devParameter.securityNotifyEmail, }); new Stack(app, "StageStack", { securityNotifyEmail: stgParameter.securityNotifyEmail, }); $ cdk deploy parameter.ts bin/sample.ts • TypeScript ファイル (parameter.ts) にパラメータのインターフェイスと実際の値を定義 • CDK App はエクスポートされたパラメータの値をインポートして使⽤ • ⼀度の Synth ですべての環境⽤にスタックを合成 Synth 1回ですべての環境のスタックを静的に合成 BLEA v3

rights reserved. IaC ではコードをシンプルにすることが重要 Source code CloudFormation Template Parameter Resource AWS CDK AWS CloudFormation AWS CDK のプロセス意図をコーディングプログラマの意図通りにリソースが振る舞うことを実際に確認したいが、困難なことがある • リソースの作成にかかる時間や料⾦が負担 • リソースへのアクセス権を持っていない • ローカルでの完全なエミュレーションは不可能静的テストリソースの振る舞いを期待静的テストは IaC においても重要。しかし、⾼度なテスト技法を検討する前にコードの複雑性を下げ、変化を明確にすることでリソースの振る舞いを検証・予測しやすくする

rights reserved. IaC におけるコードの考え⽅静的であるほどテストは容易 • アプリのコードと異なり動的に振る舞いを変える必要性が低い • コードとパラメータを⼀箇所で管理し変更時には明⽰的にレビュー、ビルド、テスト宣⾔的に書く • 過度な抽象化や条件分岐、ループを避けて可読性と予測可能性を向上 • パラメータにも再現性が必要なため可変⻑のパラメータや値の変化には注意が必要 Single Source of Truth Git リポジトリを⾒ればインフラ構成がすべてわかる状態にするソフトウェア開発の技法を活かしつつ IaC に適したコードと⼿法を選択する

rights reserved. パラメータの変更をレビューする git commit list 「ある時点での全社員の IAM User を作成する」 • 外部のデータベースからパラメータを取得し⼈が確認してからプロビジョニング（cdk diff） • パラメータを保存することで差分をレビュー可能。スナップショットテストでの確認も有効 IaC の実⾏を⾃動化したり、パラメータが外部で変更されたりする場合バリデーションやテストの実装、または SDK などの代替⼿段を検討「社員が⼊社したら⾃動的に IAM User を作成する」 • 外部のデータベースの変更をトリガーとして⾃動的にリソースをプロビジョニング • パラメータの数や値が変化したときの影響を必ず確認 $ cdk deploy -c users=hoge,fuga,piyo hoge, fuga, piyo, foo 削除変更なし追加変更がないものも含めすべての要素を宣⾔する⼊⼒は安全か︖

rights reserved. パラメータの反映タイミングを考慮する静的なパラメータ • IaC のデプロイ実⾏時にリソースの作成・変更を期待 Memory: 512 Environment: TABLE_NAME: !Ref MyTable 動的なパラメータ • アプリの実⾏中に振る舞いの変更を期待 • ロードバランサや DNS, 機能フラグなどアーキテクチャでの解決を検討 Environment: API_ENDPOINT: 10.0.0.5 NEW_FEATURE: on IaC のパラメータはデプロイ時にのみ更新されるため更新タイミングが意図通りであるか検討

rights reserved. テンプレートによるガバナンスのアイデアを活⽤するツールのコンセプトと特性を理解することでコードを改善する Infrastructure as Code が Builder を加速させる

BLEA開発チームが学んだAWS CDKの開発プラクティス 2023年版

BLEA開発チームが学んだAWS CDKの開発プラクティス 2023年版

More Decks by Kenji Kono

Other Decks in Technology

Featured

Transcript