みなさん、こんにちは。ソリューションアーキテクトの戸塚です。今週も 週刊AWS をお届けします。 AWS Summitが終了し、各チームからはAWSブログを通じて、より詳しい解説が公開されています。ぜひチェックしてみてください。 私が所属する流通小売事業部のブースでは、飲食店舗などで活用できるソリューションとして、AmiVoiceと連携したデモを出展しました。こちらは、AmiVoiceを提供されているアドバンスト・メディア様との共著でブログ「 音声 AI エージェントで実現するセントラルキッチンのハンズフリーオペレーション 」として公開しています。 飲食店舗に限らず、「音声認識 × Agentic AI」を検討されている方にとって参考になる内容ですので、ぜひご一読ください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2026年7月13日週の主要なアップデート 7/13(月) Amazon SageMaker HyperPod が Slurm クラスターでカスタム AMI をサポート Amazon SageMaker HyperPod が､Slurm でオーケストレーションするクラスターでカスタム AMI (Amazon Machine Image) を利用できるようになりました｡ユーザーは HyperPod の性能最適化済みベース AMI をもとに､セキュリティエージェントやコンプライアンスツール､専用ライブラリ､ドライバーをイメージに組み込めます｡これまでライフサイクル設定スクリプトで起動後に実行していたセットアップ処理を AMI 側に取り込めるため､クラスターの起動時間を短縮でき､ノード間の構成の不整合を抑えられます｡カスタム AMI は CreateCluster / UpdateCluster / UpdateClusterSoftware の各 API で指定でき､HyperPod がサポートするすべての AWS リージョンで利用できます｡ OpenAI privacy-filter による PII 検出とマスキングが Amazon SageMaker JumpStart で利用可能に OpenAI が開発した PII 検出･マスキング用モデル privacy-filter が Amazon SageMaker JumpStart で利用できるようになりました｡テキスト中の個人識別情報 (PII) を検出する双方向トークン分類モデルで､1 回の forward pass で入力全体にラベルを付与します｡アカウント番号･住所･メールアドレス･氏名･電話番号･URL･日付･secret の 8 カテゴリを検出できます｡SageMaker Studio の Models セクションまたは SageMaker Python SDK から数クリックで自分の AWS アカウントにデプロイでき､データサニタイズ (無害化) のワークフローを構築できます｡ Voxtral-Mini-4B-Realtime をリアルタイム音声文字起こし向けに Amazon SageMaker JumpStart で提供開始 AWS は Mistral AI のリアルタイム音声文字起こしモデル Voxtral-Mini-4B-Realtime-2602 を Amazon SageMaker JumpStart で利用できるようにしました｡ このモデルは音声を逐次処理するストリーミングアーキテクチャを備え、500ms 未満の遅延で文字起こしを出力できます｡ 13 言語に対応し、文字起こしの遅延を 240ms から 2.4s の範囲で設定してレイテンシと精度のバランスを調整できます｡ SageMaker Studio の Models 画面または SageMaker Python SDK から数クリックで自分の AWS アカウントにデプロイできます｡ Gemma-4-E2B-it が Amazon SageMaker JumpStart で利用可能に AWS は 2026 年 7 月 13 日に､ Google DeepMind の gemma-4-E2B-it を Amazon SageMaker JumpStart で提供開始しました｡ このモデルはテキスト･画像･音声を入力として受け取り､ テキストを出力するマルチモーダルの指示調整済みモデルです｡ ステップごとに思考する reasoning モードを内蔵し､ 有効パラメータ 2.3B (埋め込み込みで 5.1B) という小型構成でエッジ寄りの効率的な実行に最適化されています｡ SageMaker Studio の Models セクションまたは SageMaker Python SDK から数クリックでデプロイできます｡ OpenAI GPT-5.6 Sol、Terra、 Luna が Amazon Bedrock で一般提供開始 OpenAI の GPT-5.6 ファミリー (Sol、Terra、Luna) が Amazon Bedrock で一般提供 (GA) されました｡3 モデルはフラッグシップの推論特化 (Sol)、バランス型 (Terra)、 高速低コスト型 (Luna) という 3 階層で構成され、いずれも `bedrock-mantle` エンドポイント上の Responses API 経由で利用します｡コンテキストウィンドウは 272K トークンで、prompt caching により再利用コンテキストのキャッシュ読み取りが 90% 割引になります｡料金は OpenAI の first-party レートと同等で、 利用額は既存の AWS コミットメントに算入されます｡ 7/14(火) AWS Security Hub が組織全体の AI アセットを可視化する AI インベントリの提供を開始 AWS Security Hub に AI インベントリ機能が追加されました｡ この機能は組織全体の AI アセット (エージェント､ モデル､ パイプライン) を継続的に検出し､ そのセキュリティ状態を中央のセキュリティチームが確認できるようにするものです｡ 検出は AWS Config リソース､ Amazon Inspector の SBOM 分析､ Amazon GuardDuty の DNS テレメトリという 3 つの方法で自動的に行われます｡ 検出された各アセットは基盤インフラにマッピングされ､ GuardDuty の脅威検出を含むセキュリティ検出結果と関連付けられます｡ この機能は Security Hub Essentials に含まれ､ 追加費用はかからず､ 新たな有効化操作も不要です｡ Amazon GuardDuty AI Protection を発表 (AWS AI ワークロード向け脅威検知) Amazon GuardDuty に AI Protection が追加され、 Amazon Bedrock と Amazon SageMaker AI のワークロードを対象とした脅威検知に対応しました｡CloudTrail の管理イベントとデータイベントを解析し、 異常なモデル呼び出し、 コストハーベスティング攻撃、 プロンプトインジェクションの 3 種類を検出します｡検出結果は AWS Security Hub に集約され、 AWS Organizations で組織全体に一元的に有効化できます｡GuardDuty 利用者は 30 日間の無料トライアルで利用を開始できます｡ AWS Lambda コンソールにコーディングエージェント向けワンクリックセットアッププロンプトを追加 AWS Lambda コンソールに､コーディングエージェントを 1 クリックでサーバーレス開発向けに構成するセットアッププロンプトが追加されました｡このプロンプトは AWS Serverless skills と Serverless Model Context Protocol (MCP) server をエージェントにインストールするよう指示します｡従来は複数のドキュメントを参照する必要があったエージェント設定の手間がなくなります｡Claude Code、 Kiro、 Cursor、 GitHub Copilot、 Codex、 Devin Desktop、 OpenCode の 7 種類のエージェントに対応します｡AWS GovCloud (US) を含む Lambda 提供リージョンで利用でき、 Middle East (Bahrain) と Middle East (UAE) は対象外です｡ 7/15(水) AWS Lambda が self-managed code storage に対応 AWS Lambda は､関数のデプロイパッケージをユーザー自身の Amazon S3 バケットから直接参照する self-managed code storage に対応しました｡従来 Lambda は関数や layer の作成時にコードを Lambda 管理ストレージへコピーしていましたが､`S3ObjectStorageMode` を `REFERENCE` に設定することでコピーを行わず S3 上のコードを直接参照します｡これによりコードストレージの上限が実質的に S3 バケットの容量まで拡張され､コピー処理が省かれるため関数の作成/更新後の有効化時間が短縮されます｡あわせて Lambda 管理ストレージのデフォルト上限が 75GB から 300GB per Region に引き上げられました｡self-managed code storage の利用に Lambda 側の追加料金は発生せず､S3 の標準料金のみが発生します｡ Amazon Cognito がパスワードハッシュ付きのユーザーインポートに対応 Amazon Cognito の CSV ユーザーインポートで、パスワードハッシュを含めてユーザーを取り込めるようになりました｡ 従来は CSV でインポートしたユーザーは初回サインイン時にパスワードリセットが必須でしたが、本機能によりインポート済みユーザーは既存の認証情報でそのままサインインできます｡ 対応アルゴリズムは bcrypt、scrypt、Argon2id、PBKDF2 with SHA-256 の 4 種類です｡ Amazon Cognito が利用可能な全 AWS リージョンで使えます｡ ただし、本機能のリリース前に作成された一部の user pool ではパスワードハッシュのインポートを利用できません｡ 7/16(木) Amazon S3 が S3 Standard-IA および S3 One Zone-IA への移行における 30 日間の最低保持期間を撤廃 Amazon S3 は､オブジェクト作成後 S3 Standard に 30 日間保持してから S3 Standard-IA および S3 One Zone-IA へ移行するという従来の制約を撤廃しました｡これにより S3 Lifecycle ルールで作成後 0 日 (作成当日) からこれらの Infrequent Access クラスへ移行できます｡両クラスは S3 Standard と比べて最大 40% 低いストレージコストで､必要時にはミリ秒単位でアクセスできます｡バックアップ､ログ分析､コンプライアンスなど数時間から数日で低頻度アクセスになるデータで効果があります｡なお､IA クラス自体の 30 日間の最低課金保持期間は引き続き適用される点に注意が必要です｡ AWS Sustainability に取水量 (water withdrawals) データを追加 AWS は AWS Sustainability サービスにおいて、従来の炭素排出量データに加え、ワークロードに関連する年間取水量 (water withdrawals) データを確認できるようにしました｡データは AWS リージョン別、サービス別、AWS アカウント別に年次で提供され、コンソールと API の両方から参照できます｡取水量はデータセンター運用のために取り込まれた水の総量を表し、効率改善は取水量の減少として反映されます｡このデータは対象リージョンすべてで追加料金なしに利用できます｡ Amazon S3 Event Notifications がシステム生成タグを含むように Amazon S3 Event Notifications が､ バケットに付与された system-generated tags (AWS サービスが自動付与するタグ) をイベントメッセージに含めるようになりました｡ 対応先は Amazon EventBridge､ Amazon SQS､ Amazon SNS､ AWS Lambda の全てです｡ これにより､ 数千個のバケットを個別に列挙せず 1 つの EventBridge ルールでタグを条件にイベントをフィルタリングできます｡ 追加料金はなく､ 全 AWS リージョンで利用でき､ 既存の設定変更も不要です｡ Billing and Cost Management Dashboards に Cost Efficiency ウィジェットを追加 AWS Billing and Cost Management (BCM) Dashboards に Cost Efficiency ウィジェットが追加されました｡コスト効率スコアの推移を、Cost Explorer、Budgets、Savings Plans/Reserved Instance のカバレッジ･使用率レポートと同じ 1 枚のダッシュボードで確認できます｡ウィジェットは Cost Optimization Hub のコンソールに直接リンクし、節約の推奨事項があればそのまま対処できます｡全ての AWS 商用リージョンで追加料金なしで利用できます｡ それでは、また来週お会いしましょう！ 著者について 戸塚 智哉(Tomoya Tozuka) / @tottu22 飲食やフィットネス、ホテル業界全般のお客様をご支援しているソリューション アーキテクトで、AI/ML、IoT を得意としています。最近では AWS を活用したサステナビリティについてお客様に訴求することが多いです。 趣味は、パデルというスペイン発祥のスポーツで、休日は仲間とよく大会に出ています。

2026 年 6 月 25 日、26 日に AWS Summit Japan が開催され、多数のセッションとブース展示が行われました。AWS セッションや AWS Village のブース展示においては、レジリエンスに関するトピックを多数お届けしていました。本ブログでは、AWS Summit Japan 2026 よりレジリエンスに関するセッション、ブースの内容をサマリーでご紹介します。 AWS セッションより 大規模障害から考える、AWS 上で備えるべきレジリエンスの実践 AWS エンタープライズサポート シニアテクニカルアカウントマネージャー 猪又 赳彦より、実際の障害発生時に AWS が何をしているのかを解説するセッションをお届けしました。AWS の障害対応は「検出と軽減策の実施」「振り返り」「学習とスケーリング」の 3 フェーズで進められ、振り返りでは COE（Correction of Error）の中核として Five Whys による根本原因分析が行われることを紹介。「5 回で止める」「直線的な分析に限定する」といった典型的な誤解に触れつつ、1 つの事象から複数の根本原因へ問いを分岐させていく実例が解説されました。 また、障害から生まれた「Availability Axioms（可用性の基本原則）」として、リージョンの分離（AWS STS のリージョナル化の歴史）、AZ 障害への自動対応（Fleet Health Service や Zonal Event Detector による検知と Amazon Application Recovery Controller の Zonal Shift / Autoshift）、厳密なテスト（専用のテストリージョンでのゲームデー）、過負荷からの保護（Metastable Failure という準安定障害の概念）という 4 つの原則が紹介されました。事例では、2025 年 10 月 20 日の US East 1（バージニア北部）リージョンでの Amazon DynamoDB DNS 障害を踏まえ、Fidelity Investments 社が日常的なレジリエンステストにより、当日 2,000 個のアプリケーションのフェイルオーバーを検知から 9 分で完了させた実践が紹介されました。 Operation Phase of AI-DLC － AI 駆動カオスエンジニアリングのすすめ－ AWS Developer スペシャリストソリューションアーキテクト 金森 政雄より、AI-Driven Development Lifecycle（AI-DLC）の Operation フェーズに焦点を当てたセッションをお届けしました。AI-DLC のホワイトペーパーでは、AI がテレメトリを能動的に分析して問題を予測し、ランブックと連携して推奨アクションを提案・実行し、開発者が検証・承認するというサイクルが定義されていますが、実運用に導入するには「既存の運用に乗せる」→「AI で改善する」→「AI を活用した運用（AIOps）へ」という段階的なアプローチが有効であると解説されました。具体例として、アーキテクチャ図上でリスクを可視化する「リスクストーミング」と、カオスエンジニアリングを組み合わせ、AI-DLC で開発されたデモアプリ「Unicorn Market」を用いて、リスク抽出から障害注入実験までを AI が加速するデモが実演されました。 AWS DevOps Agent による自律的インシデント対応 －その能力を引き出す設計のベストプラクティス－ AWS シニアスペシャリストソリューションアーキテクト 加藤 正樹より、障害対応と運用改善に特化した AI エージェント「AWS DevOps Agent」の能力を引き出す設計を解説するセッションをお届けしました。障害対応における AI 活用の課題として、暴走と停止の制御、多様なデータソースの横断、チーム全員でのコンテキスト維持の 3 点を整理し、「調査は AI、判断は人」という設計思想のもと、複数オブザーバビリティツールを横断したテレメトリ調査やコードリポジトリと連携した変更特定、Skills によるナレッジ共有といった機能が紹介されました。デモでは CloudWatch Alarm をトリガーに自律的に調査を開始し、複数テレメトリを相関づけて根本原因に到達、緩和計画を Kiro 等のコーディングエージェントに引き渡すまでの一連の流れが実演されています。 能力を引き出すベストプラクティスとして、調査スコープを定義する Agent Space の設計原則、Insights ファミリーや OpenTelemetry によるテレメトリの充実、Skills と Agent Instructions によるナレッジ共有の 3 点が解説されました。ナレッジ整備前後では根本原因到達時間が 6 分 32 秒から 3 分 38 秒へ短縮された結果も共有されています。事例として KDDI 様では調査リードタイムが数週間から数日へ短縮され、CyberAgent 様では MCP サーバーを活用して本番データベースを安全に調査する独自拡張を構築した事例が紹介されました。 ランサムウェアに対して最優先で取るべき AWS の復旧対策 ソリューションアーキテクト 向井 稔より、ランサムウェア被害からの「復旧」にフォーカスし、状況に応じた 3 段階の対策を解説するセッションをお届けしました。IPA「情報セキュリティ 10 大脅威 2026」でランサム攻撃が 11 年連続 1 位となる中、防御・検知・対応だけでなく、暗号化されたデータを確実に復元し業務を再開する「復旧」フェーズの重要性を強調しました。 まず「すぐに始められる対策」として、Write Once Read Many（WORM）によるイミュータブルなデータ保護を紹介しました。AWS では Amazon S3 Object Lock、Amazon EBS Snapshot Lock、Amazon FSx for NetApp ONTAP SnapLock、AWS Backup Vault Lock の 4 つのサービスで WORM を実現でき、いずれも追加料金なしで利用可能です。Compliance モードを選択すれば、保持期間中は管理者であってもデータを削除できない強固な保護が適用されます。 次に「包括的な対策」として、AWS アカウント自体が侵害されるリスクに備え 3-2-1-1-0 ルールに基づく戦略を解説しました。具体的には、AWS Backup の論理エアギャップボールト（Logically Air-gapped Vault）により AWS 管理の専用アカウント内にバックアップを隔離し、デフォルトで Vault Lock による WORM 保護を適用する構成を紹介しました。さらに Amazon GuardDuty Malware Protection for AWS Backup によりバックアップのマルウェアスキャンを復旧前に実施できること、自動復元テストにより復旧プロセスの正常性を継続的に確認できることを説明しました。最後に「オンプレミス環境の対策」として、バックアップソフトウェアと S3 Object Lock を連携させ、オンプレミスのデータを AWS に WORM 保護付きでバックアップし、DR 対策とランサムウェア対策を同時に実現する構成を紹介しました。 AWS ブース展示より レジリエンス強化と障害対応につかえる AI 体験 本ブースでは「EC サイトが障害で停止し、復旧まで 1 時間を要した」というシナリオを起点に、レジリエンスライフサイクルの各ステップを AI で加速する 4 つのデモを体験いただきました。 起点となる AWS DevOps Agent のデモでは、DB 接続プール枯渇と Redis キャッシュ障害が同時発生する複合障害に対し、CloudWatch Alarm をトリガーに AI が自律的に調査を開始。約 10 分で 2 件の根本原因を特定し、緩和計画まで日本語でレポートする一連の流れをお見せしました（運用・対応と学習）。続いて BIA（Business Impact Analysis）のデモでは、Kiro 上で動く AI ファシリテーターが対話形式でビジネスインパクトの分析を支援。ダウンタイムコストと最大許容ダウンタイムを算出し、DR の目標値を導き出す過程をご紹介しました（目標を設定）。 3 つ目の次世代 AWS Resilience Hub × Kiro のデモでは、GenAI による障害モードアセスメントが現行アーキテクチャの課題を評価し、その結果を Kiro に渡すとマルチリージョン化の提案レポートから CloudFormation テンプレートの改修まで AI が一気通貫で生成。評価・計画・実装を AI が担い、人間は判断とデプロイ承認に集中できるワークフローを提案しました（設計と実装）。最後の Chaos Agent（Kiro × AWS FIS）のデモでは、再設計後の環境に対し AI がカオステストのシナリオ生成から障害注入、RTO/RPO の合否判定までを自律実行。実測 RTO 約 99 秒で目標を大幅にクリアする結果を示し、設計後も AI が継続的に検証する重要性をお伝えしました（評価とテスト）。 4 つのデモは「運用・対応と学習 → 目標を設定 → 設計と実装 → 評価とテスト」というライフサイクルを一気通貫で体験できる構成とし、ご来場いただいた方のご興味のポイントに合わせてご説明させていただきました。 大阪リージョンを使用したマルチリージョン構成のデモ（たこ焼き AI 大将） 大阪リージョンをメインとしたディザスタリカバリ（DR）構成を、たこ焼き注文アプリ「たこ焼き AI 大将」として体験できるデモをご案内しました。レジリエンス／DR は重要でありながら難解と捉えられやすいテーマなので、技術的な堅牢性を保ちつつ誰もが直感的に楽しめる構成を目指してデモを設計・実装しました。注文操作に連動して、たこ焼きを焼く・盛り付けるロボットアームを配置し、来場者の関心を自然に技術デモへ引き込む導線を目指しました。 ブースではリージョン障害を疑似的に発生させても注文を継続できる様子を実演し、Amazon Aurora DSQL のマルチリージョン アクティブ‐アクティブクラスターによる高可用性、Amazon Bedrock のクロスリージョン推論、Amazon CloudWatch Application Signals による SLO モニタリングを組み合わせた構成を紹介しました。障害対応には Amazon CloudFront のオリジンフェイルオーバーと Amazon Application Recovery Controller の Region Switch を採用し、AWS Fault Injection Service で Lambda レイテンシーや DSQL 接続障害時の動作を検証するアーキテクチャを体感いただきました。 AWS レジリエンス体験ゲーム 〜 選ぶだけで学べる、障害対応の意思決定 手を動かしながらレジリエンスを学べるよう、ブースにクイズ形式のゲームを用意しました。AWS のレジリエンス設計を体験できる展示です。来場者は架空のグローバル企業で「最高レジリエンス責任者（Chief Resilience Officer）」となり、次々と発生する障害シナリオに対して復旧の選択肢を選んでいきます。専門知識がなくても選択肢を選ぶだけで進められるので、クラウド初心者からアーキテクトまで、立ち止まって手を動かしていただけました。 用意したのは、業種の異なる 4 つのシナリオです。 FinancePay（決済 / マルチリージョン災害復旧） — リージョン障害に直面し、RTO / RPO を意識しながら、バックアップ＆リストア、パイロットライト、ウォームスタンバイ、マルチサイトアクティブ/アクティブという 4 つの DR 戦略を選択。Amazon Application Recovery Controller（ARC）のルーティングコントロールによるリージョン間のトラフィック切り替えも体験します。 StreamMax（動画配信 / 高可用性とゾーン分離） — ライブ配信中のアベイラビリティゾーン（AZ）障害に対応。マルチ AZ 配置と、ARC の Zonal Shift・Zonal Autoshift による健全な AZ へのトラフィック退避を通じて、障害の影響を AZ 単位に封じ込める考え方を学びます。 ShopFast（EC / セルベースアーキテクチャ） — フラッシュセール中のカスケード障害が題材。セルベースアーキテクチャとシャッフルシャーディング、バルクヘッドパターンで爆発半径（Blast Radius）を最小化し、一部が壊れてもサービス全体を止めないグレースフルデグラデーションを体感します。 DoWellAI（生成 AI / AI ワークロードのレジリエンス） — 生成 AI アプリの安定運用がテーマ。Amazon Bedrock Guardrails による入出力フィルタリング、クロスリージョン推論、プロンプトキャッシング、共有障害の防止といった、生成 AI 時代のレジリエンスパターンを扱います。 「アベイラビリティゾーンとは何か」といった基礎から、セルベースアーキテクチャや生成 AI ワークロードの可用性設計まで、体験しながら段階的に学べる展示を行いました。 進化する金融 × レジリエンス 〜 金融システムを支えるセキュリティ＆レジリエンス 金融ブースでは、ミッションクリティカルなワークロードのレジリエンス強化とサイバーセキュリティ対策について、具体的な実装をデモでご紹介しました。取り上げたのは、次のようなユースケースです。 リアルタイムカード決済のマルチリージョン構成 — 東京・大阪の両拠点で止まらない決済基盤をライブ実演。カードをかざした瞬間から処理完了までの流れを体感いただけます。 認証情報侵害の検知と AI による自律調査 — 多段階攻撃の個別アラートを AI が「攻撃チェーン」として自動判定し、調査レポートまで生成。検知から調査完了までを一気通貫でお見せしました。 AWS Security Agent による設計書レビュー — 設計書を読み込ませ、コンプライアンス確認作業を効率化する取り組みをご紹介しました。 AI との対話によるランサムウェア対策アーキテクチャ提案 — ランサムウェア対策を生成 AI が活用できる Agent Skill として体系化。金融グレードの AWS 推奨構成を対話で具体化し、設計提案・現状評価・改善ロードマップをレポート出力します。 障害訓練シナリオの AI 自動生成 — 構成情報を入力するだけで障害訓練のシナリオと実施計画を AI が自動生成し、訓練準備の負担を大幅に削減します。 止まらない決済基盤から、AI を活用した脅威検知・設計レビュー・障害訓練まで。守りを固めるだけでなく、生成 AI で運用そのものを進化させていく。そんな金融システムのこれからを、実装を通して感じていただける展示となりました。 人間 vs AI 障害対応バトル – Chaos Kitty Challenge AWS のアーキテクチャを物理的に表現し、インシデント対応を体験学習できる Chaos Kitty。4 回目の登場となる今年は、新たに「対戦モード」を追加して AWS Builders’ Fair に展示しました。同じ障害が発生した 2 つの環境で参加者と AI エージェントが同時に対応を開始し、どちらが早く正確に Web 3 層アプリケーションの障害を解決できるかを競います。 AI エージェントには AWS DevOps Agent を採用。メトリクス・ログ・トレースやデプロイ履歴を横断分析して根本原因を特定していく調査プロセスが対戦画面上にリアルタイムで可視化され、AI 時代のインシデント対応の未来を体感できる展示となりました。 Chaos Kitty は AWS Samples として公開しており、ご自身の AWS 環境にデプロイしてお試しいただけます。詳しくは紹介ブログ記事もあわせてご覧ください。 AWS Summit Japan 2026 に Chaos Kitty が対戦モードを引っさげて 4 回目の登場！   大阪リージョンデータセンター 最新の災害対策 大阪リージョンデータセンターブースでは、AWS インフラストラクチャの耐災害性を直感的に体験いただける展示を行いました。今回のサミットでは、大阪リージョンで採用されている日鉄エンジニアリングの免震装置「NS-SSB（球面滑り構造）」を模型と VR 体験装置でご紹介。VR を通じて免震構造の効果を体感いただくことで、大阪リージョンのインフラストラクチャが持つ高い耐災害性をより実感いただける内容としました。特に DR 戦略として大阪リージョンの利用を検討されているお客様から高い関心をいただきました。 まとめ 障害へのアプローチとしては、障害が起こる事を前提とし、素早く復旧する事（レジリエンス、回復力）が重要です。今回の AWS Summit では、このプラクティスを AI エージェントによって加速するという新しい潮流が多く確認できる内容となっておりました。特に、Business Impact Analysis から Resilience Hub によるアーキテクチャ評価、Fault Injection Service を用いたカオステスト、そして障害発生時の DevOps Agent による一次対応まで、レジリエンスライフサイクルの各フェーズに AI を組み込む具体的な実装例が確認できる内容になっておりました。加えて、ランサムウェアからの復旧対策や大阪リージョンを活用したマルチリージョン構成など、ミッションクリティカルなワークロードを守るための実践的な選択肢も幅広くご紹介しました。これからミッションクリティカルなシステムや高い可用性要件が求められるシステムのクラウド活用を検討頂いている皆様に少しでも参考になれば幸いです。 現在は、セッションの動画や資料を以下で公開中です。ぜひあわせてご覧ください。 – 動画（視聴には登録が必要です）： https://aws.amazon.com/jp/events/summits/japan/ – セッション資料： https://pages.awscloud.com/AWS-Summit-Japan-2026-Session-Materials-Download.html – ブース展示資料： https://pages.awscloud.com/AWS-Summit-Japan-2026-AWS-Expo.html 著者について 猪又 赳彦 技術支援本部 エンタープライズサポート シニアテクニカルアカウントマネージャー 鈴木 真史 技術統括本部 交通・物流ソリューション部 シニアソリューションアーキテクト 三好 史隆 技術統括本部 自動車・製造 ソリューションアーキテクト 安藤 麻衣 技術統括本部 通信・メディア技術本部 通信第二ソリューション部 ソリューションアーキテクト

はじめに こんにちは、SRE部 フロントSREブロックの秋田と池田です。普段はリプレイスプロジェクトをはじめ、BFF・WebアプリケーションやオンプレのWebサーバーなど、ユーザー体験に関わるシステムの運用保守に携わっています。 ZOZOTOWNでは長年、オンプレミスのDNSアプライアンスとして Infoblox を利用してきました。しかし、7年間運用してきたInfobloxがEOL（End of Life）を迎えることとなり、リプレイスを検討することになりました。 本記事では、Infobloxのリプレイス検討から廃止に至るまでの課題をご紹介します。あわせて、Akamai Edge DNSのPrimary昇格・Akamai SIA導入・TerraformによるIaC化という3つのアプローチで課題を解決した取り組みについても触れます。 目次 はじめに 目次 既存のDNS構成と課題 既存構成 課題1：コスト面 - ライセンス費用の高騰 課題2：運用面 - ライセンス更新・脆弱性対応・バージョンアップ 課題3：管理面 - ゾーン管理の非コード化 課題4：チーム面 - 運用の属人化 課題解決のアプローチ 既存構成とAkamai Edge DNS Primary昇格の比較 施策1：Akamai Edge DNS - Secondary → Primary昇格 施策2：Akamai SIA導入 - キャッシュDNSの置き換え PoC（概念実証）の実施 DNSレベルの脅威検知によるセキュリティ強化 施策3：Terraform化 - ゾーン管理のIaC移行 稼働中ゾーンのTerraform import GitHub ActionsによるCI/CDパイプラインの整備 手順書レビューからPRベースレビューへの転換 Infoblox廃止に向けたクローズ作業 まとめ 最後に 既存のDNS構成と課題 既存構成 リプレイス検討前のDNS構成は以下の通りです。 権威DNS（Primary） : Infoblox（オンプレミス） 権威DNS（Secondary） : Akamai Edge DNS キャッシュDNS : Infoblox（オンプレミス） ZOZOTOWNではInfobloxをHidden Primary（NSレコードに公開しない権威DNS）として長年利用していました。AkamaiはInfobloxからゾーン転送を受けるSecondaryの役割を担いながら、インターネット側に公開されているためユーザーからの名前解決にも応答していました。オンプレのActive Directoryで使われるキャッシュDNSはInfobloxを利用していました。 この構成はInfobloxを導入した当初は問題なく運用していましたが、7年間の運用をする中で複数の課題が浮き彫りになってきました。 課題1：コスト面 - ライセンス費用の高騰 昨今の急激な円安の影響もあり、ライセンス更新のたびに費用が大きく膨らんでいました。さらにEOLに伴う機器リプレイスとなれば、ハードウェアの調達・入替コストも新たに発生します。 同等のInfoblox機器へリプレイスするという選択肢では、こうしたコスト面の課題がそのまま継続するため、根本的な解決にはなりませんでした。 課題2：運用面 - ライセンス更新・脆弱性対応・バージョンアップ Infobloxの運用では、以下のような定期作業が繰り返し発生していました。 ライセンス更新対応 : 年次でのライセンス更新作業とライセンス費用管理 脆弱性対応 : InfobloxはBINDベースであり、BINDの脆弱性が発見されるたびに対応が必要 バージョンアップ対応 : セキュリティパッチやバグフィックスのためのアップデート作業 どれも定期的に発生する作業で、特にBINDベースゆえの脆弱性対応は予告なく緊急対応が必要になるケースもあり、計画外の工数が積み重なっていました。 課題3：管理面 - ゾーン管理の非コード化 InfobloxのゾーンはInfobloxの管理コンソールを通じた手作業での運用となっており、設定変更の経緯が社内の申請と管理コンソールのコメントでしか追えない状態でした。具体的には以下のような問題がありました。 変更履歴が社内申請と管理コンソールのコメントのみで、いつ・誰が・なぜ変更したかを追うことが困難 手作業でのレコード追加・変更による作業ミスのリスク 手順書ベースの作業かつ手順書レビューの作業準備コスト ゾーン設定の現状把握がInfobloxにアクセスしないとできない IaC（Infrastructure as Code）が当たり前になった環境において、DNSゾーン管理だけが手作業のまま取り残されている状態でした。 課題4：チーム面 - 運用の属人化 ZOZOTOWNのマイクロサービス化に合わせてチーム体制の最適化が進む中、Infobloxの運用もフロントSREブロックで担当するようになりました。しかし、チーム内でInfobloxの運用経験を持つメンバーは1人だけという状態が続いており、運用の属人化が課題となっていました。 属人化が進むと、不在時に対応できるメンバーを確保できなくなるリスクや、人員変動に伴う引き継ぎコストの増大といった問題を招きます。チームとして持続可能な運用体制を整えるために、属人化の解消が急務となっていました。 課題解決のアプローチ 既存構成とAkamai Edge DNS Primary昇格の比較 リプレイスの選択肢として、まず「同等のInfoblox機器へのリプレイス」と「Akamai Edge DNSをPrimaryに昇格してInfobloxを廃止する」の2案を比較検討しました。 比較の結果、Akamai Edge DNS Primary昇格案は以下の点で優位でした。 観点 Infobloxリプレイス Akamai Edge DNS Primary昇格 ライセンスコスト 継続（高騰リスクあり） 不要（既存Akamaiの活用） ハードウェアコスト 機器調達が必要 不要 脆弱性対応 BINDベースの定期的な対応が継続 Akamaiのマネージドサービスに委譲 ゾーン管理 手作業継続 Terraform化で解消 キャッシュDNS Infobloxのまま Akamai SIAで代替（別途費用が発生） Akamaiは既にSecondaryとして動いており、ゾーンデータはそのまま引き継げました。Akamai SIAの利用には新たに費用が発生するものの、ライセンス・ハードウェア・運用コストの削減や運用品質の向上といった優位点が大きく上回りました。 これらの比較結果をもとに、 AkamaiをPrimaryに昇格してInfobloxを廃止する 方針を決定し、以下3つの施策を実施しました。 施策1：Akamai Edge DNS - Secondary → Primary昇格 まず、Akamai Edge DNSをSecondaryからPrimaryに昇格させ、Infobloxからのゾーン転送をなくしました。 Infoblox（Primary）→ Akamai（Secondary）という構成から、Akamai単体を権威DNSのPrimaryとする構成への移行です。 移行にあたっての主な作業は以下の通りです。 AkamaiのゾーンをSecondaryからPrimaryへ変更 Secondaryとして利用していたため実際にゾーン情報を持っていることもあり、AkamaiのコンソールからSecondaryをPrimaryに切り替える作業のみで済みました。また、切り戻しの際もPrimaryからSecondaryに戻してゾーン転送の設定を再設定するだけで済むため、作業工数をかけずに移行が実現できました。 施策2：Akamai SIA導入 - キャッシュDNSの置き換え InfobloxのCache DNS機能を Akamai SIA（Secure Internet Access） で代替しました。 Akamai SIAはDNSフォワーダーとして機能するだけでなく、 DNSレベルでの脅威検知・ブロック 機能も提供します。従来のInfobloxのキャッシュDNSにはなかった機能で、セキュリティ面での強化も同時に実現しました。 PoC（概念実証）の実施 本番環境への適用前に、STG（ステージング）環境で3週間のPoCを実施しました。 PoCの確認項目は以下の通りです。 Akamai SIAのアクセス制限 名前解決の動作確認（社内ドメイン・外部ドメイン） 既存のDNS依存アプリケーションへの影響確認 手動切り戻し手順の確認 3週間のPoC期間中に問題は発生せず、本番環境への適用に移行しました。 DNSレベルの脅威検知によるセキュリティ強化 Akamai SIAでは、マルウェアのC2（Command and Control）サーバーやフィッシングサイトへのDNSクエリをブロックする機能を持っています。 Infobloxのキャッシュ置き換えに加えて、このセキュリティ機能を獲得できたことは想定外のプラスαでした。 施策3：Terraform化 - ゾーン管理のIaC移行 課題3として挙げたゾーン管理の手作業運用を解消するため、Terraformを用いてAkamaiのDNSゾーンをIaC管理する仕組みを整備しました。 稼働中ゾーンのTerraform import Akamaiには既にゾーンが存在しているため、影響範囲が小さいものから段階的に、既存ゾーンのTerraform importを始めました。 terraform import akamai_dns_zone.example example.com 全ゾーンを一括importするスクリプトを作成し、既存ゾーンをTerraform管理下に置きました。import後はtfstateと実際のゾーン設定の差分を確認し、コードと実態の一致を検証しました。 GitHub ActionsによるCI/CDパイプラインの整備 import完了後、以下のパイプラインをGitHub Actionsで整備しました。 PRを作成 → terraform plan → レビュー → マージ → terraform apply 各ステップの詳細は以下の通りです。 terraform plan（PR時） PRを作成するとGitHub Actionsが自動でterraform planを実行 planの結果はPRコメントへ出力され、レビュアーが変更内容を確認できる状態になる terraform apply（マージ時） mainブランチへのマージをトリガーにterraform applyを実行 Akamaiへの変更が自動で反映される 手順書レビューからPRベースレビューへの転換 Terraform化により、ゾーンの変更オペレーションが以下のように変わりました。 変更前 変更後 Infoblox GUIで手作業変更 tfファイルを編集してPRを作成 手順書をレビュー PRをレビュー 変更履歴が残らない Gitのコミット履歴として残る 変更の影響範囲が手順書に依存 planで変更内容が定量的に把握できる コードレビューを通じて変更の意図と影響範囲を確認できるようになり、ヒューマンエラーの削減と変更の透明性向上を同時に実現しました。 Infoblox廃止に向けたクローズ作業 施策1〜3が完了した後、Infobloxを安全に廃止するためのクローズ作業を実施しました。 Infobloxに依存しているクライアントが残っている状態で廃止してしまうと障害につながります。移行済みかどうかを地道に確認しながら、以下の順序で進めました。 キャッシュDNSの向き先変更 ：各クライアントのDNSフォワーダー設定をInfobloxからAkamai SIAへ変更 ゾーン転送の停止確認 ：Infoblox→Akamaiへのゾーン転送が停止していることを確認 権威DNS問い合わせ確認 ：外部からの問い合わせがInfobloxを経由していないことを確認 監視の切り替え ：Infoblox関連のモニタリング・アラートの削除 機器のシャットダウン・撤去 ：一定期間の様子見後、機器の電源を落として廃止 クローズ後も一定期間はリバートできる状態を維持し、問題がないことを確認した上で機器を撤去しました。 まとめ 7年間運用してきたInfobloxの廃止とAkamaiへの移行を通じて、コスト・運用・管理・チームの4つの課題を同時に解決できました。 コスト削減 ：Infobloxライセンス費用・保守サポート費用・EOLに伴うハードウェア調達費用が不要になりました 運用負荷の低減 ：BINDベースの脆弱性対応やライセンス更新といった定期作業がなくなりました 管理品質の向上 ：ゾーン変更がPRベースのレビュープロセスに変わり、変更履歴が残るようになりました セキュリティ強化 ：Akamai SIAによるDNSレベルの脅威検知も獲得できました 属人化の解消 ：SaaS移行によりInfoblox固有の知識がなくても運用できる体制となり、引き継ぎ負担を軽減できました EOLへの対応はどうしても後ろ向きな作業に見えがちですが、今回は「機器交換」で終わらせず、積み上がっていた課題を整理する機会として捉えられチーム状況を考えながら最適化できたことはとてもよかったです。同様の状況を抱えているチームの参考になれば幸いです。 最後に ZOZOでは、一緒にサービスを作り上げてくれる仲間を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。 corp.zozo.com