Zenn
📘

開催報告 Ops-JAWS Meetup34 Organizations & ControlTower

に公開
AWS
organizations
Control Tower
OpsJAWS
idea

こんにちは。
ご機嫌いかがでしょうか。
"No human labor is no human error" が大好きな吉井 亮です。

2025年4月16日に Ops-JAWS Meetup34 Organizations & ControlTowerを開催しましたので報告します。
セッションの要約は NotebookLM を使用して作成しました。

イベントページ

https://opsjaws.connpass.com/event/348813/

※ 登壇資料はイベントページに添付されています。

posfie

https://posfie.com/@YoshiiRyo1/p/e45oCNC

YouTube

https://youtube.com/live/RGRxzxX2Uaw

有志によるイベントレポート

https://qiita.com/mob_engineer/items/59af15a6c050734f94d9

タイムテーブル

時間 内容 登壇者
19:00 - 19:05 オープニング OpsJAWS 運営一同
19:05 - 19:45 AWSのマルチアカウント管理 ベストプラクティス最新版 2025 大村 幸敬 (@yktko) 様
須田 聡 (Suda, Satoru) 様
19:45 - 19:55 Q&A 調整中
19:55 - 20:00 休憩＆バッファ 休憩
20:00 - 20:10 クォータ監視、AWS Organizations環境でも楽勝です✌️ 岩本隆史 (@iwamot) 様
20:10 - 20:20 AWS Control Towerを数年運用してきての気づきとこれから 中村　匡志 様
20:20 - 20:30 コスト、カオス、権限　AWS Organizations 小ネタ3選 高橋 修一 様
20:30 - 20:40 Organizations環境の証跡管理に「CloudTrail Lake」をおすすめする理由 あしさん（芦沢広昭）様
20:40 - 20:50 AWS Organizations下でのカスタムリソースの使い方 西内　渓太 様
20:50 - 締め＆バッファ OpsJAWS運営一同

AWSのマルチアカウント管理 ベストプラクティス最新版 2025

先日開催されたJAWS-UG Ops-JAWS Meetup #34の冒頭、AWSシニアソリューションアーキテクトの大村様とシニアセキュリティコンサルタントの須田様による「AWSのマルチアカウント管理 ベストプラクティス 最新版2025」と題したセッションについて、内容を要約してご報告します。

セッションの目的と概要

本セッションは、今年のAWS Summitにマルチアカウント管理、特にバランスに関するセッションがないことを背景に、最新のベストプラクティスを共有するために企画されました。2時間相当の内容を凝縮し、前半は大村様よりベストプラクティスの概要、後半は須田様より実践的な事例紹介が行われる予定であることが冒頭で説明されました。

マルチアカウント管理の必要性とアカウントの利点

セッションでは、顧客がAWSに求めるものは単なるインフラではなく、ビジネス価値の創出、迅速なアイデア実現、セキュアでコンプライアントな環境であることが強調されました。これらの要求を実現するためには、ビジネス要件の変更への対応、費用対効果、スケーラビリティ、そして組織のセキュリティと監査要件への適合が不可欠であり、その上でAWSアカウントを適切に活用することの重要性が語られました。

アカウントの主な利点として、以下の4点が挙げられました:

  • 環境の切り替え: 開発、テスト、本番などの環境をアカウントで分離できる。
  • 請求の明確化: 各アカウントの利用状況を個別に把握できる。
  • アカウント外からのガバナンス適用: アカウントに対して一元的にセキュリティやポリシーを適用できる。
  • ワークロードの分離: システムごとにアカウントを分けることで、他のシステムへの影響を防止できる。

Landing ZoneとControl Tower

マルチアカウント管理においては、スケーラブルでセキュアなマルチアカウント環境である「Landing Zone」 を用意することが推奨されています。ここで重要なのは、Landing Zoneは特定のサービスを指すのではなく、そのような環境全体の概念であるということです。

AWS Control Towerは、このLanding Zoneを実装するための具体的な方法の一つであり、比較的推奨されるアプローチであると説明されました。Control Towerは、AWS Organizations、AWS Config、AWS CloudTrailといった基本的なAWSサービスを組み合わせて構築されており、最小限のLanding Zoneを迅速に立ち上げるのに適しています。

現在の最新状況として、Landing Zoneで実現すべき機能や実装方法はここ数年で大きな変化はなく、安心してControl Towerを利用できるというメッセージが強調されました。AWSもマルチアカウント管理においてはControl Towerを強く推奨しており、その方向性に合わせることで、長期的に安定した環境を構築できると考えられています。

Landing Zoneの主要な6つの機能

セッションでは、Landing Zoneが持つべき主要な機能として以下の6つが紹介され、それぞれの概要が説明されました:

  1. マルチアカウント構成: AWS OrganizationsのOU（Organizational Unit）やアカウントの配置設計。社内の組織構造に無理に合わせる必要はなく、セキュリティと運用上の要件が近いアカウントを同じOUにまとめることが推奨されました。また、深いOU構造は必ずしも必要なく、小さく始めて必要に応じて拡張していくアプローチが推奨されています。
  2. アカウントの払い出し（アカウントファクトリー）: Control Towerを利用することで、AWS Service Catalogを用いたアカウント払い出しの仕組みが構築できます。利用者がセルフサービスでアカウントを払い出すような仕組みの実現には、現状カスタム開発が必要であること、払い出したアカウントへの初期設定（ベースライン）の適用方法と責任範囲についても議論されました。
  3. セキュリティのベースライン: アカウント払い出し時に適用する基本的なセキュリティ設定。AWS Security Reference Architecture (SRA)が紹介された上で、最初から完璧を目指すのではなく、基本的なセキュリティを確立し、AWS Security Hubなどの発見的統制を組み合わせることが推奨されました。予防的統制と発見的統制のバランスも重要であると指摘されました。
  4. ログイン情報の管理: Control TowerではAWS IAM Identity Center（旧AWS Single Sign-On）が利用されます。フェデレーションの活用も推奨されており、具体的な内容は後半の実践編で触れられる予定です。
  5. ログの集約: Control Towerを導入すると、AWS CloudTrailとAWS Configのログが一元的に集約されます。集約を強制することの重要性、およびメンバーアカウントからのログ閲覧に関する課題と、その解決策が実践編で示唆されました。
  6. コスト管理: Control Tower自体には高度なコスト管理機能はないため、AWS Cost Explorer、AWS Cost Usage Dashboard、AWS Cloud Intelligence Dashboardなどの既存のコスト管理ツールの利用が推奨されました。

セッションはここで、須田様による実践編の紹介と自己紹介へと続きます。

須田様のセッションでは、コンサルティングの経験に基づき、具体的な事例を交えながらマルチアカウント環境における統制の勘所や導入時の注意点が解説されました。特に、セキュリティ面に焦点を当てた内容が多く、現実的な課題とその解決策が示唆されました。

マルチアカウント統制における重要な考慮事項

まず、マルチアカウント統制を進める上で考慮すべき重要な要素として、以下の点が挙げられました:

  • 費やせる時間と人数: 各社の状況に応じて、統制にかけられる時間や人員は限られているため、現実的な範囲で始めることが重要です。
  • セキュリティ方針: 各社が持つセキュリティ方針によって、クラウド上での望ましいマルチアカウント統制のあり方が大きく変わります。

セキュリティ方針の違いによる統制アプローチの例として、「疑わしきは全て拒否」という厳格な方針の金融事業者と、ある程度の自由度を尊重しつつ事故を防ぎたい一般的な企業のケースが比較されました。 前者の場合はSCP（Service Control Policy）を積極的に活用した予防的統制が、後者の場合はAWS Security HubやGuardDutyなどの発見的統制が重視される傾向が示されました。

段階的な統制実現のアプローチ

理想的な統制を一気に実現することは難しいため、段階的にマイルストーンを設定していくアプローチが推奨されました。 一元管理の対象範囲をどこまでにするかを定め、まずは最小限の統制から始め、必要に応じて拡張していく考え方が重要であると強調されました。

Landing Zone立ち上げの順序

Landing Zoneを立ち上げる際には、以下の順序で進めることが推奨されました:

  1. ゴール、要件、統制要件などの大枠を決定する。
  2. 具体的な設計に入る。

このアプローチに基づき、統制を決定していった顧客事例が紹介されました。

  • セキュリティ統制が未成熟な顧客事例: アカウント数が多く、部門も多岐にわたるため、制限をかけずに全社で迅速にセキュリティ統制を実現したいという要望に対し、作り込みを減らし、AWSのマネージド機能を最大限に活用する設計が採用されました。 具体的には、AWS Control Towerを基本としつつ、Security HubやGuardDutyのOrganizations連携を直接利用するなどの工夫が紹介されました。
  • BLEA を活用した顧客事例: 複数のOrganizationsや所属していないアカウントが存在する状況で、統一的な統制を実現したいという要望に対し、BLEA（AWS環境設定・管理ツール） が活用されました。 まずPoC（Proof of Concept）で開発担当者が設計を検討できるようベースラインを迅速に構築し、運用担当者のスキルレベルを考慮して、CDKではなくブレアのコマンドでService Catalogにテンプレートを登録し、アカウントファクトリーカスタマイゼーションにブレアのパッケージを組み込む運用方法が採用されました。 Security Hubなどのマネージド機能との組み合わせも重要であるとされました。
  • CfCTを活用した顧客事例: 開発力が高く、IaC（Infrastructure as Code）に抵抗がない顧客に対し、Customize for Control Tower (CfCT) というAWS提供のオープンソースツールが採用されました。 柔軟なカスタマイズが可能であり、顧客自身がベースラインを発展させていきたいという要望に合致しました。 ログ集約に関して、Control Towerの標準機能では対応しきれない要件に対し、CfCTを活用してメンバーアカウントに直接設定を組み込むなどの工夫が紹介されました。

マルチアカウント統制における共通的な検討事項

事例紹介に加え、マルチアカウント統制を進める上で共通的に考慮すべき事項として、以下の点が解説されました。

  • OU構成: 組織構造に無理に合わせるのではなく、統制要件に基づいて第1階層を決定し、ワークロードの特性に応じて第2階層以下を構成する考え方が示されました。 セキュリティベースラインのパターンを分ける意味のある軸でアカウントを分類することが重要であるとされました。
  • アカウント移行: 既存アカウントをControl Tower環境に移行する際の課題と注意点が説明されました。 特に、既に統制機能が導入されている場合は、移行による影響を慎重に評価する必要があるとされました。
  • ID管理: AWS IAM Identity Center（旧AWS Single Sign-On）の利用だけでなく、既存のID管理システムとの連携（フェデレーション）や、認証と認可の分離など、柔軟なID管理戦略を検討することが推奨されました。
  • コスト: Landing Zone自体で発生するコストに加え、ワークロードによってコストが変動するため、予測が難しい側面があることが指摘されました。 複数の仮説に基づいた予測と、実績との比較による予測の修正が現実的なアプローチとして提案されました。

クォータ監視、AWS Organizations環境でも楽勝です

本セッションでは、AWSリソースのクォータ監視の重要性と、AWS Organizations環境における効率的な監視方法について、具体的なソリューションを用いて解説されました。

クォータ監視とは？なぜ重要なのか

岩本様は、まずクォータ監視とは、リソースの使用量が上限に近づいた際に検知する仕組みであると説明されました。例えば、RDSのDBインスタンス数のデフォルト上限は40件ですが、急なデータ分析などで41個目を立てようとした際にクォータに引っかかる可能性があります。その際、引き上げリクエストを送ることはできますが、即座に対応されるとは限らないため、早期にクォータの状況を把握しておくことが重要です。

クォータ監視は、AWS Well-Architected Frameworkの信頼性の柱におけるベストプラクティスの一つとしても挙げられており、リソースのモニタリングと管理が推奨されています。

Organizations環境でのクォータ監視

本題として、AWS Organizations環境におけるクォータ監視の方法が紹介されました。岩本様は、「Quota Monitor for AWS」の活用を推奨されました。

このソリューションは、以下のシナリオに対応しています:

  • Organizationsを使用している環境（シナリオ1）
  • Organizationsを使用しているが、独立したアカウントが存在するハイブリッド環境
  • シングルアカウント環境

Organizations環境の場合、シナリオ1を選択します。導入手順として、以下のステップが紹介されました:

  1. Organizationsのフル機能をアクティブ化する。
  2. AWS CloudFormation StackSetsの委任管理者を設定する。
  3. 委任したアカウントで、Organizations用のスタック（ハブスタック）を起動する（CloudFormationテンプレートを実行する）。
  4. スタック起動後、AWS Systems Manager Parameter Storeに作成されるパラメータを設定する:
    • 監視対象のリージョン（カンマ区切りで指定可能）
    • 監視対象のOU ID（カンマ区切りで指定可能）
    • Slack通知を行う場合のWebhook URL
  5. 運用開始後、設定した閾値を超過した場合に通知が送信されます（Slackへの通知例が提示されました）。

ノイズ対策とミュート機能

「Quota Monitor for AWS」は非常に便利である一方、引き上げが不可能なクォータの通知も送信される場合があることが指摘されました。これに対する対策として、ミュート対象のクォータをパラメータで設定できる機能が紹介されました。サービス名とミュートしたいクォータ名をコロンで区切り、カンマ区切りで指定することで、不要な通知を抑制できます。

AWS Control Towerを数年運用してきての気づきとこれから

本セッションでは、2021年9月からAWS Control Towerを継続して3年半運用している経験に基づいたお話が展開されました。予防的統制、発見的統制、訂正的統制をAWSのマネージドサービスで実現しており、サードパーティ製品は利用していないとのことです。詳細についてはAWSブログでも紹介されているそうです。

Control Towerのメリット

中村様は、AWS Control TowerはAWSのベストプラクティスなセキュリティ環境をネイティブに利用できる点を高く評価されており、「すごい素晴らしい」と述べられています。特に、Organizationsを最初から利用することが推奨され、既存環境への後からの適用は手間がかかる可能性があると指摘されました。

セキュリティに関しては、Security Reference Architectureのドキュメントが非常に有益であり、Control Tower導入・運用においても参考になると紹介されました。

運用面では、アカウントファクトリー機能を利用してセキュリティのブループリントを簡単に展開できる点がメリットとして挙げられました。また、現在ではTerraformでの展開も可能になっているため、より柔軟な運用が期待できるとのことです。

コストに関しても、サードパーティ製品と比較して運用コストが優れていると感じているそうです。メンバーアカウント側の課金は預金額の数%程度であり、これによりガバナンスを実現できるのは大きな利点だと述べられました。

Control Tower運用上の課題

一方で、Control Towerの運用にはいくつかの課題も存在すると指摘されました。

  • Landing Zoneアップデートに時間がかかる：アカウント数が多い環境では、アップデートにかなりの時間を要することがあるそうです。
  • 関係部署との調整: 機能追加のためには関係部署との調整が必要となり、その工数も無視できないとのことです。
  • 意図しない課金: アップデートによって意図しない課金が発生するリスクがあり、影響確認の重要性が強調されました（例：CloudTrailのログ出力先変更による高額課金）。
  • ドリフト状態: CloudFormation Stack Setsで動作しているControl Towerの設定を誤って変更するとドリフト状態になり、その修正に手間がかかることがあるそうです。
  • コスト共有: クレジット、Savings Plans、Reserved Instancesの共有においては、支払い主体が複数いる場合に考慮が必要であり、安易な共有は避けるべきだと述べられました。

今後の展望

中村様は今後、以下の点に取り組んでいきたいと語られました。

  • リソースコントロールポリシー（RCP）と制限型ポリシーの活用
  • S3のSSE-Cによる暗号化の禁止（ランサムウェア対策として）
  • Instance Metadata Service V1の撲滅（セキュリティリスク軽減のため）
  • IAM Identity Centerの活用: Amazon Q DeveloperのProプラン利用を見据えて、Identity Centerを使いこなせるように取り組んでいきたいとのこと。現状、複数の外部IDプロバイダーを接続できない制限があるため、その解決も目指しているそうです。

コスト、カオス、権限　AWS Organizations 小ネタ3選

本セッションでは、AWS Organizations環境におけるコスト分析、カオスエンジニアリング、そして管理アカウントの権限抑制に関する実践的な小ネタが紹介されました。

セッション概要

高橋様のセッションは、以下の3つのテーマで構成されていました:

  1. OU単位でのコスト分析
  2. SCPでお手軽カオスエンジニアリング
  3. 管理アカウント上の権限抑制

1. OU単位でのコスト分析

高橋様は、AWSのCost Categoriesという機能を利用して、AWSの利用料金をカスタマイズしたカテゴリに分類し、コストを可視化する方法を紹介されました。通常はアカウント単位で分類できますが、Organizationsを利用している場合に、OU（組織単位）の階層でコストを可視化したいと考え、それを実現するためのスクリプトを作成されたそうです。

  • AWS SDKを用いてOrganizationsのOU構造を取得します。
  • 取得したOU構造をCost Categoriesの定義に変換します。
  • AWS CLI/SDKを通じてCost Categoriesを登録・更新します。

実際に作成されたスクリプトにより、OUの第一階層でのコスト分析だけでなく、より深い階層での分析も可能になり、OUという断面でコストの傾向や偏りを把握できるようになりました。このスクリプトはGitHubで公開されています。

2. SCPでお手軽カオスエンジニアリング

次に、SCP（Service Control Policies） を利用した簡易的なカオスエンジニアリングの手法が紹介されました。

  • 実験対象のアカウントを、権限を奪うSCPをアタッチした観察用のOUに移動させます。
  • ワークロードがどのように影響を受けるかを観察します。
  • 観察後、アカウントを通常のOUに戻します。

実験対象として、社内のメールフィルタリングサービスの開発環境用アカウントが使用されました。このサービスは、SESで受信したメールをS3に格納し、Lambda関数で処理・フィルタリングを行い、SNSを通じて通知を行う仕組みです。

SCPでサーバーレス関連の権限を奪った結果、変換処理を行うLambda関数がS3からメールの生データを取得する際にアクセスエラーが発生しました。これは、SCPがIAMユーザーとロールの権限に影響を与えるためです。

この手法のメリットとして、外部から意図的に異常を注入でき、テストが容易で、元に戻しやすい点が挙げられました。将来的には、RCP（Resource Control Policies）や専念型ポリシーでの同様の実験も検討されているとのことです。

3. 管理アカウント上の権限抑制

最後に、管理アカウントにおける権限抑制のアイデアが紹介されました。管理アカウントは権限が集中しており、SCPなどのコントロールの対象外となるため、セキュリティ上の注意が必要です。

対策として、可能な限りメンバーアカウントへの権限委譲と、管理アカウントへのアクセス機会の削減が基本となりますが、委譲しきれないケースに対して、IAMロール作成時のパーミッションバウンダリーの適用を強制する仕組みが紹介されました。

  • IAMロールを作成する際に、特定のパーミッションバウンダリーを付与することを条件とします。
  • 同時に、作成したロールのパーミッションバウンダリーを後から削除・更新することも禁止します。

これにより、管理アカウント上で作成されるIAMロールに意図しない強力な権限が付与されるのを防ぐことができます。このテクニックはメンバーアカウントでも利用可能ですが、管理アカウントの機密性を考慮すると特に有効であると述べられました。

Organizations環境の証跡管理に「CloudTrail Lake」をおすすめする理由

本セッションでは、AWS Organizations環境におけるCloudTrailの管理における課題と、その解決策としてのCloudTrail Lakeの利点と注意点が解説されました。

CloudTrailとその管理

CloudTrailは、AWSアカウント内のAPIアクティビティをイベントログとして記録・保存するサービスであり、AWSの監査やガバナンスの基本となるものです。

マルチアカウント環境におけるCloudTrailの管理では、以下の設定がよく用いられます:

  • 証跡: CloudTrailのイベントをS3などの永続ストレージに出力する設定。デフォルトでは90日間しか保存されませんが、証跡により長期間の保存が可能になります。
  • 組織の証跡: Organizations環境において、組織内の全アカウントに証跡の設定を複製する機能。

しかし、従来のCloudTrail管理にはいくつかの考慮すべき点があります。特に統制の面では、CloudTrailの取得設定が勝手に変更されることを防ぐ必要があります。また、ログの集約や分析、コスト管理なども課題となります。

CloudTrail Lakeの提案

芦沢様は、これらの課題を解決するソリューションとしてCloudTrail Lakeを提案されました。CloudTrail Lakeは、組織全体のイベントデータをイベントデータストアと呼ばれる一元的な場所に集約し、保管・分析できるサービスです。

CloudTrail Lakeの利点

CloudTrail Lakeの主な利点は以下の通りです:

  • イベントデータストアによる一元管理: Organizations全体のCloudTrailイベントを1つの場所で管理できます。これにより、複数アカウントに分散したログを個別に管理・分析する手間が省けます。
  • 柔軟なデータ保持期間と料金体系: 7年間または1年間の保持期間を選択でき、データ取り込み量に応じた料金が発生します。S3のように別途ストレージ費用がかかることはありません。
  • 強力なクエリ機能: SQLに似たクエリ構文（CloudTrail Lake クエリ）を使用して、集約されたイベントデータを効率的に検索・分析できます。内部的にはAmazon Athenaと同じエンジンを使用しています。
  • コストの最適化: イベントデータの取り込みとクエリ実行に対してのみ料金が発生し、イベントデータストアの管理アカウントのみに課金されます。メンバーアカウント側で予期せぬコストが発生する心配がありません。

CloudTrail Lakeの懸念点と今後の展望

一方で、CloudTrail Lakeにはいくつかの懸念点もあります:

  • 料金: 特に長期間のデータ保持（7年間）を選択した場合、料金が高くなる可能性があります。
  • リソースベースポリシー: 現時点では、イベントデータストア単位でのみアクセス制限が可能であり、S3のバケットポリシーのように、パス単位での詳細なアクセス制御はできません。
  • クエリ構文の日本語サポート: クエリ構文が英語のみであるため、日本語でのサポートが待望されています。

AWS Organizations下でのカスタムリソースの使い方

本セッションでは、AWS Organizations環境におけるCloudFormationカスタムリソースの活用方法、注意点などが解説されました。

CloudFormationカスタムリソースとは

CloudFormationカスタムリソースとは、CloudFormationテンプレートにカスタムのプロビジョニングロジックを記述し、スタックの作成、更新、削除時にそのロジックをCloudFormationに実行させることができる機能です。これは、CloudFormationの組み込みリソースタイプでは表現できない複雑なロジックやワークフローが必要な場合に役立ちます。

カスタムリソースは、Amazon SNSまたはAWS Lambdaを使用して実装でき、一般的にはLambdaがより多く利用される傾向にあるとのことです。

オーガニゼーション図鑑におけるカスタムリソースのユースケース

西内様は、AWS Organizations環境におけるカスタムリソースのユースケースとして、以下の点を挙げられました。

  • CloudFormation未対応のリソースの作成: カスタムリソース（特にLambda）を使用することで、CloudFormationがまだ対応していないAWSリソースに対しても、API実行を通じて作成や管理が可能になります。
    • 例として、かつてSecurity HubがCloudFormationに未対応だった時期に、カスタムリソースからSecurity HubのAPIを呼び出すことで、スタックセットを通じて組織全体にSecurity Hubを有効化する例が紹介されました。
  • リソースに対するAPI実行の自動化: リソースの作成や更新後に、追加のAPI実行が必要な場合にカスタムリソースを活用できます。
    • 例として、IAM Access Analyzerのアーカイブ RuleをStackSetsで展開しているケースにおいて、アーカイブ Ruleを更新した後、ApplyArchiveRule APIを実行しないと過去の検出結果がアーカイブされないという課題に対し、カスタムリソースを利用して更新時にAPIを自動実行する解決策が示されました。

これらのユースケースは、特にスタックセットと組み合わせることで、新規アカウントに対しても同様の操作を自動的に適用できるため、マルチアカウント環境における統制強化に繋がります。

カスタムリソース利用時の注意点

西内様は、カスタムリソースを利用する上での重要な注意点として、以下の4点を強調されました。

  • 削除時の依存関係の考慮: リソース削除の際には依存関係を考慮し、適切な順序で削除を行う必要があります。依存関係のあるリソースが先に削除されると、カスタムリソースの実行がエラーとなり、スタック全体の削除が失敗する可能性があります。作成時にも同様に、依存関係に基づいた順序でリソースを作成する必要があります。
  • 更新時に動作するかどうかの考慮: カスタムリソースに関連付けられたLambda関数のロジックのみを更新した場合、カスタムリソース自体が更新されたとは認識されず、Lambda関数が実行されないことがあります。Lambda関数の変更をトリガーするには、カスタムリソースのプロパティ（例えば、日付やバージョンなどの適当なパラメーター）も合わせて更新し、テンプレートを更新する必要があります。
  • レスポンスの設定とタイムアウト設定の実施: カスタムリソースは、処理結果（成功または失敗）をCloudFormationに明示的に応答する必要があります。応答がない場合、CloudFormationはデフォルトで約1時間待機し、スタックが実行中のままになる可能性があります。Lambda関数内で適切な返却ロジックを実装するか、カスタムリソースのプロパティでタイムアウト時間を短く設定することを推奨しています。
  • クロスアカウントでのセキュリティの考慮: Organizations環境でカスタムリソースを利用する場合、デプロイ対象のアカウントと機能に適したIAM実行ロールをLambda関数に付与し、意図しない実行を防ぐための仕組みが必要です。

次回予定

Ops-JAWS 次回の予定です。

6月3週目 Meetup35 IaC

8月3週目 Meetup36 未定

10月3週目 Meetup37 未定

12月2週目 Meetup38 2025年 Ops系アップデート祭

Discussion