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

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

View Slide

⾼野賢司
ソリューションアーキテクト @名古屋
アマゾンウェブサービスジャパン合同会社
趣味
こうの
東海地⽅のこれから 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

View Slide

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

View Slide

開発に集中するための
ガバナンスのつくりかた

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

参考にした 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
AWS CDKͷ͋Δ͋Δ͓೰Έʹ౴͍͑ͨ
։ൃ࣌ͷҙࢥܾఆΛߴ଎Խ͢ΔͨΊʹ
༑Ԭ խࢤ
Prototyping Engineer
Amazon Web Services Japan G.K.
https://speakerdeck.com/
tmokmss/answering-cdk-faqs
AWS Japan で CDK を⽇々活⽤している
プロトタイピングチームの知⾒を参考にした

View Slide

ガバナンスベースの
運⽤モデル

View Slide

サービスチームによるセルフサービスモデル
• ガバナンスベースをサービスチーム⾃⾝がデプロイする、基本の運⽤モデル
• プラットフォームチームはガバナンスベースのリファレンス実装やサンプルアプリを提供
クローンしてカスタマイズ
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
配布
デプロイ
デプロイ
適したユースケースの例
• セルフサービスによる疎結合化・独⽴デプロイ性を重視
• チームによるカスタマイズとベストプラクティスの共有

View Slide

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

View Slide

CDK Pipelines からの⾃動デプロイモデル
• ガバナンスベースを CDK Pipelines によって各 AWS アカウントに適⽤
• デプロイ先 AWS アカウントを任意の粒度でグルーピング可能
aws-samples/
baseline-
environment-
on-aws
YOUR-ORG/
blea-for-
my-company
サンプル
CDK
CDK
CDK
CDK
サンプル
CDK
Security /
Infrastructure
accounts
デプロイ
BLEA v3
Pipeline account
AWS CodePipeline
CI/CD パイプラインからデプロイ
Self Mutation でパイプラインを⾃動更新
ガバナンスベースゲストシステム
• デプロイ対象のグループや段階をコントロールしたい
• 更新頻度が⾼く、常に最新のガバナンスを適⽤したい

View Slide

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
CDK
CDK
サンプル
CDK
Security /
Infrastructure
accounts
デプロイ
BLEA v3
Baseline Hub
account
AWS Service Catalog
AWS Control Tower からデプロイ
ガバナンスベースゲストシステム
• プラットフォームチームが組織全体の状況を把握したい
• 更新頻度が低く、デプロイの実⾏環境を管理したくない

View Slide

CDK アプリと
スタックの分け⽅

View Slide

マルチスタックからシングルスタックに変更
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

View Slide

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

View Slide

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

View Slide

マルチアプリからシングルアプリに変更
ユースケース* ごとに複数の 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 のサブプロジェクト（パッケージ）を指す

View Slide

Construct ID を
適切に命名する

View Slide

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 がそのまま使われる
• 物理名には - が前置され、
リソースまでの Construct のパスが
結合して使われる
※ App クラスには Construct ID がない
※ リソースごとの名前の制約に合わせて変換
されることも（⼩⽂字化、区切り⽂字の変更など）
• Stage で Stack をまとめると
さらに - が前置される

View Slide

クラスの役割と物理名を考慮した命名の例
• 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 がない場合
"環境名-" を前置

View Slide

環境ごとのパラメータ管理

View Slide

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

View Slide

環境ごとのパラメータの指定⽅法を変更
{
"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 まで

View Slide

最もミスが起こりづらい⽅法を選択
2023/05/20 AWS CDK CONFERENCE JAPAN ͋Δ͋Δ͓೰Έʹ౴͍͑ͨ
؀ڥ͝ͱʹύϥϝʔλΛઃఆ͢Δํ๏ - ൺֱද
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 ͋Δ͋Δ͓೰Έʹ౴͍͑ͨ
؀ڥ͝ͱʹελοΫఆٛΛग़͠෼͚Δํ๏
ελοΫఆٛํ๏ͷ୅දྫ (௨ৗ 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 時の認証情報とパラメータの不⼀致を避ける

View Slide

環境ごとのパラメータの指定⽅法を変更
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

View Slide

Infrastructure as Code の
コードをシンプルにする

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

Thank you!
⾼野賢司
@konokenj

View Slide

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

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

Kenji Kono

More Decks by Kenji Kono

Other Decks in Technology

Featured

Transcript