こんにちは、koizumi です。今回は幕張メッセにて開催されました AWS Summit Japan 2025 の参加レポートになります。

AWS Summit Japan 2025

今年は 6/25 と 6/26 の 2 日間で開催され、私は初日はオンライン参加、2 日目は現地参加してきました。アーカイブも公開されておりますので、気になる方は下記リンクからご覧になってください。

aws.amazon.com

気になったセッションのご紹介

今年の AWS Summit で、特に印象に残ったトピックの一部についてご紹介できればと思います。

サービス停止を防ぐコンテナ活用術: コンテナワークロードにおける高可用性設計の実践

紹介者：koizumi

本セッションでは、マイクロサービスアーキテクチャなどのようなコンテナ技術を活用した複雑なワークロードにおいて、可用性を確保するためのアーキテクチャ設計のポイントについて取り上げていました。

高可用性を実現する上での設計のポイントとして、以下のような点が挙げられていました。

冗長化する
- Pod を複数用意する etc
- 配置戦略がポイント
  - インスタンス、リージョン単位で分離して配置する etc
  - マルチ AZ に分散配置する
    - Pod 単位の AZ 分散配置（PTSC (pod topology spread constraints)）
      - Descheduler etc
    - インスタンス単位の AZ 分散配置
      - Managed Node Group / Cluster Autoscaler
      - Karpenter / Auto Mode はデフォルトで分散配置
    - AZ 障害が他の AZ のリソースに伝搬する可能性がある
通信の信頼性を高める
- 高速な切り離し：ヘルスチェック
- 呼び出し先のヘルスチェックをして、早期に切り離す
  - コンテナのヘルスチェック：Liveness Probe で対応可能
  - Service Discovery のヘルスチェック: Readiness Probe で対応可能
  - ロードバランサーのヘルスチェック: ターゲットグループへのヘルスチェックでルーティング対象から外すなどで対応可能
    - デフォルト 30s * 5 なので、この値をチューニングするのも大事
- サーキットブレーカー
  - 実装例としては Istio などで対応可能（Cilium も可能）
  - Istio でもサーキットブレークの設定は可能
- リトライやタイムアウトの設定

また、早期に障害範囲を切り離すことで復旧速度（MTTR）を早める対応パターンについても非常に参考になりました。

大枠 2 つの対応パターンがある
- AZ 独立性：障害分離境界により範囲障害の影響を軽減する
  - トラフィックを AZ 内に閉じることで障害を分離する
  - EKS だと、Topology Aware Routing, trafficDistribution を使うことでベストエフォートで AZ 内に閉じることができる
  - ELB ではクロスゾーン負荷分散無効化が可能
  - AZ 毎の DB 接続点は Cloud Map で設定する必要がある
- AZ 退避：早期に障害範囲を切り離す
  - 静的安定性を考慮した退避が重要
  - 分散されたデータプレーンにてフェールオーバをする
  - Application Recovery Controller のゾーンシフト
    - これ気になる
  - どうやって AZ 退避をキックするのか
    - システムメトリクスから、特定 AZ での障害を検知する
    - AWS が提供するイベント（Service Health Event とか）
デメリットとしては、設計が複雑化してしまう
- 重要な高可用性目標を持つコンポーネントやパスへの適用を検討する

Kubernetes などの複雑なワークロードを利用されている方には非常に参考になるセッションでした。気になる方はオンラインでも視聴できるので、是非ご覧になってみてください。

AWS による生成 AI のセキュリティアプローチ

紹介者：mtjune

本セッションでは AWS が生成 AI に関するセキュリティにどのようなアプローチを採っているのか、ということについて大きく3つのレイヤーに分けて紹介を行っていました。

生成 AI モデルの構築・学習のための基盤レイヤーのセキュリティについて
- AWS オペレーターが AWS 利用者のデータに触れないようになっている
  - Nitro System と呼ばれる基盤によって AWS オペレーターから AWS 利用者のデータを完全に分離
- AWS 利用者から、個人情報など機密性の高い情報に触れないようにする
  - Nitro Enclaves によって、インスタンス内に隔離された環境を作ることができる
生成 AI アプリケーション構築のためのツールレイヤー(Amazon Bedrock など)のセキュリティについて
- モデルプロバイダが行うモデルの学習に AWS 利用者のデータが使用されないことを保証している
  - モデルが推論を行うアカウント(AWS 管理)と、モデルの学習を行うアカウント(モデルプロバイダ管理)を分離することで実現
- データ・モデル・出力へのアクセスを制限する
  - IAM などのサービスを利用することで、必要最小限のポリシーをつけるようにする
  - ユーザーのリクエストに応じて AI エージェントがナレッジベースや各種ツールにアクセスする時点で認可を行い、本来触れないデータにエージェントがアクセスできないようにする
    - AI エージェント自体が、データなどのアクセスに関わるセキュリティ上の判断を行うべきではない
      - 従来の決定論的なセキュリティを用いることで、リスクが予測できるようになる
- 生成 AI の安全性の実現に Amazon Bedrock Guardrails が有用
  - 有害コンテンツの生成や不適切な質問をブロックしたり、機密情報の除去、ハルシネーションのフィルタリングなどが可能
生成 AI アプリケーションレイヤー(Amazon Q など)のセキュリティについて
- Amazon Q Business のセキュリティ
  - 管理者がガードレールを設定可能
    - 有害な応答をフィルタリング
    - 応答を企業内コンテンツに制限
      - 高い関連性の応答や、ハルシネーションの抑制につながる
  - AWS PrivateLink によって Q Business へのセキュアなアクセスが可能
  - IAM Identity Center を用いてユーザーの権限に基づいたアクセス制御も可能
  - 入力データは学習に利用されない

生成 AI のセキュリティに対して AWS がどのようにアプローチしているのか、普段は見れない AWS サービスの裏側を知ることができる非常に面白いセッションでした。セッションで紹介されていた Nitro System は基調セッションでも紹介されており、AWS 的にも特に注力しているように感じました(ブースでは Nitro Card の展示もされていました)。

セキュアなソフトウェア開発ライフサイクルのための生成 AI

紹介者：k.oshiro

できるだけ開発の初めの方でセキュリティ対策を入れることが重要（シフトレフト）
- 開発の後半からセキュリティを考えるのではなく、初めの方からセキュリティを意識する
  - Amazon Q Developer などで設計からセキュリティ対策を入れる
コード全体のセキュリティはどうするか？
- ソース管理システムに渡した後も Amazon CodeGuru Security, Amazon Inspector などでチェック
- コードの安全性、コードが依存しているライブラリの安全性を静的構成分析を行う
本番環境ではどうするのか？
- デプロイ後にもコードやパッケージが脆弱になっている可能性もある
  - Amazon Inspector を使って継続的にチェック可能
AWS からの開発者サポート
- Amazon Q Developer がどのように開発をサポートするか
- コード作成
  - Amazon Q Developer が開発環境のコンテキストを読んで、README などのドキュメントの整備を行える
  - 開発ももちろん可能
- レビューの実施
  - IDE (Visual Studio Code) からも Amazon Q Developer でのコードレビューが可能
    - 重要度などの情報が一覧でき、より詳しい内容も確認可能（リスクや修正方法など）
    - コードの修正案まで提案可能
  - GitHub などでも使用可能
- CI/CDパイプラインでのセキュリティの担保
  - Amazon CodeGuru Security が使用できる
  - CI/CD などのパイプライン上では CLI/SDK で呼び出せる
  - Amazon Inspector で統合的にコードの脆弱性を検出できる
- デプロイ後の継続的な監視
  - Amazon Inspector
    - デプロイ後も脆弱性を継続的にスキャンすることができる
    - ソフトウェア部品表（SBOM: Software Bill Of Materials）を作成できる
      - SBOM は S3 に吐き出されるので、Athena などで読み込めばクエリが可能
        
        特定のライブラリに脆弱性があった際に、どのサービスに影響があるかをすぐに調査できる
    - EC2, ECR などの脆弱性スキャンを強化できる

セキュアなソフトウェア開発を行うために生成 AI をいつ、どのように活用するか学べるセッションでした。このセッションで紹介された手法は、さまざまな AI Agent を使って取り組むことができる汎用的な内容だと感じました。一方で、Amazon Q Developer は AWS アカウントのコンテキストを考慮できるということで、ぜひ使ってみたいと感じました。