© 2022, Amazon Web Services, Inc. or its affiliates. © 2022, Amazon Web Services, Inc. or its affiliates. Baseline Environment on AWS (BLEA) 開発にあたって検討したこと AWS CDK Conference Japan ⼤村 幸敬 Amazon Web Services Japan Senior Solutions Architect 2022/04/09

© 2022, Amazon Web Services, Inc. or its affiliates. ⼤村 幸敬（おおむら ゆきたか） 部⻑ / シニア ソリューションアーキテクト • これからクラウドを使いはじめる エンタープライズ企業をサポート • 運⽤系サービス & DevOps 系サービスをリード • Baseline Environment on AWS (BLEA) 開発者 好きなAWSのサービス︓ AWS Command Line Interface (CLI) AWS Cloud Development Kit (CDK) AWS Systems Manager Incident Manager @yktko 2

© 2022, Amazon Web Services, Inc. or its affiliates. 私とCDK https://qiita.com/advent-calendar/2021/aws-cdk 3

© 2022, Amazon Web Services, Inc. or its affiliates. アジェンダ 1. Baseline Environment on AWS 開発の⽅向性 1. What is BLEA 2. BLEAの開発⽅針 2. これから CDK を使う⽅へのナレッジ 1. CDKを使うのは難しそう 2. CDKのL2 Constructがない / CFnを使いたい 3. やっぱりYAMLがいい 4. ⼿でやった⽅が楽 3. すでに CDK を使っている⽅へのナレッジ 1. cdk deploy の認証情報を持ちたくない 2. パラメータを切り替えて使うには 3. パイプラインをどうデザインするか 4. 複数のCDKプロジェクトをどう管理するか 4

© 2022, Amazon Web Services, Inc. or its affiliates. 本⽇の内容 話すこと • BLEA 開発中に検討した、AWS CDK 開発における 設計⽅針、実装⽅式、開発者が知っておくべきこと • これは BLEA 開発の⽬的で検討した内容であり ⼀般的なベストプラクティスはありません 考え⽅を共有することで 皆さんがよりよい選択をする⼀助になればと思っています 話さないこと • AWS CDKそのものの詳しい解説 • BLEAそのものについての解説 5

© 2022, Amazon Web Services, Inc. or its affiliates. © 2022, Amazon Web Services, Inc. or its affiliates. Baseline Environment on AWS 開発の⽅向性 6

© 2022, Amazon Web Services, Inc. or its affiliates. Baseline Environment on AWS (BLEA) AWSのセキュリティベストプラクティスを実装した オープンソースのサンプルテンプレート 特徴 • 基本的なセキュリティを設定するテンプレートと ゲストシステムのサンプルテンプレートを提供 • AWSのセキュリティベストプラクティスに準拠 • AWS Cloud Development Kit (CDK) コード 参考となるスニペット、コメント、リファレンスを豊富に記載 • チームによる⻑期的な利⽤を想定 CDK標準ライブラリのみを使ったシンプルな実装 利⽤者が理解しやすいよう過度な作り込みを避ける https://github.com/aws-samples/baseline-environment-on-aws ガバナンス ベース （基本的なセキュリティ） ゲストシステム サンプル AWS Account BLEAが提供するテンプレート CDK CDK 7

© 2022, Amazon Web Services, Inc. or its affiliates. Q: なぜ BLEA は AWS CDK を使うのか︖ • 記述量が少なくシンプルで理解しやすいコード（CloudFormation ⽐） • ⻑期にわたる安全な運⽤には引き継ぎしやすいコードが必要 • テンプレートをブラックボックスにしない • 開発上の利点が多い • AWSのベストプラクティスがライブラリに含まれておりコードの記述量が少なく済む • ⼀般のプログラミング⾔語（TypeScript）であるためオブジェクト参照が明快 • エディタによる強⼒なサジェストがあるため実装中の誤り混⼊を少なくできる • 実績のある CloudFormation によりデプロイされる • CDKの学習コンテンツとしての利⽤ • インフラエンジニアは TypeScript 開発未経験者であることも多いため、 環境構築も含めた 1st step ガイドやドキュメントを提供する • よく利⽤する CDK コードの書き⽅やコメントやリファレンスを多く記載 • BLEA 独⾃クラスは極⼒作らず、CDK の基礎知識と標準 API リファレンスを読めば、 必要な部分をコピペしつつ開発を開始できるように実装 8

© 2022, Amazon Web Services, Inc. or its affiliates. コードサンプル (ALB アクセスログの設定） ALB のアクセスログ設定（やや特殊な書き⽅） 特殊な設定の理由（security best practice準拠）、 ⼀般的な設定のやり⽅、およびリファレンス ログ出⼒に必要な特殊権限とその書き⽅ (RegionInfo の使い⽅） 9

© 2022, Amazon Web Services, Inc. or its affiliates. © 2022, Amazon Web Services, Inc. or its affiliates. これからCDKを使う⽅へのナレッジ 10

© 2022, Amazon Web Services, Inc. or its affiliates. 課題: CDKを使うのは難しそう BLEAでの解決策: • 開発環境を⽤意するまでの障壁をできるだけ⼩さくする • 想定開発環境をVisualStudio Codeに限定 • 開発環境設定ファイルや初期⼿順を提供する 実際にいただいたユーザーの声: • TypeScriptやPythonのコードを書いたことがない • npmやlintなどアプリ開発系の知識がよくわからない • なんか強い開発環境の整備が必要で複雑そう • メモ帳とか、さ○○エディタとか、秀○でやりたい https://bit.ly/3CUIxQY 11

© 2022, Amazon Web Services, Inc. or its affiliates. 参考: BLEAでのVSCode Extensions利⽤ VSCode EditorConfig Prettier ESLint VSCode Extensions BLEA での推奨テキストエディタ 各種ツールとの連携機能を有する 関連ファイル .vscode/extensions.json テキストエディタの インデントや改⾏コードなどを⾃動設定 関連ファイル .editorconfig JavaScript, TypeScript などの コードフォーマッター 関連ファイル .prettierrc.json JavaScript, TypeScript に対し 静的チェック (Lint) を実⾏ 関連ファイル .eslintrc.json 開発者間の設定差異による 無⽤な差分の発⽣を抑制 かっこの前後のスペースや改⾏位置など 開発者ごとの書き⽅の差異を吸収。 ⼿動でフォーマットを調整する⼿間を削減 静的チェック (コードを実⾏しない構⽂解析) により潜在的なバグを予防し ベストプラクティスを適⽤ ※ VSCode 以外のテキストエディタを使⽤する場合は、下記ツールとの連携をサポートするものをご選択ください 12

© 2022, Amazon Web Services, Inc. or its affiliates. 課題: CDKの L2 Construct がない / CFnを使いたい BLEAでの解決策: • L1 Constructを積極的に使う • CFnをインポートする 考え⽅ • CFnリソースがある = L1 Construct がある • L1 Construct のコードでサジェストが使える • ＝ CFnをYAMLで書くよりエラー訂正が強⼒ / リファレンス参照が減る • L1 Constructでコード書いてCFnテンプレートを⽣成して使うとか • cloudformation-includeモジュールでCFnテンプレートや既存の環境を変更 せずCDKで管理できる https://bit.ly/3LJERW2 https://bit.ly/3Jf77yg 13

© 2022, Amazon Web Services, Inc. or its affiliates. 課題: やっぱりYAMLがいい BLEAでの解決策: • ロジックを書かずコンストラクタとメソッドだけ使う • 独⾃の Construct を作らず標準ライブラリのみ使う 考え⽅ • CDKのコードはリソースの⽣成と相互参照がほとんど • ロジックや継承などを使わなければYAMLと同様 • そのうえ、⽂字列だけで相互参照するYAMLに対し メソッドやプロパティでアクセスする⽅が ⾒通しがよい • そもそもロジックが複雑なコードは構成管理には不向き （コードと実体の対応がわかりにくい） 14

© 2022, Amazon Web Services, Inc. or its affiliates. 課題: ⼿でやった⽅が楽 BLEAでの解決策: • 実施回数が少なく、⼿順がシンプルいなら⼿でやる • 過度なカスタムリソースコード (Lambda) 作成はしない 考え⽅ • Organizations全体での有効化が簡易なサービス • SecurityHub / GuardDuty / SystemsManager QuickSetup etc. • Organizationsやアカウントにつき1回しかない操作 • カスタムリソースを作ってLambdaとAPIで実装してもよいが メンテナンス負荷のほうが⼤きい https://bit.ly/3jgsvbJ 15

© 2022, Amazon Web Services, Inc. or its affiliates. © 2022, Amazon Web Services, Inc. or its affiliates. すでにCDKを使っている⽅へのナレッジ 16

© 2022, Amazon Web Services, Inc. or its affiliates. 課題: cdk deploy の認証情報を持ちたくない BLEAでの解決策: • AWS SSOを使う(credentials fileでなく) 設定⽅法 1. ~/.aws/configにSSOログイン⽤プロファイルを設定 2. aws sso login コマンドで AWS SSO画⾯でID/PW/MFAトークン を⼊⼒してログイン 3. 以後cdkコマンドが利⽤可能 注: 2022年3⽉の v2.18.0 で、AWS SSOの認証情報が、CDKから直接利⽤可能になりました︕ $ aws sso login $ cdk deploy GitHub Local Permanent API Key Target Account Target Account AWS SSO SSOを使うパターン creedentials fileを 使うパターン $ cdk deploy [profile mytarget] sso_start_url = https://d-deadbeef00.awsapps.com/start sso_region = ap-northeast-1 sso_account_id = 012345678912 sso_role_name = AWSAdministratorAccess region = ap-northeast-1 ~/.aws/config $ cd usecases/base-ct-guest $ npm run build $ aws sso login --profile mytarget （ここでブラウザが開くのでログイン） $ npx cdk deploy -c environment=myenv --profile mytarget Stack BLEA-BASE-ConfigRule (略) 実⾏例 https://bit.ly/3NXZcJ0 17

© 2022, Amazon Web Services, Inc. or its affiliates. 課題: パラメータを切り替えて使うには BLEAでの解決策: 1. cdk.json の contextに設定値グループを保持 2. cdk コマンドの –c (--context) オプションでグループを指定 3. CDK コードでパラメータを取得して利⽤ cdk.jsonの例 https://bit.ly/3JkMWyX 18

© 2022, Amazon Web Services, Inc. or its affiliates. パラメータ挿⼊: BLEAでの考え⽅ Context • デプロイ対象に紐づくパラメータ情報。これをメインで使う • アカウントとリージョンを指定しない場合は環境変数に従う • 開発環境などデプロイ先を限定したくない場合に使⽤ • デプロイ先アカウントとリージョン(env)を指定可能 • コンテキスト値とそのデプロイ先のセットを記録 • --profile のアカウントxリージョンと⼀致しない場合はエラーになる (fool proof) 環境変数 (Process.env) • profileで指定したアカウントとリージョンの取得に使う Parameters • CFnテンプレートに渡すパラメータ Synth後、デプロイ時に値を変えるのに使えるが通常は使わない https://docs.aws.amazon.com/ja_jp/cdk/v2/guide/parameters.html cdk.jsonの例 19

© 2022, Amazon Web Services, Inc. or its affiliates. 検討: パラメータについてあれこれ • そもそもパラメータで切り替えるのがよいのか︖ • コードの中に複雑な条件分岐が発⽣する可能性 • コード⾃体を環境ごとに分けてパラメータを埋め込む⽅が良い︖ • パブリックに公開するコードにパラメータを載せられない • BLEA開発環境⽤のパラメータをどこに置くか︖ • cdk.context.json, ${HOME}/.cdk.json, SSM ParameterStore, S3... • パラメータの型チェックができない & JSONは⾯倒 • 独⾃の設定ファイルを読み込む⽅式にするか︖ • しかし実装が複雑に... • CDKのデフォルトライブラリには（まだ）存在しない https://bit.ly/3LOH1Ur 20

© 2022, Amazon Web Services, Inc. or its affiliates. 課題: パイプラインをどうデザインするか BLEAでの考え⽅ (with CDKPipelines) 21

© 2022, Amazon Web Services, Inc. or its affiliates. 課題: パイプラインをどうデザインするか BLEAでの考え⽅（まとめ） • CI/CD実現のため⼿元PCからでなくパイプラインからデプロイ • Dev環境は⼿元PCを使って任意のアカウントへ気軽にデプロイ • Staging、Prod環境は既定アカウントへパイプラインでデプロイ • ターゲットスタックの検証はDev環境で パイプライン⾃体の検証はStaging環境のデプロイで⾏う • そのためstagingとprodのパイプラインは同じものを別に構成 • CDKPipelineを使う（サンプル実装として） • GitHubからStagingやProdへ直デプロイしない • GitHubはパイプラインアカウントにのみ接続 (CodeStar Connection) 22

© 2022, Amazon Web Services, Inc. or its affiliates. 検討: パイプラインをどうデザインするか 取りうる選択肢 • ターゲットスタックのどんなテストをどこで⾏うのか • Dev環境 / Staging環境 • Ownerは誰か（アカウント分割に影響） • GitHub（リポジトリ） / パイプライン / ターゲットアカウント • どこで cdk deploy を実⾏するか • ⼿元PC / GitHub / パイプラインアカウント / ターゲットアカウント • どこで CI (npm run test) を実⾏するか • ⼿元PC / GitHub / パイプライン • どこでパイプラインスタックのテストを⾏うのか • Dev環境 / Staging環境 23

© 2022, Amazon Web Services, Inc. or its affiliates. 課題: 複数のCDKプロジェクトをどう管理するか BLEAでの解決策: • リポジトリは1つでサブディレクトリでユースケースごとに分ける • パッケージ管理は NPM workspaces を使う 考え⽅: • BLEAは1つのリポジトリで多様なパターンを提供したい • 個々のユースケースは独⽴して使うのでCDKプロジェクトは別 • ユースケース内のバリエーションは異なるAppを⽤意 • node_moduleを1つだけにしたい（容量爆発対策） 検討: • アプリコードインフラ系コードをどう分けるか問題 • チーム編成 / ライフサイクル / CI/CDと品質検証の仕組み • 多くのCDKツールキットはルート直下に1プロジェクトを置くことを想定 24

© 2022, Amazon Web Services, Inc. or its affiliates. その他の検討 • セキュリティグループやIAM Policyの循環参照 • スナップショットテストはやるとして、他に何をテストするか • ALBが勝⼿にSecurityGroupを設定するのをやめさせたい • Route53とACMはCDKで管理した⽅がいいのか • CloudFrontとWAFはus-east-1で設定しないと • etc… 25

© 2022, Amazon Web Services, Inc. or its affiliates. Next step... BLEA GitHub リポジトリ https://github.com/aws-samples/baseline-environment-on-aws/blob/main/README_ja.md AWS環境にセキュアなベースラインを提供するテンプレート 「Baseline Environment on AWS」のご紹介（解説ブログ） https://aws.amazon.com/jp/blogs/news/announcing-baseline-environment-on-aws/ HowTo にいろいろ情報あります ⼿元環境構築から導⼊まで 詳しい⼿順あります 26

© 2022, Amazon Web Services, Inc. or its affiliates. まとめ 27 1. Baseline Environment on AWS 開発の⽅向性 1. What is BLEA 2. BLEAの開発⽅針 2. これから CDK を使う⽅へのナレッジ 1. CDKを使うのは難しそう 2. CDKのL2 Constructがない / CFnを使いたい 3. やっぱりYAMLがいい 4. ⼿でやった⽅が楽 3. すでに CDK を使っている⽅へのナレッジ 1. cdk deploy の認証情報を持ちたくない 2. パラメータを切り替えて使うには 3. パイプラインをどうデザインするか 4. 複数のCDKプロジェクトをどう管理するか

© 2022, Amazon Web Services, Inc. or its affiliates. Thank you! © 2022, Amazon Web Services, Inc. or its affiliates. ⼤村 幸敬 (Yukitaka Ohmura) ご質問がありましたら、Twitterで︕ @yktko または #jawsug #cdkconf へ