クラスメソッドのCDK事情大公開スペシャル#3 で「CDKを使ったPagerDuty連携インフラのテンプレート化」というテーマで登壇しました
2025.02.272025/02/21 にクラスメソッド日比谷オフィスで開催された勉強会イベントクラスメソッドのCDK事情大公開スペシャル#3 で「CDKを使ったPagerDuty連携インフラのテンプレート化」というテーマで登壇しました。今回の勉強会はJAWS-UG CDK支部とコラボです。
登壇資料
要約すると、複数プロジェクトに同じインフラ構成を加える場合、同じ内容のCDKのコードを何度も書くよりCFNテンプレート使った方が良い、といった内容です。
クイック作成リンクやPagerDutyについても紹介できたのは良かったです。Xでも「PagerDuty気になる」や「クイック作成リンク、初めて知った」などのツイートをして頂き嬉しかったです。
x.com #jawsug_cdk since:2025-2-21
補足
Xで疑問点をいくつか挙げて頂いているので、ここで登壇資料について少し補足します。
Lambdaを利用してPagerDuty連携した理由
PagerDutyでは700種以上のプラットフォームとインテグレーション(アラート連携)するための機能がサポートされています。今回のようにPagerDutyのAPIを呼び出さなくても、Webhookの設定のみで連携できるようなプラットフォームもあります。
しかし今回は、Lambdaを使ってアラートに関連するログ情報をCW Logsから取得、整形してPagerDutyにログ情報を伝えています。これにより、詳細なログ情報を含むインシデントをPagerDuty上で作成できます。外出先でもスマホアプリからインシデントの詳細まで確認できます。
各環境にLambdaを作った理由
また共通基盤的に一つのLambdaだけを作成することも検討しました。しかしCW Logsからログ取得することを考えると、一つのLambdaがクロスアカウントに複数の環境からログ取得してくることになります。セキュリティ的な観点から各環境にLambdaを配置した方が良いと思いました。
クイック作成リンクはアカウントを跨いでも利用可能か
S3バケットの権限管理が手間ですが、利用可能です。クイック作成リンクはS3バケットに配置されたCFNテンプレートを利用します。クイック作成リンクを利用するアカウントがS3バケットへのアクセス権を持っていなければいけません。バケットポリシーで特定のアカウントにアクセス許可するか、バケットをパブリックにすればどのアカウントでも利用可能です。
関連ブログ
登壇内容の元ネタとなった自分のブログです。
![[AWS CDK] AWS WAFで同一のIPアドレスから同一のURIパスに複数回アクセスがあった場合にブロックするレートベースルールを設定してみた](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-8cc2be5d32f2b7e78f85a99d463f3690/6213c0b16f198b77794266f22dc8eb5c/aws-waf)
