本記事は 2026 年 7 月 13 日に公開された Helen Hasbun および Emma Parkerton による “ Welcome to birthday week ” を翻訳したものです。 1 年が経ち、Kiro は AI コーディングからエージェンティックエンジニアリングへと進化しました。開発者コミュニティの皆さんがいなければ、今の Kiro というツールも、今の私たちというチームもなかったでしょう。皆さんがフィードバックを寄せ、イベントに参加し、作り上げたものを共有していただき、その一つひとつが私たちを成長させてくれました。このコミュニティが私たちとともに成長し、変化していく様子を見守ることができて、心から嬉しく思います。社内では皆さんのことを、とても良い意味でよく話題にしています。念のためお伝えしておきますね。 何が起きているか 7 月 13 日から 7 月 17 日まで（太平洋時間）の 1 週間を通じて、皆さんへの感謝をお伝えします。追加のクレジットを獲得できる仕組みや、随所にちょっとしたサプライズを用意し、皆さんが作り上げてきたものやシェアしてくれたものを一緒にお祝いします。毎日、コミュニティを主役にした特別な企画を用意します。 Your year of Kiro（皆さんと Kiro の 1 年のあゆみ）。 1 週間を通じて、皆さんがこの 1 年間で Kiro を使ってどのように作ってきたのかを聞かせてください。何をリリースしたのか、何が楽になったのか、何に驚いたのか。#BuildWithKiro #TeamKiro #1YearOfKiro のハッシュタグと @kirodotdev のメンションを付けて SNS でストーリーを共有してください。私たちは 1 週間ずっと読み、リポストし、皆さんの 1 年目を一緒にお祝いします。 デイリーコーディングチャレンジ。 毎日、Kiro アンバサダーが 日替わりのコーディングチャレンジ を発表します。デイリーチャレンジをクリアして Kiro のボーナスクレジットを獲得しましょう。連続クリアで連続ボーナスが加算され、週の終わりには完了したチャレンジ数に応じた倍率が適用されます。皆さんは最高報酬を獲得するために、連続パーフェクトを達成できますか？ バースデーパーティーライブストリーム。 7 月 15 日（水）午前 9 時 30 分（太平洋時間）からライブ配信を行い、この 1 年の印象的な出来事を振り返ります。プロダクトのローンチ、プログラムのローンチ、イベント、各種アップデートなど、取り上げたいことがたくさんあります。そのため、通常 1 時間のストリームを 1 時間半に拡大し、後半の 30 分にはスペシャルゲストとして Kiro VP の Deepak Singh が加わり、ビジョンを紐解きます。当初どういうものだったのか、どのように展開してきたのか、これからどこへ向かうのか。ぜひご視聴ください。素敵なパーティーになります。 コミュニティスポットライト。 1 週間を通じて、1 年目を成功に導いてくれたビルダーの皆さんに光を当てます。明日のために開発する学生、企業を立ち上げ成長させている創業者、日々 Kiro を自ら使いこなしている Amazon と AWS のビルダーやコミュニティ、限界を押し広げて知見を共有してくれる Kiro アンバサダー。Kiro が幅広い業界、影響力、規模でビルダーの皆さんを支えている様子を目の当たりにできたのは、本当に素晴らしいことでした。 いくつかのバースデーサプライズ。 サプライズが 1 つや 2 つなければ、誕生日らしくありませんよね。ここではまだ明かせませんが、サプライズをいくつか用意しているので、SNS をフォローして、最新情報を逃さないようにしてください。 是非お祝いに参加してください 今年は皆さんが私たちと一緒に作り上げてくれました。この 1 年の Kiro との物語や体験を共有し、 デイリーチャレンジ にできるだけたくさん挑戦し、 バースデーパーティーライブストリーム を視聴してリアルタイムで質問を投稿して、SNS 上で交わされる Kiro コミュニティの会話にぜひご参加ください。皆さんからのフィードバックや体験に、私たちは本当にたくさんの刺激とモチベーションをいただきました。皆さんにとって、コミュニティでの時間が同じように刺激的で励みになるものになることを願っています。 Discord にご参加いただき、 X や LinkedIn をフォローし、1 週間を通じて Kiro をタグ付けし、#BuildWithKiro #TeamKiro #1YearOfKiro のハッシュタグを使って築き上げたものを共有してください。 一緒に 2 年目をスタートしましょう。Kiro、お誕生日おめでとう！ 翻訳は Kiro 好きの Solutions Architect の吉村が担当いたしました。

みなさん、こんにちは。AWS ソリューションアーキテクトの木村です。 7 月 28 日（火）に「 AWS Bedrock LLM Day Japan 」が東京 赤坂インターシティにて開催されます。AWS Summit New York で発表された最新のサービスアップデートを日本のお客様向けにいち早くお届けするとともに、Amazon Bedrock上でのAnthropic・OpenAIモデルの活用法や、AIエージェント構築基盤AgentCoreの最新機能を実践的に解説します。ぜひご参加ください！ 「 AWS ジャパン生成 AI 実用化推進プログラム 」も引き続き募集中ですのでよろしくお願いします。 それでは、7 月 6 日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ「エムシーディースリー株式会社様：AI-DLC Unicorn Gym による3日間の開発変革」を公開 三菱商事グループの一員として産業 DX を推進するエムシーディースリー株式会社様と実施した、AI 駆動開発ライフサイクル（AI-DLC）の体験型プログラム「Unicorn Gym」のレポートです。7 つのチームが Kiro を活用して実際のプロダクト課題や業務課題に挑み、3 日間で商用レベルに近いアプリケーション開発やレガシー環境のコンテナ化を実現した様子と、各チームが得た学び・活用の工夫を紹介しています。 ブログ記事「フロンティアモデルの安全なリリースに向けた AWS の取り組み」を公開 Anthropic の Claude Fable 5 が、悪用を防ぐためのさらに強力なガードレールを備えて Amazon Bedrock で再び利用可能になりました。本ブログでは AWS の CISO である Amy Herzog が、Project Glasswing を通じた Anthropic との連携のもと、サイバーセキュリティ分野で強力な能力を持つフロンティアモデルを防御側に届けつつ、攻撃者への悪用を防ぐための考え方を説明しています。ガードレール作動時には Opus 4.8 に自動フォールバックする仕組みも紹介されています。 ブログ記事「Amazon Bedrock のゼロデータ保持の強制方法」を公開 Claude Fable 5 のようにモデルプロバイダーとのデータ共有を必要とするモデルの登場を受けて、Amazon Bedrock のデータ保持モード（none / default / inherit / provider_data_share）の仕組みを解説しています。Amazon Bedrock Projects によるプロジェクト単位のきめ細かい制御や、サービスコントロールポリシー（SCP）で組織全体にゼロデータ保持を強制する方法を、具体的なポリシー例と検証手順付きで紹介しています。データガバナンス要件のある組織の方は必見です。 ブログ記事「【公共向け】Claude Mythos 時代の脅威対策ワークショップ開催報告 & 耐障害性ライフサイクル実践ワークショップのご案内」を公開 パブリックセクターのお客様向けに月次開催しているセキュリティワークショップの第 3 回・第 4 回の開催レポートです。「Claude Mythos 時代の脅威への対応」をテーマに、Amazon Inspector による脆弱性管理・パッチ運用自動化と、AWS Security Agent による設計レビュー・コードレビュー・自動ペネトレーションテストのハンズオンを実施しました。ワークショップ教材は 一般公開 されていますので、ぜひお試しください。 ブログ記事「AWS パートナーと実現する生成 AI — 現場を変える8つの実践事例 AWS Summit Japan 2026 Partner Breakout Session レポート」を公開 AWS Summit Japan 2026 で 4 部構成にてお届けした Partner Breakout Session のレポートです。東邦ガス情報システム様の Kiro 導入、青森放送様の Amazon Bedrock を活用した文字起こしシステム、品川区様の音声 AI 実証、日本取引所グループ様の GraphRAG による暗黙知の形式知化など、8 組の AWS パートナーとお客様による実践事例のハイライトと、全セッションを通して見えてきた「AI の価値を現場で実現するために本当に必要なこと」を紹介しています。 ブログ記事「AWS Parallel Computing Service と Kiro CLI で HPC のデプロイを加速する」を公開 従来数週間かかっていた HPC クラスターのデプロイを、Kiro CLI のカスタムエージェントで自動化する方法を紹介しています。AWS PCS のベストプラクティスを組み込んだエージェントとの対話だけで、ネットワーク、コントローラー、キュー、コンピュートノードを備えたクラスターを約 30 分で構築する手順を、 デモリポジトリ とともに順を追って解説しています。 ブログ記事「Kiro の超過利用の上限設定と前払い機能のご紹介」を公開 Kiro の超過利用 (overage) の支出をコントロールする 2 つの新機能を紹介しています。IAM Identity Center 等でサインインするチーム向けには AWS Service Quotas コンソールから超過利用の上限を設定できるようになり、個人開発者向けには最小 5 ドルからのクレジットパックを前払いで購入できるようになりました。想定外の請求を防ぎたい方におすすめのアップデートです。 ブログ記事「Kiro で Claude Sonnet 5 が利用可能になりました」を公開 2026 年 7 月 1 日より、Claude Sonnet 5 が Kiro の IDE、CLI、Web で利用可能になりました。Sonnet 5 は推論力・ツール利用・コーディング能力が大幅に強化され、Sonnet クラスの価格のまま Opus 4.8 に近いエージェント性能を発揮します。クレジット倍率は Sonnet 4.6 と同じ 1.3 倍、100 万トークンのコンテキストウィンドウを備えており、タスクに応じて Opus 4.8 とのコスト・性能バランスを選べるようになりました。 サービスアップデート Amazon SageMaker HyperPod が Prefill と Decode の分離 (Disaggregated Prefill and Decode) をサポート Amazon SageMaker HyperPod で LLM 推論の Prefill と Decode を専用の GPU プールに分離する DPD がサポートされました。従来は両フェーズが同じ GPU を奪い合い、長いコンテキストのリクエストが他のトークン生成を停滞させていましたが、今回のアップデートで安定したレイテンシと高いスループットを実現し、両フェーズを独立してスケールできます。長いリクエストだけを自動で分離パスに振り分けるルーターも備えています。詳細は こちらのドキュメント をご参照ください。 Amazon SageMaker HyperPod が継続的プロビジョニングの Slurm クラスターでディープヘルスチェックをサポート 継続的プロビジョニングで作成した Slurm クラスターでも、GPU の健全性や接続性を検証するディープヘルスチェックが実行可能になりました。非同期に追加される新しいノードを、稼働中のワークロードを中断せずにジョブ投入前に検証できます。自動ノード復旧機能と組み合わせれば、失敗したインスタンスは自動で再起動・交換されます。詳細は こちらのユーザーガイド をご参照ください。 Amazon SageMaker HyperPod が継続的プロビジョニングの Slurm クラスターで AMI ベースのノードライフサイクル設定をサポート 継続的プロビジョニングを使用する Slurm クラスターでも AMI ベースの設定が利用可能になりました。これまで必要だったライフサイクル設定スクリプトの管理が不要になり、Docker や Slurm アカウンティングなどを備えた本番対応のノードを AMI から直接構成できます。ノード追加時点で設定が完了するため、より早くジョブをスケジュールできます。詳細は こちらのドキュメント をご参照ください。 Amazon SageMaker Studio がワンクリックのモデルデプロイとカスタマイズのために Hugging Face と統合 Hugging Face のモデルページから「Deploy on SageMaker AI」などを選ぶだけで、モデルがロード済みの Studio 環境に直接アクセスできるようになりました。従来はコンソールでの環境構築や IAM 設定、GPU クォータ申請が必要でしたが、今回のアップデートで数秒で環境が作成され、ファインチューニングやデプロイに必要な権限も事前設定されます。 AWS Neuron 2.31.0 が NKI 0.5.0 と UltraServer Operator とともに利用可能に AWS Neuron 2.31.0 がリリースされました。NKI 0.5.0 では MX FP8 スケール dtype や新しいテンソルビュー API が追加され、Amazon EKS 上の Trainium UltraServer ワークロードの管理を自動化する UltraServer Operator がパブリックベータで登場しました。Trn2・Trn3 でデフォルト有効になった新コンパイラバックエンドによる性能向上や、14 の実験的カーネル追加も含まれます。 AWS MCP Server が OAuth をサポート AWS Sign-In を使って AI エージェントを AWS MCP Server に直接接続できるようになりました。業界標準の OAuth を利用するため追加の認証ソフトウェアは不要で、既存の AWS ID や IAM 権限、ガバナンス制御がそのまま適用されます。ブラウザでの対話型認可とヘッドレス認可の両方に対応し、トークン失効 API や CloudTrail 監査などの統制機能も提供されます。詳細は こちらの Blog 記事 をご参照ください。 AWS DMS Schema Conversion が AI エージェントによる自動化をサポート AWS DMS Schema Conversion が AWS MCP Server を通じた AI エージェント自動化に対応しました。Kiro、Claude Code、Cursor などを接続し、IDE から自然言語でスキーマ変換や評価レポート生成などの移行ワークフロー全体を実行できます。専用スキルが API パターンや操作手順をエージェントに提供するため、試行錯誤を削減できます。追加料金なしで利用可能です。詳細は こちらのドキュメント をご参照ください。 Kiro IDE 1.0.116 — エージェント書き込み時のフック、遅延 MCP 認証、マルチウィンドウ同期 Kiro IDE 1.0.116 がリリースされました。エージェントによるファイル変更をトリガーにフックを実行できるようになり、サインインが必要な MCP サーバーへの自動 OAuth 認証や、複数ウィンドウ間での設定同期にも対応しました。trust 機能や接続まわりの修正も含まれています。 Kiro CLI 2.12 — MCP OAuth サポートの拡張 Kiro CLI 2.12 がリリースされました。Figma のように厳格な OAuth 要件を持つ MCP サーバーに対応し、クライアントシークレットの設定、カスタムコールバックパスの指定、独自クライアント ID 使用時の動的クライアント登録のスキップが可能になりました。複合フラグを持つコマンドのより正確な承認プロンプトや、ASCII モードの完全対応も含まれています。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 木村 直登(Naoto Kimura) AWS Japan のソリューションアーキテクトとして、製造業のお客様に対しクラウド活用の技術支援を行なっています。最近は AI Agent と毎日戯れており、AI Agent 無しでは生きていけなくなっています。好きなうどんは’かけ’です。

本記事は 2026 年 7 月 9 日 に公開された「 AWS Transform for migrations now supports localization for 13 languages 」を翻訳したものです。 移行プロジェクトを運営する組織が、単一の共通言語で業務を行うとは限りません。移行チームは地理的に分散しており、多くの場合、依存関係やビジネスコンテキスト、運用上のリスクを理解している担当者がワークロードに最も精通しています。そのため、担当者が最も慣れた言語で作業できることは欠かせません。本日、 AWS Transform のマイグレーションワークフローの多言語サポートを発表します。 提供開始した機能 AWS Transform の表示言語を以下の 13 言語に変更できるようになりました。 English (US) English (UK) Deutsch (German) Español (Spanish) Français (French) 日本語 (Japanese) Bahasa Indonesia (Indonesian) Italiano (Italian) Português (Portuguese) 한국어 (Korean) 中文 简体 (Chinese Simplified) 中文 繁體 (Chinese Traditional) Türkçe (Turkish) このローカライズは、物理サーバーと仮想サーバー (VMware、Hyper-V、KVM など) のディスカバリー、プランニング、ランディングゾーン、ネットワーク移行、リホスト、コンテナ化を含む AWS Transform マイグレーションワークフロー全体に適用されます。 仕組み 表示言語を切り替えるには、AWS Transform コンソール右上の設定アイコンを選択し、言語メニューから希望の言語を選択します。変更はマイグレーションワークフローの Web アプリケーションインターフェース全体に即時反映されます。 チームメンバーは AWS Transform と翻訳ツールを切り替えることなく、会話型インターフェースの操作、ジョブプランの確認、承認の管理、移行タスクの実行を、希望の言語で行えます。 図 1: Web アプリケーションの表示言語を変更するには、右上の設定アイコンを選択し、言語メニューから希望の言語を選択します。 図 2: 言語設定を日本語に変更した例 多言語対応が重要な理由 AWS Transform は会話型サービスです。自然言語で移行の計画と実行を対話形式で進めます。母国語で読み、応答し、意思決定できてこそ、会話型体験の価値が最大限に発揮されます。これまでインターフェースは英語のみでしたが、英語を主な業務言語としない地域（日本、韓国、ラテンアメリカなど）のチームには使いにくい面がありました。 今回のアップデートにより、マイグレーションエンジニアはタスクの説明確認、プロンプトへの応答、ウェーブプランの操作を、業務言語とツール間で頭の中で翻訳することなく実行できます。データ取り込みからネットワーク変換まで、マイグレーションワークフロー全体を日常の業務言語で利用できるようになりました。 使ってみる すでに AWS Transform for migrations をご利用中の方は、コンソールを開いて今すぐ言語設定をお試しください。AWS Transform を初めてお使いの方は、 AWS Transform ドキュメント をご参照ください。自然言語でワークロードの変換を計画・実行する方法をご確認いただけます。 現在、言語ローカライズに対応しているのは AWS Transform for migrations のみです。 著者について Jason Amaya Jason Amaya は、テキサス州ヒューストンを拠点とする AWS の Go-To-Market (GTM) スペシャリストです。エンタープライズ顧客のクラウド変革を加速させることに注力しており、AWS Worldwide Specialist Organization (WWSO) 内で AWS Transform for Migrations 戦略に携わり、セールスチームや顧客と連携してビジネス成果の拡大に取り組んでいます。 Jamie Vinciguerra Jamie は AWS の Worldwide Go-To-Market スペシャリストで、AWS Transform for migrations を担当しています。インフラのマイグレーションとモダナイゼーション GTM に 4 年間の経験を持ち、VMware ワークロードの AWS への移行支援に深い専門知識を持っています。以前は VMware マイグレーション戦略に注力しており、現在は依存関係マッピング、ウェーブプランニング、ネットワーク変換などを自動化するエージェント型 AI マイグレーションツール「AWS Transform」の普及を推進しています。AWS アカウントチームや顧客と緊密に連携し、クラウドマイグレーションを加速させています。 翻訳はパートナーソリューションアーキテクト 豊田が担当しました。原文は こちら です。

本記事は、2025 年 6 月 11 日に Networking & Content Delivery で公開された VPC resource gateways: Implementation patterns and use cases を翻訳したものです。 Amazon Virtual Private Cloud (Amazon VPC) 間でアプリケーションを接続する際、従来の AWS PrivateLink のプロバイダー・コンシューマーモデルに適合しないサービスへの接続が必要になると、VPC ピアリングや AWS Transit Gateway だけでは簡単に解決できない複雑なネットワーク課題に直面します。これは特に、IP アドレス空間が重複している場合に顕著です。 従来の PrivateLink の Provider-Consumer Model に適合しないサービスへの接続を、VPC リソースゲートウェイを使用することで実現でき、ネットワークアーキテクチャを簡素化できます。プロバイダーがサービスの前段に Network Load Balancer を配置することを求める VPC エンドポイントサービスとは異なり、リソースゲートウェイはロードバランサーインフラストラクチャの追加オーバーヘッドなしに、より幅広いターゲットを公開できます。 これまで複雑な追加設定が必要だったシナリオでも、追加インフラストラクチャの管理オーバーヘッドなしにサービスにアクセスできるようになりました。リソースゲートウェイは、ARN、DNS、または IP ベースのサービスへの接続を可能にしながら、セキュリティの維持、複雑さの軽減、コストの最適化を実現します。 リソースゲートウェイには複数のアクセス方法があります。 リソースエンドポイント 、 Amazon VPC Lattice サービスネットワークアソシエーション、および VPC Lattice サービスネットワークに接続された サービスネットワークエンドポイント です。本記事では、リソースへのアクセスを提供するために、リソースゲートウェイとリソースエンドポイントを使用したアーキテクチャパターンに焦点を当てます。Amazon VPC Lattice のサービスネットワークエンドポイントのユースケースと使用方法の詳細については、 こちらのブログ を参照してください。 以下のユースケースとトラフィックフローパターンを通じて、リソースゲートウェイの機能を理解していきましょう。 ユースケース 1：RDS リソースへのプライベートかつセキュアなアクセス 異なるビジネスユニットやアプリケーションコンポーネント間で厳密な分離を維持するために、マルチ VPC またはマルチアカウント戦略を採用している場合、アプリケーションサーバーとデータベースが異なる VPC や AWS アカウントに配置されます。また、このアーキテクチャパターンの要件は、合併・買収（M&A）の際にも発生します。 Amazon Relational Database Service (Amazon RDS) は、管理タスクを自動化することで従来型データベースの管理を簡素化します。 Amazon Aurora は、MySQL および PostgreSQL との完全な互換性を持つグローバルスケールのリレーショナルデータベースです。 Web/アプリケーションサーバーと RDS/Aurora データベースが異なる VPC に存在する場合、VPC ピアリングによる直接的な VPC 間通信や、AWS Transit Gateway / AWS Cloud WAN を使用したネットワーク接続のセットアップにより接続を確立できます。しかし、コンシューマーの数が急速に増加すると、これらの VPC ピアリング接続や AWS Transit Gateway / AWS Cloud WAN を経由するネットワークフローの管理オーバーヘッドが増大します。 リソースゲートウェイとリソース VPC エンドポイントを使用して、アプリケーションから Amazon RDS リソースへの接続を可能にできます。図1は、このユースケースのハイレベルアーキテクチャ図を示しています： 図1：RDS リソースへのプライベートかつセキュアなアクセス RDS リソースへのプライベートかつセキュアなアクセスを実現するために、以下の手順でリソースエンドポイントとリソースゲートウェイを構成できます： RDS リソースが存在する VPC にリソースゲートウェイを作成する。 アクセスしたい各 RDS クラスターまたはインスタンスに対して「ARN」タイプの リソース設定 を作成し、リソースゲートウェイに関連付ける。   注意 ：ARN ベースのリソースは現在、パブリックでない Amazon RDS リソースでサポートされています。ARN ベースのリソース設定の 子リソース設定 は、AWS によって自動的に管理されます。 （オプション） コンシューマー VPC と RDS VPC が異なる AWS アカウントにある場合、RDS VPC アカウントからコンシューマー VPC アカウントへ AWS RAM を通じてリソース設定を共有する。リソース設定が共有された後、コンシューマー VPC アカウントでリソース共有を承認する。 コンシューマー VPC に 「Resource」タイプの VPC エンドポイント を作成し、ARN タイプのリソース設定に関連付ける。VPC エンドポイントの作成時に、オプションで「Private DNS」を有効化する。Private DNS を有効にすると、リソース VPC エンドポイントを通じたプライベート接続を活用しながら、AWS サービスがリソースに対してプロビジョニングした DNS 名を使用してリクエストを続けることができます。   注意 ：Private DNS を使用するには、コンシューマー VPC の DNS ホスト名および DNS 解決が「有効」 （enableDnsHostnames, enableDnsSupport）に設定されていることを確認してください。 リソースエンドポイントとリソースゲートウェイに関連付けられたセキュリティグループにルールを追加して、必要なトラフィックを許可する。 VPC エンドポイントの Private DNS が有効時と無効時での動作を示す：   有効（推奨） ：RDS リソースの DNS 名（ライターエンドポイント、リーダーエンドポイント、またはインスタンスエンドポイント）を使用してリソースにアクセスできます。   無効 ：リソース VPC エンドポイントの DNS 名を使用して RDS リソースにアクセスします。ただし、これはデータベース証明書のコモンネーム（CN）を検証 していない 場合にのみ機能します。これは、リソース VPC エンドポイントの DNS 名が RDS/Aurora DB インスタンスの証明書のサブジェクト代替名（SAN）に含まれていないためです。 ユースケース 2：VPC IP CIDR が重複する環境での接続 CIDR が重複する VPC にコンシューマーとリソースが 存在する場合、それら間の直接通信が困難になります。このシナリオは、合併・買収時、パートナーネットワークへの接続時、または CIDR の計画が調整されていないマルチアカウント環境で一般的に発生します。この問題に対処する従来のソリューションには、NAT（ネットワークアドレス変換）を実行するアプライアンスの設定、NAT ゲートウェイの使用、または Network Load Balancer の作成と VPC エンドポイントサービスを使用したサービスの公開が含まれます。これらの解決策は有効ですが、追加リソースの作成が必要なため、複雑さとコストが増加します。 VPC リソースエンドポイントとリソースゲートウェイは、このような状況でコンシューマーがリソースにアクセスできるようにする、よりシンプルな代替手段を提供します。図2は、このユースケースのハイレベルアーキテクチャ図を示しています。 図2：重複 CIDR ユースケースにおけるリソースエンドポイントとリソースゲートウェイの使用 このケースでコンシューマーがリソースにアクセスできるようにするには、以下を実行します。 アクセス対象のリソースが存在する VPC にリソースゲートウェイを作成する。 リソースまたはリソースグループを表すリソース設定を作成し、リソースゲートウェイに関連付ける。 （オプション）コンシューマー VPC とリソース VPC が異なる AWS アカウントにある場合、リソース VPC アカウントからコンシューマー VPC アカウントへ AWS RAM を通じてリソース設定を共有する。リソース設定が共有された後、コンシューマー VPC アカウントでリソース共有を承認する。 コンシューマー VPC に、各リソース設定に対応する「Resource」タイプの VPC エンドポイントを作成する。 リソースエンドポイントとリソースゲートウェイに関連付けられたセキュリティグループにルールを追加して、必要なトラフィックを許可する。 リソース VPC エンドポイントの DNS 名を使用して、リソース VPC 内のリソースにアクセスする。フレンドリーな名前を使用してリソースにアクセスしたい場合は、「コンシューマー VPC」に関連付けられたプライベートホストゾーンを作成し、フレンドリー DNS 名をリソース VPC エンドポイントの DNS 名にポイントする CNAME レコードを追加できます。リソース VPC エンドポイントの DNS 名は、関連するリソース VPC エンドポイントを選択した際の「Associations」の下で確認できます。 図3：リソース VPC エンドポイントの DNS 名 ユースケース 3：パブリックドメインへの接続プロキシ パブリックエンドポイント宛ての通信であっても、一元化されたVPCを経由させるか、あるいはプライベートかつ制御されたネットワーク経路を使用することを義務付けるような厳格なポリシーを採用する場合を想定します。こうしたパブリックエンドポイントは、多くの場合 AWS 外の SaaS サービスか、AWS 上にありながら PrivateLink 経由ではプライベートに公開されていないサービスです。 リソースゲートウェイを使用して、集約 VPC 経由で、または AWS VPN 、 AWS Direct Connect 、VPC ピアリングなどのプライベート接続オプションを介したインクラウド接続ユースケースとして、パブリックエンドポイント（AWS またはサードパーティ）にアクセスできます。図4は、VPC 内のクライアントが集約 VPC とリソースゲートウェイを通じてパブリックエンドポイントにアクセスするハイレベルアーキテクチャ図を示しています。 図4：集約 VPC とリソースゲートウェイによるパブリックエンドポイントへのアクセス リソースゲートウェイを使用して集約 VPC 経由でパブリックエンドポイントへの接続を確立するには、以下のアプローチに従います： パブリックサブネットとプライベートサブネットを持つ VPC（「リソース VPC」）を作成する。VPC ルーティングを設定し、プライベートサブネットからインターネットへのトラフィックがパブリックサブネット内の NAT ゲートウェイを経由してルーティングされることを確認する。 リソース VPC のプライベートサブネットにリソースゲートウェイを作成する。 コンシューマーにアクセスさせたい各ドメイン名に対して、「DNS」タイプのリソース設定を作成する。各 DNS リソース設定は、コンシューマーにアクセスさせたい単一のドメイン名にマッピングされます。複数のドメイン名にアクセスさせたい場合は、複数のリソース設定を単一の「リソースグループ」にグループ化し、単一のリソース VPC エンドポイントで複数ドメインにアクセスできるようにできます。 （オプション）コンシューマー VPC とリソース VPC が異なる AWS アカウントにある場合、リソース VPC アカウントからコンシューマー VPC アカウントへ AWS Resource Access Manager(RAM) を通じてリソース設定を共有する。リソース設定が共有された後、コンシューマー VPC アカウントでリソース共有を承認する。 コンシューマー VPC に「Resource」タイプの VPC エンドポイントを作成し、リソース設定に関連付ける。 リソースエンドポイントとリソースゲートウェイに関連付けられたセキュリティグループにルールを追加して、必要なトラフィックを許可する。 プライベートホストゾーン（コンシューマー VPC に関連付け）を作成し、アクセスするパブリック FQDN をリソースエンドポイントの対応する DNS 名にマッピングする CNAME タイプのレコードを追加する。リソースエンドポイントの DNS 名の確認方法については、図2を参照。 プライベートホストゾーンで作成したレコードを使用して、アプリケーションからパブリックエンドポイントにアクセスする。 同様に、オンプレミスと AWS 間の確立済みプライベート接続を通じて、パブリックエンドポイントへのトラフィックをルーティングすることもできます。これにより、アウトバウンドインターネット接続を信頼できるエンドポイントに制限し、オンプレミスのクライアントがネットワーク分離を維持しコンプライアンス要件を満たしながら、パブリック FQDN とセキュアに通信できるようになります。図5は、オンプレミスのクライアントが AWS Site-to-Site VPN / AWS Direct Connect を介してリソースゲートウェイ経由でパブリックエンドポイントにアクセスするハイレベルアーキテクチャ図を示しています。 ※訳者注：集約 VPC の IGW からのアウトバウンド通信は TGW での接続が分かりやすく一般的ですが、TGW のデータ処理料金は $0.02/GB、リソースエンドポイントのデータ処理料金は $0.01/GB であり、本方式は特にデータ量が圧倒的である場合、コスト削減に大きく寄与します。 図5：集約 VPC とリソースゲートウェイによるオンプレミスからのパブリックエンドポイントへのアクセス ユースケース 4：Transit Gateway や VPC ピアリングを経由せずに AWS サービスのインターフェースエンドポイントを集約する インターネットを経由せずに AWS サービスへのプライベート接続を実現するには、インターフェース VPC エンドポイントを使用できます。しかし、各 VPC でサービスごとに個別のインターフェース VPC エンドポイントを作成すると、大きなコストと管理の複雑さにつながる可能性があります。そのため、より効率的なアプローチは、必要な すべてのインターフェースエンドポイントをホストする集約 VPC を用意し、AWS Transit Gateway または AWS VPC ピアリング接続を使用してコンシューマー VPC とリソース VPC 間の接続を確立し、集約 VPC エンドポイントへの接続を実現することです。 リソースゲートウェイとリソースエンドポイントは、このユースケース（特に大規模ネットワーク）に対処するための、よりシンプルでコスト効率の高いオプションを提供します。Transit Gateway アタッチメントよりも低い全体コスト（時間あたりおよびデータ処理）で、単一のリソースエンドポイントを作成して複数の AWS サービスエンドポイントにアクセスできます（集約 VPC エンドポイントが主なユースケースであることを前提）。図6は、このユースケースのハイレベルアーキテクチャ図を示しています。 図6：リソースゲートウェイを使用した集約 VPC エンドポイントへのアクセス リソースゲートウェイを使用して集約 VPC エンドポイントへのプライベート接続を確立する方法は以下のとおりです。 リソース VPC に、要件に応じた AWS サービスの集約インターフェース VPC エンドポイントを作成する。 リソース VPC にリソースゲートウェイを作成する。 各 AWS サービス VPC エンドポイントに対して、「DNS」のリソース定義を持つリソース設定を作成する。ドメイン名には、インターフェース VPC エンドポイントのリージョナル DNS 名を追加する（例： vpce-xxxx.ec2.<region>.vpce.amazonaws.com ）。   注意 ：リソースゲートウェイでは、リソース設定の DNS 名がパブリックに解決可能である必要があるため、インターフェース VPC エンドポイントのプライベート DNS 名は機能しません。 子 DNS リソース設定を持つリソースグループを作成し、リソースグループをリソースゲートウェイに関連付ける。 （オプション）コンシューマー VPC とリソース VPC が異なる AWS アカウントにある場合、リソース VPC アカウントからコンシューマー VPC アカウントへ AWS RAM を通じてリソース設定を共有する。リソース設定が共有された後、コンシューマー VPC アカウントでリソース共有を承認する。 コンシューマー VPC に「Resource」タイプの VPC エンドポイントを作成し、リソース設定に関連付ける。 リソースエンドポイントとリソースゲートウェイに関連付けられたセキュリティグループにルールを追加して、必要なトラフィックを許可する。 （オプション）異なるドメイン名を使用してサービスエンドポイントにアクセスしたい場合は、ドメイン名 <region>.amazonaws.com のプライベートホストゾーンを作成し、コンシューマー VPC に関連付ける。アクセスする各サービスに対してプレフィックス付きの CNAME タイプのレコードを追加し（例： <prefix>.ec2.<region>.vpce.amazonaws.com ）、リソースエンドポイントの対応する DNS 名にポイントする。TLS 検証が正常に行われるようにするため、プライベートホストゾーンとレコードは上記の形式である必要がある。 プライベートホストゾーンで作成したレコード（例： <prefix>.<region>.vpce.amazonaws.com ）、またはリソースエンドポイントの DNS 名を使用して、アプリケーションからインターフェースエンドポイントにアクセスする。 まとめ 本記事では、VPC リソースゲートウェイを使用して AWS 環境における複雑なネットワーク課題を簡素化する方法を説明しました。プライベートなデータベース接続の確立、IP アドレスが競合するネットワーク間の通信の実現、セキュアなインターネットアクセスの作成、AWS サービスアクセスの合理化について解説しました。これらのソリューションは、VPC リソースゲートウェイが強固なセキュリティを維持しながら一般的なネットワーク課題に対処する方法を示しており、成長に合わせたクラウドアーキテクチャの構築に有用なツールとなります。 AWS ネットワーク構成を簡素化する準備はできましたか？ VPC リソースゲートウェイ のドキュメントを参照して、今すぐリソースゲートウェイの実装を開始し、ご自身の AWS 環境でこれらのパターンを試してみてください。 翻訳はソリューションアーキテクトの長屋が担当しました。

みなさん、こんにちは。ソリューションアーキテクトの西村です。 今週も 週刊AWS をお届けします。 さて、7月28日（火）に東京・赤坂インターシティにて、「 AWS Bedrock LLM Day Japan 」が開催されます。Anthropic や OpenAI、OSS の最新モデルから、先日の AWS Summit New York での発表まで、生成 AI の最新動向を半日で体験いただけるイベントです。Amazon Bedrock を活用してビジネスにイノベーションを起こされているユーザーの事例セッションもご用意しています。生成 AI の最新情報のキャッチアップや、ビジネスへの活かし方に課題をお持ちのお客様にとって有用な機会ですので、ぜひご参加ください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2026年7月6日週の主要なアップデート 7/6(月) Amazon SageMaker HyperPod が Disaggregated Prefill and Decode (DPD) に対応 Amazon SageMaker HyperPod が、LLM 推論の prefill フェーズと decode フェーズを分離して実行する Disaggregated Prefill and Decode (DPD) に対応しました。計算集約的な prefill とメモリ帯域集約的な decode をそれぞれ専用の GPU プールに割り当て、KV キャッシュを Elastic Fabric Adapter (EFA) 経由で転送します。これにより、トークンごとのレイテンシーが安定し、厳しいレイテンシー SLO のもとでもスループットを高められます。prefill / decode の容量を独立してスケールでき、インテリジェントルーターがリクエストを自動で最適配分するため、コストとパフォーマンスのバランスを取りやすくなります。EKS オーケストレーターと EFA 対応インスタンスを使用でき、SageMaker HyperPod が提供されている全リージョンでご利用いただけます。 Amazon Cognito がレート制限のセルフサービス設定に対応 Amazon Cognito が、API レート制限をセルフサービスで設定できる新しいプロビジョニング API に対応しました。コンソールまたは API から、アカウントレベルの上限までレート制限を自分で設定でき、変更は即座に反映されます。これまでサービスクォータ経由で必要だった手動の審査プロセスや待ち時間なしに、トラフィックパターンに応じてレート制限を柔軟に増減できます。急なトラフィック増加やキャンペーン時にも、事前のクォータ引き上げ申請を待たずに対応できるようになります。Amazon Cognito が利用可能なすべての AWS リージョンでご利用いただけます。 Amazon CloudWatch Application Signals が Service Events を提供開始 Amazon CloudWatch Application Signals が、例外・レイテンシーのスナップショット、関数レベルのパフォーマンスデータ、デプロイイベントを自動収集する Service Events を提供開始しました。ADOT SDK や CloudWatch Observability EKS アドオンで計測しておくだけで、コードを変更することなくこれらのイベントを自動的にキャプチャできます。デプロイ後に新たに発生した例外を素早く特定できるため、リリース後の問題調査にかかる時間を短縮できます。オプションで関数呼び出しメトリクスを有効にすれば、さらに細かい可視化も可能です。Java / Python / JavaScript に対応し、すべての商用 AWS リージョンでご利用いただけます。 7/7(火) Amazon SageMaker Unified Studio が既存 MWAA 環境のインポートに対応 Amazon SageMaker Unified Studio が、既存の Amazon Managed Workflows for Apache Airflow (MWAA) 環境をプロジェクトにインポート・接続できるようになりました。Workflows ツールで「Add connection」を選択し、Airflow の設定を入力するだけで、運用中の環境をそのまま利用できます。DAG を再作成したり移行したりすることなく、分析や機械学習と同じインターフェースからワークフローを管理できる点が魅力です。Apache Airflow 3 以降では、ドラッグ＆ドロップエディタによるビジュアルオーサリングも利用できます。Amazon SageMaker Unified Studio が利用可能なすべての AWS リージョンでご利用いただけます。 Amazon ECS Managed Instances が GPU の管理料金を最大 60% 引き下げ Amazon ECS Managed Instances が、GPU インスタンスの管理料金を引き下げました。G シリーズは 35%、P シリーズおよび AWS Trainium は 60% の値下げとなり、GPU ワークロードをよりコスト効率よく実行できます。ECS Managed Instances はインフラを AWS が完全管理し、GPU メトリクスの自動監視や、ハードウェア障害の自動検出・修復も備えています。CloudWatch Container Insights による可視化と障害時の自動復旧により、運用負担を抑えつつ稼働停止時間を最小化することが可能です。ECS Managed Instances が利用可能なすべての AWS リージョンでご利用いただけます。 Amazon RDS for Oracle が Oracle Database 26ai のサポートを開始 Amazon RDS for Oracle が、最新の長期サポートリリースである Oracle Database 26ai のサポートを開始しました。自然言語から SQL を生成・実行する Select AI や、ベクトル埋め込みをデータベース内に格納してセマンティック検索を実現する Oracle AI Vector Search を利用でき、SQL 内で直接 RAG (Retrieval Augmented Generation) を構築しやすくなります。データをデータベース外に持ち出すことなく、Anthropic Claude や Amazon Nova、Meta Llama などの基盤モデルを活用した高度な分析が可能です。JSON Relational Duality Views や SQL Property Graphs といった新しいデータアクセス方法も加わり、開発者やビジネスユーザーの生産性向上につながります。すべての商用 AWS リージョンおよび AWS GovCloud (US) リージョンでご利用いただけます。 7/8(水) Amazon Redshift の Graviton ベース RG インスタンスがトレーリングトラックで利用可能に Amazon Redshift の Graviton ベースの RG インスタンス（rg.xlarge、rg.4xlarge）が、安定性を重視するトレーリングトラック（P201）でも利用できるようになりました。RG インスタンスは RA3 インスタンスと比較して最大 2.4 倍高速なクエリ性能を提供し、vCPU あたりのコストを 30% 削減できます。本番環境の安定性を優先するお客様が、検証済みのトラック上でこの高いコストパフォーマンスを享受できます。AWS マネジメントコンソール、AWS CLI、AWS SDK から、新規クラスターの作成または既存クラスターのリサイズでご利用いただけます。 AWS Security Hub が Network Scanning を提供開始 AWS Security Hub が、環境内のリソースがインターネットから実際に到達可能かどうかを検出する Network Scanning を提供開始しました。セキュリティグループやルートテーブルの設定を評価するだけでなく、実際にプローブを行い、パブリック IP アドレスや仮想マシン、ロードバランサー、到達可能なポートと稼働中のサービスを特定して検出結果を生成します。設定ベースの検出を補完し、外部から実際にアクセスできるリスクを正確に把握できるため、攻撃対象領域の削減に役立ちます。AWS だけでなく Azure 環境も対象とし、Security Hub Essentials の契約であれば追加費用なしで、個別アカウントや組織全体で有効化できます。AWS Security Hub をサポートするすべての商用リージョンでご利用いただけます。 Amazon Aurora DSQL が変更データキャプチャ (CDC) の一般提供を開始 Amazon Aurora DSQL が、変更データキャプチャ (CDC) の一般提供を開始しました。insert / update / delete 操作の結果を変更イベントとして自動的にキャプチャし、Amazon Kinesis Data Streams に配信できます。これにより、マイクロサービス間のデータ同期や、AWS Lambda 関数のトリガー、Amazon S3・Amazon Redshift・Amazon OpenSearch Service へのデータ連携を、インフラを管理することなく実現できます。データベースワークロードへの影響を抑えた設計により、パフォーマンスに影響を与えずに変更データを取得できるのは実運用で効いてきます。Aurora DSQL が利用可能なすべての AWS リージョンでご利用いただけます。 7/9(木) Amazon SageMaker Feature Store が一括書き込みとレコード一覧の API を追加 Amazon SageMaker Feature Store が、複数レコードを単一リクエストで一括書き込みできる BatchWriteRecord と、フィーチャーグループ内のレコード識別子をページ単位で一覧表示できる ListRecords を追加しました。BatchWriteRecord は複数のフィーチャーグループにまたがる書き込みにも対応し、API 呼び出しを削減して、低レイテンシーで取り込みが可能になるほか、一部のレコードが失敗してもリクエスト全体は継続されます。ListRecords により、フィーチャーグループの内容を参照・監査・ライフサイクル管理でき、カスタムツールを構築する必要がなくなります。あわせて、オフラインストアのテーブル名・データベース名をカスタムで指定できるようになり、データカタログの整理も容易になりました。Amazon SageMaker Feature Store が利用可能なすべての AWS リージョンでご利用いただけます。 AWS Config が 191 個のマネージドルールを追加 AWS Config が、Amazon Bedrock、Amazon SageMaker、Amazon ECS、Amazon EKS、Amazon RDS、Amazon Redshift、Amazon S3、AWS CloudTrail など主要サービスに対応した 191 個のマネージドルールを追加しました。暗号化、ロギング、パブリックアクセス、ネットワークセキュリティ、データ保護といった設定を自動で評価でき、AI ワークロードからクラウドインフラまでガバナンスの適用範囲が広がります。ルールは個別に、またはコンフォーマンスパックとして一括でデプロイできるため、複数サービスにまたがるベストプラクティスの適用やコンプライアンス管理を効率化できます。 7/10(金) Amazon EC2 R8in / R8ib / R8idn / R8idb インスタンスが東京リージョンなどで利用可能に メモリ最適化インスタンスの Amazon EC2 R8in、R8ib、R8idn、R8idb が、アジアパシフィック（東京）およびヨーロッパ（フランクフルト、アイルランド）を含むリージョンで追加で利用可能になりました。第 6 世代 Intel Xeon Scalable プロセッサと第 6 世代 AWS Nitro カードを搭載し、前世代（R6in / R6idn）と比較して vCPU あたり最大 43% のコンピューティング性能向上を実現します。R8in / R8idn は最大 600 Gbps のネットワーク帯域幅を、R8ib / R8idb は最大 300 Gbps の EBS 帯域幅を提供し、リアルタイムのビッグデータ分析や分散キャッシュ、AI/ML クラスター、大規模商用データベースなど、メモリ集約型のワークロードに適しています。 AWS DMS Schema Conversion が AWS MCP Server による AI エージェント自動化に対応 AWS Database Migration Service (DMS) Schema Conversion が、AWS MCP Server を介した AI エージェント自動化に対応しました。Kiro、Claude Code、Cursor などの AI コーディングエージェントを接続することで、自然言語による指示から、プロジェクト作成、ソースメタデータの参照、スキーマ変換、評価レポートの生成、結果のエクスポートまで、マイグレーションのワークフロー全体を IDE から直接実行できます。ストアドプロシージャや関数、トリガーといったコードの変換も支援し、試行錯誤のループを削減できる点がうれしいポイントです。追加料金なしで、既存のすべての ソース/ターゲットエンジンの組み合わせでご利用いただけます。 AWS Organizations が新規組織にアカウント離脱防止のセキュリティコントロールをデフォルト適用 AWS Organizations が、コンソールから新規に組織を作成する際に、メンバーアカウントの組織からの離脱や自己クローズを防ぐサービスコントロールポリシー (SCP) を自動的に適用するようになりました。これにより、深いセキュリティ知識がなくても、初日から強固なガバナンスパターンを確立でき、初期構成が簡略化されます。適用される設定は必要に応じて自由にカスタマイズできます。現在では、米国東部（バージニア北部）、AWS GovCloud (US-East / US-West)、中国リージョンでご利用いただけます。 それでは、また来週！ 著者について 西村 忠己(Tadami Nishimura) / @tdmnishi AWS Japan のソリューションアーキテクトとして、小売・消費財業種のお客様を担当しています。データガバナンスの観点から、お客様がデータ活用を効果的に行えるようなデモンストレーションなども多く行っています。好きなサービスは Amazon Aurora と Amazon Quick です。趣味は筋トレで、自宅に徒歩０分のトレーニングルームを構築して、日々励んでいます。

2026 年 7 月 1 日より、Claude Sonnet 5 が Kiro の IDE 、 CLI 、 Web でご利用いただけるようになりました。Sonnet 5 は Anthropic がこれまでに提供した中で最もエージェント性能に優れた Sonnet モデルであり、Sonnet 4.6 から大幅にアップグレードされ、推論力・ツール利用・コーディング能力が強化されています。しかも価格は Sonnet クラスのままです。 Sonnet クラスの価格で、Opus クラスに近いエージェント性能を 多くの開発者にとって、Agentic AI の時代は Sonnet クラスのモデルから始まりました。しかし最近では、エージェント性能における最も明確な向上は Opus 系列で見られていました。Sonnet 5 はこのギャップを縮めます。推論、ツール利用、コーディング、知的作業において、その性能は Opus 4.8 に近づきつつ、コストは大幅に抑えられています。 Kiro では、これにより実質的な「コストと性能の選択肢」が手に入ります。最も難しいタスクで最大限の精度が必要なときは Opus 4.8 を、強力なエージェント性能をより多く実行できる価格帯で使いたいときは Sonnet 5 を選べます。両者の間で実行レベルを調整し、タスクごとに最適なバランスを見つけることができます。 エンドツーエンドのエージェント作業のために構築 Kiro の IDE、CLI、Web 全体において、Sonnet 5 は編集前に計画を立て、監督なしでより長く動作し続け、明示的に指示されなくても自身の出力を確認します。初期テストを行ったユーザーからは、従来の Sonnet モデルでは途中で止まってしまっていた複雑なタスクを最後までやり遂げる、という感想が一貫して寄せられています。 IDE における 仕様駆動のワークフロー では、これはより広範囲な変更において、スペックからのズレが少ない、より忠実度の高い実装につながります。CLI と Web においては、ブラウジング、ターミナル操作、複数ファイルにわたるリファクタリングといった複数ステップのエージェントタスクが、より確実に完了まで到達し、手詰まりが減り、密に監督する必要も少なくなります。 利用可能な環境 Sonnet 5 は、AWS us-east-1 (バージニア北部)リージョンおよび AWS Europe (フランクフルト) リージョンにおいて、クロスリージョン推論のサポートとともに、Kiro Pro、Pro+、Pro Max、Power のお客様に対して 実験的サポートとして 段階的に展開されます。100万トークンのコンテキストウィンドウを備え、クレジット倍率は Sonnet 4.6 と同じ 1.3 倍です。 トークナイザーの変更に関する注記 : Sonnet 5 は更新されたトークナイザーを使用しており、Sonnet 4.6 とはテキストの処理方法がわずかに異なります。同じ入力でも、コンテンツの種類によっておおよそ 1.0〜1.35 倍のトークン数になる場合があります。 Kiro をダウンロード するか、IDE や CLI を再起動して最新のモデルを確認してください。 Web をご利用の方 は、ブラウザを再読み込みするとモデルセレクターに Sonnet 5 が表示されます。 本記事は Sonnet 5 is now available in Kiro (2026年7月1日公開、著者: Vipin Mohan)の日本語翻訳版です。

みなさん、こんにちは。ソリューションアーキテクトの武松です。 AWS は数十年にわたり、世界中で事業を展開する何百万のお客様を同時に保護するためのプロセスとツールを開発してきました。AWS のセキュリティチームと脅威インテリジェンスチームは、日々 AI と自動化を駆使した取り組みを続けています。たとえば AI を活用したログ分析により、SecOps エンジニアがセキュリティログの分析に要する時間は平均 6 時間からわずか 7 分へと短縮され、この 50 倍もの生産性向上により脅威の検出と対応をかつてないスピードで行えるようになっています。あるお客様を保護する過程で得た知見は、すべてのお客様の保護に役立ちます。この規模で運用しているからこそ、新たに検出した脅威がすべてのお客様の防御強化に直結します。AI はすでにその中核を担っています。 2026 年 4 月 7 日、 Anthropic が Project Glasswing を発表しました 。世界で最も重要なソフトウェアの保護と、AI の進化に伴い業界に求められるサイバーセキュリティの実践を前進させることを目的としたイニシアチブです。これを支えるのが、サイバーセキュリティにおける推論能力と AI 能力の飛躍的な進歩を実現する新しいクラスの AI モデル Claude Mythos です。Claude Mythos は Anthropic のこれまでのフロンティアモデルを上回る知性と能力を備え、サイバーセキュリティやソフトウェアコーディング、複雑な推論タスクで高いパフォーマンスを発揮します。Project Glasswing の一環として、AWS では継続的な AI セキュリティレビューが行われている重要なコードベースに Claude Mythos をすでに適用しています。十分にテストされた環境であっても、コードをさらに強化できる箇所の特定に役立っています（参考：「 AI を活用した大規模なセキュリティ防御の構築 — 脅威が出現する前に 」）。 しかし、こうした強力な AI は防御側だけのものではありません。国家レベルの攻撃者やランサムウェアオペレーター、サプライチェーン攻撃者も、すでに AI を活用して攻撃のスケールを拡大しています。 AWS Japan パブリックセクター技術統括本部では、2026 年 4 月より、官公庁・自治体・教育・医療などパブリックセクターのお客様向けのセキュリティワークショップシリーズを月次で開催しています。4 月・5 月の第 1 回・第 2 回ではランサムウェア対策をテーマに、 Amazon GuardDuty や AWS Security Hub を用いた脅威検知と統合セキュリティ管理を扱いました（参考：「 第 1 回・第 2 回の開催レポート 」）。続く 6 月・7 月の第 3 回・第 4 回では、 金融庁が対応を要請 し、 厚生労働省が医療機関等との意見交換を開始する など状況が急速に変化する中、一刻も早く実践的な対策をお届けすべく、テーマを「Claude Mythos 時代の脅威への対応」とし、第 3 回で Amazon Inspector 、第 4 回で AWS Security Agent を用いたハンズオンを実施しました。 本記事では第 3 回・第 4 回の開催レポートをお届けします。 ワークショップの概要 第 3 回・第 4 回のワークショップは「Claude Mythos 時代の脅威への対応」を共通テーマとしています。講師はシニア セキュリティ ソリューションアーキテクトの中島 章博氏が務めました。セキュリティは組織全体で取り組むテーマであることを踏まえ、考え方を理解する座学と手を動かすハンズオンの 2 部構成とすることで、幅広い立場の方にメリットがあるよう工夫しています。前半の座学でフロンティア AI 時代の脅威動向やセキュリティ対策の考え方を解説し、後半はハンズオン形式で実際に AWS のセキュリティサービスを体験していただきました。 座学では、Claude Mythos / Project Glasswing の登場により今後予想される 2 つの脅威を解説しました。(1) 大量の脆弱性が公開されパッチ適用が追いつかなくなる N デイ攻撃の増加と、(2) フロンティア AI の一般化によるサイバー攻撃高度化とゼロデイ攻撃の増加です。対応策として、前者にはパッチ適用の日常業務化やマネージドサービスの活用、後者には AI を活用した脆弱性スキャンとセキュリティレビューをご紹介しました。これらの対策を実践するハンズオンとして、第 3 回では Amazon Inspector による脆弱性管理とパッチ運用の自動化を、第 4 回では AWS Security Agent による設計レビュー・コードレビュー・自動ペネトレーションテストを通じた AI エージェントによるプロアクティブなセキュリティ評価を体験いただきました。 Claude Mythos 時代のサイバーセキュリティ 第 3 回: Amazon Inspector で実現する脆弱性管理（2026 年 6 月 12 日） Amazon Inspector とは Amazon Inspector は、 Amazon Elastic Compute Cloud (Amazon EC2) インスタンス、コンテナイメージ、 AWS Lambda 関数などのワークロードやコードリポジトリを自動的に検出し、ソフトウェアの脆弱性や意図しないネットワークへの露出がないかスキャンする脆弱性管理サービスです。 ハンズオン概要 参加者一人ひとりにワークショップ専用の AWS サンドボックス環境が払い出されます。この環境には複数の Amazon EC2 インスタンス、コンテナイメージ、Lambda 関数があらかじめデプロイされており、Amazon Inspector が継続的にスキャンし脆弱性を検出しています。参加者はセキュリティ担当者の立場で、検出（Detect）→ 優先順位付け（Prioritize）→ 修復（Remediate）の一連の流れを体験します。 ハンズオンは「基礎・検出」「修復・自動化」の 2 パートで構成されています。 前半の基礎・検出パートでは、Amazon Inspector ダッシュボードでカバレッジと脆弱性の全体像を把握し、検出結果の重大度・影響リソースの読み方を学びます。抑制ルールによるノイズ削減や、CVE 脆弱性データベースでの CVSS スコアの調査も行います。 後半の修復・自動化パートでは、 AWS Systems Manager Patch Manager を使い、Amazon Inspector が検出した脆弱性に対してフリート全体でパッチを一括適用します。パッチベースラインの定義から、Run Command による Amazon EC2 インスタンスのスキャンと不足パッチのインストール、パッチポリシーによるスケジュール設定まで実施いただきました。そして、パッチ適用後に Amazon Inspector が再スキャンし、検出結果が自動的にクローズされる継続的な脆弱性管理の流れを体験いただきました。さらに、Lambda 関数のコードスキャンで検出された脆弱性を修正して Amazon Inspector で修復を確認するサーバーレスの脆弱性管理や、Amazon Inspector SBOM Generator と Inspector Scan API を組み合わせた CI/CD パイプラインへの脆弱性スキャン統合にも取り組みました。 「Amazon Inspector を有効にしたが、検出結果の優先順位付けや実際のパッチ適用プロセスをどう自動化すればよいかわからない」という方にとって、開発ライフサイクル全体（コード → ビルド → デプロイ → 実行）での脆弱性管理を安全な環境で体験できる内容です。ワークショップ教材は「 アプリケーションセキュリティワークショップ 」として公開しています。 Amazon Inspector ワークショップ環境の概要 第 4 回: セキュリティ運用を支援する AWS Security Agent（2026 年 7 月 2 日） AWS Security Agent とは AWS Security Agent は、すべての環境における開発ライフサイクル全体でアプリケーションを積極的に保護するフロンティアエージェントです。お客様のアプリケーションに合わせたオンデマンドのペネトレーションテストを実施し、確認済みのセキュリティリスクを発見して報告します。また、お客様の要件に合わせてカスタマイズされた自動セキュリティレビューを実施し、設計からデプロイまでセキュリティを統合することで、脆弱性を早期かつ大規模に防ぐのに役立ちます。 ハンズオン概要 第 3 回と同様に参加者ごとにサンドボックス環境が払い出されます。この環境には、学習用に意図的に脆弱性を持たせた架空の Web サイト Juice Shop が AWS Fargate 上にデプロイされており、AWS Security Agent が設計・コード・本番環境をそれぞれ検証できる状態になっています。参加者はセキュリティ担当者の立場で、要件定義（Requirements）→ 設計レビュー（Design Review）→ コードレビュー（Code Review）→ ペネトレーションテスト（Pentest）の一連の流れを体験します。 ハンズオンは 4 つのモジュールで構成されています。 Module 1（セキュリティ要件） : AWS Security Agent がレビュー時に適用するセキュリティ基準を定義します。業界標準とベストプラクティスに基づき AWS が提供・維持するマネージドセキュリティ要件に加え、組織固有のポリシーに対応するカスタムセキュリティ要件（JWT 認証のベストプラクティス、FTP/SFTP によるファイルホスティングの禁止など）を作成しました。 Module 2（設計レビュー） : Juice Shop アプリケーションの詳細な設計ドキュメントをアップロードし、Module 1 で定義したセキュリティ要件と照らし合わせた設計レビューを実施します。コードを書く前の段階で JWT 実装の問題などアーキテクチャ上のセキュリティ課題を発見できることを体験いただきました。 Module 3（コードレビュー） : リポジトリ全体を対象としたコードスキャンと、GitHub プルリクエストに対する自動分析の 2 種類のコードレビューを実施しました。設計レビューで指摘された JWT の問題をコードで修正し、PR を作成して AWS Security Agent からのフィードバックを確認しました。 Module 4（ペネトレーションテスト） : AWS Security Agent が Juice Shop に対して自律的に実行した自動ペネトレーションテストの結果を調査します。SQL インジェクションなどの確認済み脆弱性を AWS CloudShell から実際に再現し、検出結果の信頼性を確認しました。 「ペネトレーションテストを実施したいが、人手やコストの制約でなかなか実施できない」「開発ライフサイクル全体でアプリケーションを積極的に保護したい」という方にとって、AI エージェントを活用したセキュリティ運用の実践を体験できる内容です。ワークショップ教材は「 AWS Security Agent ハンズオン: プロアクティブな AppSec と自律型ペネトレーションテスト 」として公開しています。 AWS Security Agent ワークショップ環境の概要 参加者からのフィードバック 第 3 回は計 122 名、第 4 回は 59名 の方にご参加いただき、ご好評をいただきました。官公庁・教育・医療など幅広い組織からご参加いただいています。「とても分かりやすい座学・ハンズオンだった」「自組織での活用イメージが湧いた」「Inspector を利用してみたい」など、日々の運用に直結する学びを得られたというフィードバックをいただきました。 まとめと今後の取り組み 本ワークショップシリーズは、皆様のご要望に応じて今後も継続的に開催予定です。第 5 回（2026 年 8 月 21 日）は「耐障害性ライフサイクル実践ワークショップ ― FlyWheel で回す継続的なレジリエンス強化」をテーマに、たこ焼き注文システムを題材にした耐障害性ライフサイクルの各ステージを実践いただきます。ご関心のある方は担当の AWS アカウントチームまでお気軽にお声がけください。 ワークショップで学んだ内容を次のアクションにつなげるために、AWS では以下のようなセキュリティ支援を提供しています。 AWS セキュリティ成熟度モデル : 組織のセキュリティ対策の現在地を把握し、次に取り組むべき施策を明確にするフレームワークです。脆弱性管理やポスチャ管理が自組織ではどの段階にあるのか、確認してみてはいかがでしょうか。 脅威モデリングワークショップ : 設計段階からセキュリティを組み込みたい方に向けて、サンプルシステムを対象としたワークショップ形式のほか、実際のワークロードを対象とした個別支援も実施しています。 Security Health Improvement Program (SHIP) : お客様のセキュリティ状況を可視化し、改善に向けた具体的なアクションプランの策定と実行を継続的に支援するプログラムです。自組織のセキュリティを体系的に強化したい方におすすめです。詳しくは「 AI 時代におけるセキュリティ体制の強化 」もあわせてご覧ください。 上記の支援にご興味がある方は、担当の AWS アカウントチームまでお気軽にお声がけください。 著者 武松 未来 (Mirai Takematsu) — AWS Japan, Public Sector, Associate Solutions Architect 今井 真宏 (Masahiro Imai) — AWS Japan, Public Sector, Solutions Architect

こんにちは。アマゾン ウェブ サービス ジャパン合同会社 パートナーソリューションアーキテクトの深井 宣之です。 2026 年 6 月 5 日に AWS 公共パートナーネットワーク（PSN）セミナーとして「IT 基盤の環境変化に対応する AWS マイグレーション」と題した Webinar を開催しました。本ブログでは開催内容について Blog にまとめたものになります。投影資料もダウンロードすることが可能です。 本セミナーでは、アマゾン ウェブ サービス ジャパン合同会社 パブリックセクター統括本部 パートナーアカウントマネージャーの坂口 雄一郎と、同 パブリックセクター技術統括本部 パートナーソリューションアーキテクトの深井 宣之が登壇し、ハードウェアの価格高騰や納期遅延、仮想化ソフトウェアのライセンス体系変更といった IT 基盤を取り巻く環境変化を踏まえ、AWS マイグレーションの全体像をご紹介しました。初級レベルの内容として、AWS やクラウドの知識がない方にもご参加いただける構成としています。 資料（PDF）の ダウンロードはこちら から可能です。 IT 基盤を取り巻く環境変化 近年、エンタープライズサーバーやメモリ、SSD ストレージなどハードウェアの価格高騰が続いており、リードタイムも延長しています。多くの現場では納期が読めず、入札や調達計画に影響が出ているのが実態です。 加えて、仮想化ソフトウェアのライセンス体系変更により、既存の IT 基盤を従来と同じコストで維持することが困難になるケースが増えています。 セキュリティ面では、AI を悪用したサイバー攻撃が高度化しており、Claude Mythos に象徴されるような AI 時代のセキュリティ脅威が現実のものとなっています。一方で、日本政府は行政機関での AI 徹底利活用を基本方針として決定しており、守りと攻めの両面での対応が求められています。 AWS が選ばれる理由 こうした環境変化を踏まえ、マイグレーション先の IT 基盤として AWS が選ばれる 7 つの理由を紹介しました。 IT リソース調達時間の短縮 — オンデマンドで即座にリソースを確保でき、数か月の調達リードタイムから解放 コスト最適化 — 従量課金モデルにより、使った分だけの支払いが可能 継続的な値下げ — AWS はこれまで 161 回 (2026年 5月時点) の値下げを実施 耐障害性と高可用性 — グローバルインフラストラクチャにより、マルチ AZ 構成での高可用性を実現 AI 時代に対応するセキュリティ — AWS は主要なコンプライアンスに準拠しておりその中で ISMAP 認定も取得。AWS では従前より AI を活用したセキュリティの高度化に取り組む 最新 AI サービスへのアクセス — Amazon Bedrock をはじめとする AI サービスや、Anthropic 社との戦略的提携による最新モデルへのアクセスが可能 移行を成功に導くためのソリューション — 移行ツールやプログラムが充実 AWS マイグレーションの進め方 移行パス AWS では移行戦略として 7 つのパス（7R）を定義しています。多くのケースではリホスト（Lift-and-shift）で移行し、まず AWS に移行することでハードウェア保守から解放され、空いた工数でモダナイゼーションに注力する段階的アプローチが一般的です。 リロケート: Amazon Elastic VMware Service (Amazon EVS) VMware 環境をそのまま AWS に移行する場合は、Amazon Elastic VMware Service（Amazon EVS）が活用できます。東京リージョンで既に利用可能です。 リホスト: AWS Application Migration Service（AWS MGN） OS やアプリケーションをそのまま移行するリホストには AWS MGN が利用できます。継続的にデータをレプリケーションし、ダウンタイムを最小化します。エージェント型とエージェントレス型の 2 つの方式があります。 データベース移行: AWS Database Migration Service (AWS DMS) と AWS Schema Conversion Tool (AWS SCT) データベースの移行には AWS DMS が利用できます。異なるエンジン間の移行では AWS SCT を併用します。 モダナイゼーション: AWS Transform AWS Transform は大規模な移行とモダナイゼーションのための初のエージェント型 AI サービスです。 コスト把握: Migration Evaluator 移行後コストを事前に把握する無料サービスです。約 1 週間のデータ収集後に評価レポートを提示します。 MAP（Migration Acceleration Program） MAP は移行時の二重投資負荷を軽減するため、クレジットや現金還元を提供するプログラムです。MAP の詳細は AWS Partner Central をご参照ください。 お客様事例 東京都中央区 — Amazon WorkSpaces による VDI 刷新 オンプレミス VDI のレスポンス低下を Amazon WorkSpaces で解消。基幹系・内部事務系の両セグメントで利用しています。 岩手県教育委員会 — 共同利用型校務支援システム 全 33 市町村が共同利用する校務支援システムの基盤として AWS を採用。校務支援システムを含む学校関連のIT基盤では、長崎県、新座市、名古屋市、福岡市でも実績があります。 同志社大学 — 情報インフラの全体最適化 4 系統の情報インフラを AWS に移行。AWS MGN を活用し、ダウンタイム削減とコスト最適化を実現しました。 おわりに IT 基盤を取り巻く環境は大きく変化しています。AWS はこうした環境変化への対応を支援します。ご興味をお持ちの方は御社担当の Partner Account Manager にお気軽にご連絡ください。 このブログは、アマゾン ウェブ サービス ジャパン合同会社 パートナーソリューションアーキテクト 深井 宣之が執筆しました。

本ブログは井村屋グループ株式会社様、株式会社 Hashup 様、Amazon Web Services Japan 合同会社が共同で執筆いたしました。 みなさん、こんにちは。AWS アカウントマネージャーの藤川です。 昨今、食品・製造業のお客様から「需要予測の精度向上」や「属人化した業務の自動化」についてご相談いただく機会が増えています。特に食品業界では、賞味期間の制約や季節変動の大きさから、需要予測の精度が欠品・廃棄に直結するため、AI 活用への期待が高まっています。 1896年の創業から130年、1947年の設立から80年目を迎え「あずきバー」や「肉まんあんまん」で知られる 井村屋グループ株式会社 様（以下、井村屋グループ様）は、 株式会社 Hashup 様（以下、Hashup 様）と連携し、 Amazon SageMaker Canvas を活用したチルド製品（肉まん・あんまん・ピザまん等）の翌日出荷数 AI 需要予測の自動化のPOCを実施しました。本記事では、熟練担当者の経験と勘に依存していた需要予測業務を、AWS 上で再現・自動化した取り組みについてご紹介します。 お客様の状況と検証に至る経緯 井村屋グループ様は、DX 戦略プロジェクト（2024年度完了）を経て、需給管理と SCM 標準化プロジェクトを推進してきました。その次のステップとして、標準化された需給データを活用した AI 需要予測システムの導入に着手しました。 同社のチルドタイプの肉まんあんまんは、季節性や営業施策によって出荷量の変動が大きく、さらに賞味期間が短いため、特に高い予測精度が求められます。しかし、従来の予測業務は熟練担当者の経験と勘に依存しており、欠品や廃棄のリスクが高く、生産・出荷計画の最適化が困難な状況でした。 「業務担当者が毎日約2時間をかけて、複数の Excel シートや kintone アプリ、基幹システムからデータを手作業で抽出・整形し、前週トレンドや経験則をもとに翌日の出荷数を決定していました。まさに運用当初から継ぎ足して使われてきた”秘伝のたれ”のような業務でした」と熟練担当者は当時を振り返ります。 また、この業務は特定の担当者に属人化しており、引き継ぎリスクや、気象データなど予測に有効な外部情報を活用できていないという課題もありました。 こうした課題を解決するため、井村屋グループ様は AWS とのパートナーシップに加え、AI・データ活用に強みを持つ Hashup 様をコンサルティングパートナーとして迎え、3 社体制でPOCを実施・推進しました。 ソリューション／構成 Hashup 様が中心となり、AWS 上に以下の 2 つのアプローチでシステムを構築しました。 ① 業務自動化：データレイクの構築 複数の Excel シート、kintone アプリ、基幹システムに散在していたデータの参照・抽出・整形の流れを、AWS 上にデータレイクとして構築し自動化しました。 ·     kintone や基幹システムのデータを AWS 上に自動連携 ·     毎日約2時間かけて手作業で作成していた見込シートを、ボタンひとつで 5 秒で自動生成 ·     気象情報も自動取得し、予測の参考データとして活用可能に 「担当者様へのヒアリングを何度も実施し、複雑なデータの流れを完全に理解した上で AWS 上に再現しました。担当者様がスムーズに移行できるよう、出力は既存の見込シートとできるだけ同じ見た目になるよう配慮しています」と Hashup 様は構築時のこだわりを語ります。 ② AI 需要予測：Amazon SageMaker Canvas による時系列予測モデル Amazon SageMaker Canvas の AutoML 機能を活用し、時系列予測モデルを構築しました。 ·       学習データ : 過去 2 年半の出荷実績データに、気温（代表 6 地点の平均最高・最低気温）、販促情報、前週トレンドなどを説明変数として投入 ·       予測対象 : チルドまん各商品の翌日出荷数 ·       モデル構築 : AutoML によりハイパーパラメータ最適化を自動実行し、最もパフォーマンスの高いモデルを自動選択 ·       有効因子 : 日本の祝日（SageMaker が自動付与）、気温、小売見込、前日計、前週トレンドなどが予測に寄与 導入効果 AI 需要予測システムのPOC実施により、以下の顕著な効果が得られました。 ·       業務工数 90% 削減 : 毎日約2時間を要していた予測業務のデータ抽出・前処理・予測・結果出力を自動化し、手作業をほぼゼロに ·       熟練担当者と同等以上の予測精度を実現 : あんまん: AI 6.0% vs 担当者 6.2%（WAPE）— AI が同等 ゴールド肉まん: AI 9.8% vs 担当者 15.4%（WAPE）— AI が大幅に上回る ·       属人化からの脱却： 特定担当者の経験・勘に依存しない、再現性のある予測プロセスを確立 ·       外部データの活用： 従来取り入れられていなかった気象データを予測に組み込み、精度向上に貢献 「Amazon SageMaker Canvas の AutoML 機能により、機械学習の専門知識がなくても高精度な時系列予測モデルを構築できました。また、AWS 上にデータレイクを構築したことで、これまで散在していたデータが一元化され、AI 予測だけでなく今後のデータ活用基盤としても機能しています」と井村屋グループ様は技術面でのメリットを説明します。 Hashup 様は「井村屋グループ様のデジタル戦略室の皆様に多大なるご協力をいただき、担当者様への丁寧なヒアリングを重ねることで、長年培われてきた”秘伝のたれ”とも言える業務ノウハウを AWS 上に忠実に再現できました。AWS のマネージドサービスを活用することで、2025 年 11 月の開始からわずか約 4 ヶ月で概念実証を完了できたことも大きな成果です」とプロジェクトを振り返ります。 AWS Summitと同日に幕張メッセ併設の国際会議場で開催されたプライベートセッション「AI Leaders Session」ご登壇時の様子（井村屋グループ株式会社 執行役員常務 デジタル戦略室長 岡田孝平様） 今後の展望 「2026 年 秋冬のチルドまんシーズンに向けて、業務自動化から AI 需要予測までの一気通貫システムへの完全移行を目指しています。さらに、kintone の特売見込み情報と連携した長期の出荷予測を実現し、原材料発注計画の AI 予測・自動化にも取り組んでいきます。他カテゴリへの AI 予測の展開も計画しています」 また、今回のプロジェクトを通じて AWS 上のデータレイクに蓄積された販売実績・気象・販促などの多様なデータを、需要予測だけでなく経営判断や現場のアクションにも活かしていくため、 Amazon Quick の活用もご検討いただいています。AI が生成した予測値と実績の乖離をダッシュボードでリアルタイムに可視化することで、予測精度のモニタリングや、需要変動の要因分析をより直感的に行える環境の構築を目指しています。 株式会社Hashup 代表取締役 CEO 神野 悦太郎様（左端） 井村屋グループ株式会社 執行役員常務 デジタル戦略室長 岡田孝平様（左から二番目） Amazon Web Services Japan : アカウントマネージャー 藤川 高志朗（右から二番目）、ソリューションアーキテクト 古屋 楓（右端）

本文は 2026年6月26日 に公開された AWS Cloud WAN Routing Policy: Real-World Global Network Scenarios (Part 2) を翻訳したものです。 Part 1 では、 AWS Cloud WAN のルーティングポリシーを紹介し、グローバルネットワーク全体でルート伝播とパス選択に影響を与えるためのきめ細かな制御をどのように使用できるかを示しました。各ルーティングポリシーは、3つの主要コンポーネントで構成されます。1) マッチ条件：ルートプレフィックスまたは BGP 属性を評価します。2) アクション：マッチしたルートの処理方法を決定します。3) 方向性：ポリシーをインバウンドとアウトバウンドのどちらのルート伝播に適用するかを指定します。これらの構成要素は、アタッチメント、セグメント、またはリージョンのレベルで適用できます。 本記事では、これらの概念を踏まえ、ハイブリッド環境やマルチサイト環境で一般的に見られる3つの実運用シナリオを取り上げます。AWS Cloud WAN のルーティングポリシーを使用して、 AWS Transit Gateway 環境からの移行中にルーティングを制御する方法、ローカルプリファレンスを使用して複数の AWS Direct Connect ロケーション間のパス選択を改善する方法、そして同一の BGP 自律システム番号（ASN）を持つネットワーク間の接続を許可する方法を学びます。 これらのパターンは、AWS Cloud WAN を集中型のポリシー適用ポイントとして使用し、グローバルネットワーク全体のルーティング制御を簡素化する方法を示しています。 本記事で説明するシナリオは、網羅的なリストではありません。AWS Cloud WAN のルーティングポリシーは、ここで扱う以外にも追加のマッチ条件とアクションをサポートしているため、お客様の環境固有のルーティング課題に対応できます。利用可能なマッチ条件とアクションの完全なリストについては、 AWS Cloud WAN ルーティングポリシーのドキュメント を参照してください。 前提条件 本記事は、2部構成のシリーズの第2回です。マッチ条件、アクション、方向性、基本的な設定ワークフローなど、ルーティングポリシーの基礎を扱った Part 1: AWS Cloud WAN Routing Policy — Fine-grained controls for your global network を既に読まれていることを前提とします。また、 Amazon Virtual Private Cloud（Amazon VPC） 、AWS Cloud WAN、AWS Direct Connect、 AWS Site-to-Site VPN などの主要な AWS ネットワークサービス、および AS-path、ローカルプリファレンス、コミュニティ属性といった概念を含む Border Gateway Protocol（BGP） の基礎を理解していることを前提とします。AWS Cloud WAN のハイブリッド接続パターンに関する補足的な背景情報については、 Simplify global hybrid connectivity with AWS Cloud WAN and AWS Direct Connect integration を参照することを推奨します。 補足：AWS Cloud WAN のルーティングポリシーには、コアネットワークポリシーバージョン 2025.11 以降が必要です。本記事で説明する設定を実装する前に、コアネットワークがこのバージョンで動作していることを確認してください。 シナリオ1：既存の Transit Gateway 環境からのルート伝播の制御 AWS Cloud WAN を採用する場合、既に AWS Transit Gateway 上に構築された既存環境を運用しているかもしれません。移行中は、これらの環境を AWS Cloud WAN に接続することで、一度きりのカットオーバーではなく、段階的な移行が可能になります。 こうしたアーキテクチャでよくある要件は、AWS Cloud WAN が Transit Gateway から学習したルートを、ネットワークの他の部分、特に AWS Direct Connect や AWS Site-to-Site VPN を通じて接続されたオンプレミス環境にどのように伝播するかを制御することです。 次の図（図1）は、ルーティングポリシーが適用されていない場合に、AWS Cloud WAN 内でルートがどのように学習され、伝播されるかを示しています。この例では、ap-southeast-2 リージョンの Transit Gateway が、AWS Direct Connect を通じてオンプレミスのデータセンター（DC1）に接続されています。この Transit Gateway が AWS Cloud WAN にアタッチされると、DC1 は重複したルートを受信し始めます。1つ目のルートセットは、Transit Gateway から直接伝播されます。2つ目のセットは AWS Cloud WAN 自体から来るもので、AWS Cloud WAN は Transit Gateway ルートテーブルのアタッチメントから同じルートを学習し、それらを Direct Connect 経由で DC1 に再配布します。ルーティングポリシーがない場合、このルートの重複は、非効率的または予測不可能なルーティング動作につながる可能性があります。 図1：ルーティングポリシーがない場合のルート伝播動作 AWS Cloud WAN のルーティングポリシーは、BGP コミュニティのタグ付けとフィルタリングによってこの問題を解決し、どのルートをオンプレミス環境にアドバタイズするかを正確に制御できるようにします。 図2：ルーティングポリシー適用後のルート伝播動作 図2に示すように、Transit Gateway は自身の production ルートテーブルを AWS Cloud WAN の production セグメントに接続します。ルーティングポリシーは2つのステップで動作します。第1に、Transit Gateway ルートテーブルのアタッチメントから学習したルートに、BGP コミュニティ値（65000:1 など）をタグ付けします。第2に、このコミュニティタグを、production セグメントから hybrid セグメントへルートを共有する際のフィルタとして使用します。タグ付けされたルートは、hybrid セグメントの Direct Connect ゲートウェイ（DXGW）へはそれ以上アドバタイズ（伝播）されません。 その結果、オンプレミスのデータセンターは Transit Gateway から直接ルートのみを受信することになり、重複したアドバタイズが排除され、Transit Gateway が同じデータセンターに接続されたままのアーキテクチャにおけるルーティングの競合を回避できます。 補足：AWS Cloud WAN に直接アタッチされた新しい VPC は、Transit Gateway の背後にある既存の VPC が AWS Cloud WAN 上の VPC と通信できるように、自身の Classless Inter-Domain Routing（CIDR）ブロックを Transit Gateway にアドバタイズします。ただし、これらの CIDR ブロックは、その関連付けの 許可プレフィックスリスト に含まれていない限り、Transit Gateway の Direct Connect ゲートウェイの関連付けを通じてオンプレミスにはアドバタイズされません。これにより、Cloud WAN の VPC ルートが Transit Gateway パス経由で DC1 にアドバタイズされるのを防ぎ、AWS Cloud WAN の Direct Connect ゲートウェイをオンプレミスへの唯一のパスとして残します。 仕組み 既存の Transit Gateway から学習したルートは production セグメントに入り、アタッチメントのインバウンドポリシーによってコミュニティ 65000:1 でタグ付けされます。production の VPC と AWS Cloud WAN のリソースは、Transit Gateway のワークロードに通常どおり到達できます。一方、production のルートが hybrid セグメントと共有される際、アウトバウンドのセグメントフィルタリングポリシーがコミュニティタグ 65000:1 にマッチし、それらのルートをドロップします。その他すべての production ルート（VPC からのルート）は hybrid セグメントに通過し、Direct Connect 経由でオンプレミスにアドバタイズされます。これにより、同じ Transit Gateway に依然として直接接続されているデータセンターへの重複したルートアドバタイズを防ぎます。 ステップ1：Transit Gateway のルートにコミュニティをタグ付けする（Transit Gateway ルートテーブルアタッチメントでインバウンド） このインバウンドポリシーを、AWS Cloud WAN の Transit Gateway ルートテーブルアタッチメントに適用します。このポリシーは、Transit Gateway から学習したすべてのルートにマッチし、コミュニティ 65000:1 でタグ付けします。 { "routing-policies": [ { "routing-policy-number": 100, "routing-policy-name": "tagTgwRoutes", "routing-policy-description": "Tag routes learned from existing TGW with community 65000:1", "routing-policy-direction": "inbound", "routing-policy-rules": [ { "rule-number": 10, "rule-definition": { "match-conditions": [ { "type": "prefix-in-cidr", "value": "0.0.0.0/0" } ], "condition-logic": "and", "action": { "type": "add-community", "value": "65000:1" } } } ] } ] } ステップ2：セグメント共有時にタグ付けされたルートをフィルタリングする（prod → hybrid） このアウトバウンドポリシーを、production セグメントから hybrid セグメントへルートを共有する際に適用します。このポリシーは、コミュニティ 65000:1 を持つルートにマッチしてドロップし、Transit Gateway 由来のルートが hybrid セグメントおよび Direct Connect 経由でオンプレミスの DC に伝播されるのを防ぎます。コミュニティ値 65000:1 にマッチしないルートは暗黙的に許可され、通常どおり伝播を続けます。AWS Cloud WAN のルーティングポリシールールはデフォルト許可（default-allow）を基本として動作し、ドロップルールによって明示的にマッチしたルートのみがフィルタリングされます。 { "routing-policies": [ { "routing-policy-number": 200, "routing-policy-name": "filterRoutesToHybrid", "routing-policy-description": "Drop TGW-originated routes (community 65000:1) when sharing prod to hybrid", "routing-policy-direction": "outbound", "routing-policy-rules": [ { "rule-number": 10, "rule-definition": { "match-conditions": [ { "type": "community-in-list", "value": "65000:1" } ], "condition-logic": "and", "action": { "type": "drop" } } } ] } ] } ステップ3：ポリシーを配布ポイントに関連付ける 3.1 ルーティングポリシーラベルを使用して、タグ付けポリシーを Transit Gateway ルートテーブルアタッチメントに適用します。 { "attachment-routing-policy-rules": [ { "rule-number": 100, "conditions": [ { "type": "routing-policy-label", "value": "TgwInbound" } ], "action": { "associate-routing-policies": [ "tagTgwRoutes" ] } } ] } 関連付けを完了するには、routing-policy-label を Transit Gateway ルートテーブルアタッチメントに割り当てます。これは、アタッチメントの作成時に routing-policy-label パラメータを使用するか、AWS Cloud WAN コンソールで既存のアタッチメントを編集することで実行できます。このシナリオでは、ラベル TgwInbound を Transit Gateway ルートテーブルアタッチメントに割り当てます。 3.2 セグメント共有のレベルでフィルタリングポリシーを適用します。 { "segment-actions": [ { "action": "share", "mode": "attachment-route", "segment": "production", "share-with": [ "hybrid" ], "routing-policy-names": [ "filterRoutesToHybrid" ] } ] } シナリオ2：複数の Direct Connect ロケーション間でのパス選択の改善 複数のオンプレミスロケーションがある場合、耐障害性のために複数のサイトから同じプレフィックスをアドバタイズしていることが多いでしょう。これは可用性を向上させますが、AWS Cloud WAN が複数のロケーションから固有の優先度なしに同一のルートを受信するというルーティングの曖昧さを生み出します。追加の制御がなければ、トラフィックが適切に誘導されない場合に非効率的なルーティング決定につながる可能性があります。 ルーティングポリシーが適用されていない場合、AWS Cloud WAN はデフォルトのルーティング動作（ロンゲストプレフィックスマッチ）に依存し、ローカルプリファレンスやパスステアリングは行われません。図3に示すように、AWS Cloud WAN が同じプレフィックス（例えば DC2 から発信される 10.2.0.0/16）を3つの DXGW とサイトすべてから同時に学習する場合、DC2 を通る直接パスを優先するメカニズムがありません。その結果、DC2 宛てのトラフィックが代わりに DC1 や DC3 を経由して出ていくことがあり、不要なバックボーンの通過、レイテンシーの増加、コストの増加を招きます。 補足：このシナリオでは、オンプレミスのデータセンターが MPLS や AWS Direct Connect SiteLink などのバックボーンネットワークを通じて相互接続されており、フェイルオーバー時にサイト間でトラフィックを通過させられることを前提としています。 図3：ルーティングポリシーがない場合のルートパス選択 AWS Cloud WAN のルーティングポリシーは、ローカルプリファレンスなどの BGP 属性を使用して、パス選択を集中的に制御します。図4に示すように、各 DXGW アタッチメントに適用されたインバウンドルーティングポリシーがローカルプリファレンス値を割り当て、トラフィックを発信元のデータセンターへ誘導することで、最も直接的なパスが優先されるようにします。 図4：ルーティングポリシー適用後のルートパス選択 このシナリオでは、各データセンターが特定のプレフィックスのセットを保有しています。DC1 は 10.1.0.0/16 を、DC2 は 10.2.0.0/16 を、DC3 は 10.3.0.0/16 を発信します。耐障害性のため、3つの DC はいずれも、自身の Direct Connect ロケーションから3つすべてのプレフィックスをアドバタイズします。各 DC は専用の DXGW を通じて接続されており、DC1 は ASN 65010、DC2 は 65011、DC3 は 65012 を使用します。AWS Cloud WAN は3つの DXGW すべてから同じルートを学習し、ローカルプリファレンスを使用して各プレフィックスのトラフィックをその保有元 DC へ誘導します。他の DC は、セカンダリおよび第3（ターシャリ）のフェイルオーバーパスとして機能します。 AWS Cloud WAN の観点から見ると、このシナリオのパス優先度マトリックスは次のとおりです。 プレフィックス 1番目（ローカルプリファレンス 300） 2番目（LP 200） 3番目（LP 100） DC1: 10.1.0.0/16 DXGW 65010 DXGW 65011 DXGW 65012 DC2: 10.2.0.0/16 DXGW 65011 DXGW 65012 DXGW 65010 DC3: 10.3.0.0/16 DXGW 65012 DXGW 65011 DXGW 65010 仕組み 3つの DC はいずれも耐障害性のために3つすべてのプレフィックスをアドバタイズしますが、各プレフィックスは特定の DC に属します。AWS Cloud WAN が 10.1.0.0/16 を3つの DXGW すべてから学習すると、ルーティングポリシーは、DXGW 65010（保有元である DC1）から 300、DXGW 65011（DC2）から 200、DXGW 65012（DC3）から 100 のローカルプリファレンスを割り当てます。AWS Cloud WAN は最も高いローカルプリファレンスを持つパスを選択し、10.1.0.0/16 のトラフィックを DC1 経由で誘導します。DC1 の Direct Connect パスに障害が発生した場合、トラフィックは自動的に DC2（ローカルプリファレンス 200）、次いで DC3（ローカルプリファレンス 100）へフォールバックします。同じロジックが、DC2 保有のプレフィックス（プライマリは DXGW 65011、セカンダリは 65012、第3経路は 65010 経由）および DC3 保有のプレフィックス（プライマリは DXGW 65012、セカンダリは 65011、第3経路は 65010 経由）にも適用されます。 DXGW のレベルでは、VIF 上の BGP コミュニティ を通じて、追加のパス制御レイヤーが利用できます。各 DXGW にはプライマリとセカンダリの2つの VIF があり、コミュニティタグによってアウトバウンドトラフィックにどちらの VIF が優先されるかが決まります。高優先度には 7224:7300、低優先度には 7224:7100 を使用します。あるいは、アクティブ・アクティブの ECMP ロードバランシングのために、両方の VIF に 7224:7200 を適用することもできます。 この設定により、AWS Cloud WAN と DXGW は、インバウンドのルート優先設定を使用してアウトバウンドトラフィックをオンプレミスへ誘導します。対称ルーティングを実現するには、オンプレミスから AWS へ流れるトラフィックについても、オンプレミスのデバイスが同じパスを優先するように設定する必要があります。 補足：定義された3つのプレフィックスリストのいずれにもマッチしないプレフィックスは、明示的なローカルプリファレンスが設定されないまま通過し、3つの DXGW すべてにわたって非決定的なパス選択となります。オンプレミスから新しいプレフィックスがアドバタイズされるのに合わせて、プレフィックスリストを最新の状態に保つようにしてください。 ステップ1：各データセンター用のプレフィックスリストを定義する データセンターごとに個別のプレフィックスリストを作成し、そのサイトから発信される CIDR をグループ化します。プレフィックスリストは Amazon VPC マネージドプレフィックスリスト（カスタマーマネージドプレフィックスリスト）として作成され、その後プレフィックスリストエイリアスを使用してコアネットワークに関連付けられます。ルーティングポリシーがプレフィックスをマッチする際に参照するのは、このエイリアスです。例えば、10.1.0.0/16、10.2.0.0/16、10.3.0.0/16 をそれぞれ含む3つの マネージドプレフィックスリスト を作成し、エイリアス dc1Prefixes、dc2Prefixes、dc3Prefixes を使用してコアネットワークに関連付けます。 補足：–max-entries パラメータは必須で、プレフィックスリストが保持できるエントリの最大数を定義します。ここで使用している値 5 は任意のものであり、含める予定のプレフィックス数に応じて調整できます。 aws ec2 create-managed-prefix-list --prefix-list-name dc1Prefixes --max-entries 5 --address-family IPv4 --entries Cidr=10.1.0.0/16 aws ec2 create-managed-prefix-list --prefix-list-name dc2Prefixes --max-entries 5 --address-family IPv4 --entries Cidr=10.2.0.0/16 aws ec2 create-managed-prefix-list --prefix-list-name dc3Prefixes --max-entries 5 --address-family IPv4 --entries Cidr=10.3.0.0/16 aws networkmanager create-core-network-prefix-list-association --core-network-id <core-network-id> --prefix-list-arn <dc1-prefix-list-arn> --prefix-list-alias dc1Prefixes aws networkmanager create-core-network-prefix-list-association --core-network-id <core-network-id> --prefix-list-arn <dc2-prefix-list-arn> --prefix-list-alias dc2Prefixes aws networkmanager create-core-network-prefix-list-association --core-network-id <core-network-id> --prefix-list-arn <dc3-prefix-list-arn> --prefix-list-alias dc3Prefixes ステップ2：DXGW アタッチメントごとにルーティングポリシーを定義する 各 DXGW は、それぞれ独自のインバウンドルーティングポリシーを持ちます。このポリシーは、パス優先度マトリックスに基づいて各プレフィックスにローカルプリファレンス値を割り当て、各プレフィックスを発信元 DC へ、決定的なフェイルオーバー順序で誘導します。 DXGW 65010（DC1）のポリシー。DC1 のプライマリ、DC2 と DC3 の第3経路： { "routing-policies": [ { "routing-policy-number": 100, "routing-policy-name": "pathPreferenceDxgw65010", "routing-policy-description": "DXGW 65010 (DC1): primary for DC1, tertiary for DC2, tertiary for DC3", "routing-policy-direction": "inbound", "routing-policy-rules": [ {"rule-number": 10, "rule-definition": {"match-conditions": [{"type": "prefix-in-prefix-list", "value": "dc1Prefixes"}], "condition-logic": "and", "action": {"type": "set-local-preference", "value": "300"}}}, {"rule-number": 20, "rule-definition": {"match-conditions": [{"type": "prefix-in-prefix-list", "value": "dc2Prefixes"}], "condition-logic": "and", "action": {"type": "set-local-preference", "value": "100"}}}, {"rule-number": 30, "rule-definition": {"match-conditions": [{"type": "prefix-in-prefix-list", "value": "dc3Prefixes"}], "condition-logic": "and", "action": {"type": "set-local-preference", "value": "100"}}} ] } ] } DXGW 65011（DC2）のポリシー。DC2 のプライマリ、DC1 と DC3 のセカンダリ： { "routing-policies": [ { "routing-policy-number": 200, "routing-policy-name": "pathPreferenceDxgw65011", "routing-policy-description": "DXGW 65011 (DC2): secondary for DC1, primary for DC2, secondary for DC3", "routing-policy-direction": "inbound", "routing-policy-rules": [ {"rule-number": 10, "rule-definition": {"match-conditions": [{"type": "prefix-in-prefix-list", "value": "dc1Prefixes"}], "condition-logic": "and", "action": {"type": "set-local-preference", "value": "200"}}}, {"rule-number": 20, "rule-definition": {"match-conditions": [{"type": "prefix-in-prefix-list", "value": "dc2Prefixes"}], "condition-logic": "and", "action": {"type": "set-local-preference", "value": "300"}}}, {"rule-number": 30, "rule-definition": {"match-conditions": [{"type": "prefix-in-prefix-list", "value": "dc3Prefixes"}], "condition-logic": "and", "action": {"type": "set-local-preference", "value": "200"}}} ] } ] } DXGW 65012（DC3）のポリシー。DC3 のプライマリ、DC2 のセカンダリ、DC1 の第3経路： { "routing-policies": [ { "routing-policy-number": 300, "routing-policy-name": "pathPreferenceDxgw65012", "routing-policy-description": "DXGW 65012 (DC3): tertiary for DC1, secondary for DC2, primary for DC3", "routing-policy-direction": "inbound", "routing-policy-rules": [ {"rule-number": 10, "rule-definition": {"match-conditions": [{"type": "prefix-in-prefix-list", "value": "dc1Prefixes"}], "condition-logic": "and", "action": {"type": "set-local-preference", "value": "100"}}}, {"rule-number": 20, "rule-definition": {"match-conditions": [{"type": "prefix-in-prefix-list", "value": "dc2Prefixes"}], "condition-logic": "and", "action": {"type": "set-local-preference", "value": "200"}}}, {"rule-number": 30, "rule-definition": {"match-conditions": [{"type": "prefix-in-prefix-list", "value": "dc3Prefixes"}], "condition-logic": "and", "action": {"type": "set-local-preference", "value": "300"}}} ] } ] } ステップ3：ポリシーを DXGW アタッチメントに関連付ける 各ルーティングポリシーを routing-policy-label にマッピングし、次にラベルによってアタッチメントをマッチし、対応するルーティングポリシーを関連付ける attachment-routing-policy-rules を定義します。routing-policy-label を各アタッチメントに割り当てます。 { "attachment-routing-policy-rules": [ {"rule-number": 100, "conditions": [{"type": "routing-policy-label", "value": "dxgw65010inbound"}], "action": {"associate-routing-policies": ["pathPreferenceDxgw65010"]}}, {"rule-number": 200, "conditions": [{"type": "routing-policy-label", "value": "dxgw65011inbound"}], "action": {"associate-routing-policies": ["pathPreferenceDxgw65011"]}}, {"rule-number": 300, "conditions": [{"type": "routing-policy-label", "value": "dxgw65012inbound"}], "action": {"associate-routing-policies": ["pathPreferenceDxgw65012"]}} ] } 次に、routing-policy-label パラメータまたはコンソールを使用して、対応する routing-policy-label を各 DXGW アタッチメントに適用します。このシナリオでは、ラベル dxgw65010inbound を DXGW 65010 アタッチメントに、dxgw65011inbound を DXGW 65011 アタッチメントに、dxgw65012inbound を DXGW 65012 アタッチメントに割り当てます。 シナリオ3：同一 ASN を持つネットワーク間の通信の許可 Wide Area Network（WAN）を構築する企業は、グローバル接続のために AWS のバックボーンインフラストラクチャをますます活用していますが、買収、有機的な成長、または一般的なデフォルト ASN 値を使用したマルチサイト展開などにより、プライベート ASN の重複に直面することがよくあります。複数のサイトが同一の ASN を使用している場合、BGP のループ防止機能が、AS-path にそのサイト自身の ASN を含むルートを拒否し、WAN 全体のエンドツーエンドの通信を妨げます。 このシナリオでは、2つの ASN の競合がエンドツーエンドの通信を妨げています。図5に示すように、DC1 と DC2（A）はどちらも ASN 65000 を使用しています。AWS Cloud WAN がそれらの間でルートを伝播すると、各サイトは AS-path に自身の ASN を検出するため、相手のルートを拒否します。これが BGP のループ防止機能を引き起こします。 図5：DC1 と DC2 間で BGP ループ防止機能を引き起こす ASN の競合 2つ目の競合（B）は、図6に示すように、ASN 64512 を使用する DC3 が、ap-southeast-2 の AWS Cloud WAN コアネットワークエッジ（CNE）の ASN と競合するというものです。これにより、DC3 のルートは ap-southeast-2 の CNE によってドロップされ、DC3 もその CNE からのルートをドロップします。 図6：DC3 と AWS Cloud WAN CNE 間の ASN の競合によるルート伝播のブロック これら2つの競合が組み合わさることで、3つのデータセンターすべてにわたって到達性が完全に失われる結果となります。 AWS Cloud WAN のルーティングポリシーは、replace-asn-list アクションによってこの問題に対処します。このアクションは、AS-path 全体を指定した ASN のセットで置き換え、ループ防止機能を引き起こす競合を取り除き、オンプレミスの BGP の番号を振り直すことなく接続を復元します。 図7に示すように、3つのデータセンターは AWS Cloud WAN を中央のグローバルバックボーンとして使用します。DC1 は ap-southeast-2 リージョンの Direct Connect を通じて接続し、DC2 は us-west-2 リージョンの Site-to-Site VPN を通じて接続し、DC3 はメトロファイバー経由で DC2 を通じて AWS Cloud WAN に到達します。インバウンドルーティングポリシーは、2つのアタッチメントポイントに適用されます。(1) DC1 用の Direct Connect ゲートウェイアタッチメント、および (2) DC2 用の VPN アタッチメントです。DC3 のルートは DC2 の VPN アタッチメントを経由して通過するため、そのアタッチメントのインバウンドポリシーが DC2 と DC3 の両方の ASN 置換を処理します。 図7：3つのデータセンターすべての接続を復元する ASN 置換ルーティングポリシー 次の表は、ASN の置換をまとめたものです。 ソース 元の ASN 置換後の ASN 理由 DC1（Direct Connect） 65000 65550 DC2 でのループ検出を回避 DC2（Site-to-Site VPN） 65000 65551 DC1 でのループ検出を回避 DC3（DC2 のメトロファイバー経由） 64512 65552 ap-southeast-2 の CNE ASN との競合を回避 重要：AWS Cloud WAN のコアネットワークエッジ（CNE）は、インバウンドルーティングポリシーが評価される前に、BGP AS-path のループ検出を実行します。CNE が自身の ASN と一致する ASN を持つルートを受信した場合、replace-asn-list アクションが実行される前にそのルートをドロップします。トポロジーを計画する際は、オンプレミスのルートが、受信側の CNE の ASN と一致する ASN を持たないようにしてください。 仕組み このアプローチは、各サイトに固有で競合しない置換 ASN を割り当てることで、どのサイトも伝播されたルートの中に自身の ASN を見ることがなく、また、どのルートもトポロジー内の CNE と競合する ASN を持たないようにするものです。DC1 が AWS Cloud WAN にルートをアドバタイズすると、Direct Connect ゲートウェイアタッチメントのインバウンドポリシーが、AS-path 全体を ASN 65550 で置き換えます。これらのルートは AWS Cloud WAN を通じて伝播し、AS-path に 65000 ではなく 65550 を含んだ状態で DC2 に到達するため、DC2 のルーターはループ検出を引き起こすことなくそれらを受け入れます。 DC2 がルートをアドバタイズすると、VPN アタッチメントのインバウンドポリシーが AS-path 全体を ASN 65551 で置き換えます。これにより DC1 は、AS-path に 65000 ではなく 65551 を含んだ状態でこれらのルートを受信するため、BGP のループ検出を防ぎ、DC1 と DC2 間の双方向通信を復元します。 DC3 については、ルートは ASN 64512（DC3）と ASN 65000（DC2）の両方を持った状態で、DC2 の VPN アタッチメントを通じて AWS Cloud WAN に入ります。インバウンドポリシーは AS-path 全体を単一の専用 ASN（65552）で置き換え、競合する2つの値を1回の操作で取り除きます。これにより、DC3 のプレフィックスが AWS Cloud WAN のルートテーブルに受け入れられ、DC1 およびクラウドリソースにアドバタイズされるようになります。 すべての置換 ASN（65550、65551、65552）は、コアネットワークエッジ用に設定された ASN 範囲の外から選択されています。ルーティングポリシーの置換値は、AWS Cloud WAN の CNE の ASN 範囲と重複できないためです。 ステップ1：DC1 の Direct Connect ゲートウェイアタッチメントにインバウンドポリシーを定義する このポリシーは、DC1 から到着する AS-path に ASN 65000 を含むルートにマッチし、それを 65550 に置き換えます。これらのルートが DC2 に伝播されるとき、AS-path には 65000 が含まれなくなるため、DC2 のルーターはそれらを受け入れます。 { "routing-policies": [ { "routing-policy-name": "replaceasndc1", "routing-policy-description": "Replace ASN 65000 from DC1 with 65550 to avoid loop detection at DC2", "routing-policy-direction": "inbound", "routing-policy-number": 100, "routing-policy-rules": [ {"rule-number": 10, "rule-definition": {"match-conditions": [{"type": "asn-in-as-path", "value": 65000}], "condition-logic": "and", "action": {"type": "replace-asn-list", "value": [65550]}}} ] } ] } ステップ2：DC2 の VPN アタッチメントにインバウンドポリシーを定義する このポリシーは、2つのルーティングルールを使用して ASN の競合を解決します。 ルール10 ：DC3 の ASN（64512）を 65552 に置き換えます。 ルール20 ：DC2 の ASN（65000）を 65551 に置き換えます。 DC3 からのルートは DC2 を経由して通過するため、AS-path に両方の ASN を含みます。そのため、順序が重要です。replace-asn-list は AS-path 全体を上書きするため、DC3 のルートが専用の置換 ASN（65552）を受け取れるように、ルール10 を先に実行する必要があります。 もしルール20 が先に実行されると、DC2 の ASN にマッチして AS-path 全体を 65551 で置き換えてしまいます。DC3 のルートは依然として受け入れられ、接続は機能しますが、DC2 のルートと区別がつかなくなり、ルートの追跡やトラブルシューティングが難しくなります。 { "routing-policies": [ { "routing-policy-name": "replaceasndc2", "routing-policy-description": "Replace ASN 65000 from DC2 with 65551 and ASN 64512 from DC3 with 65552", "routing-policy-direction": "inbound", "routing-policy-number": 200, "routing-policy-rules": [ {"rule-number": 10, "rule-definition": {"match-conditions": [{"type": "asn-in-as-path", "value": 64512}], "condition-logic": "and", "action": {"type": "replace-asn-list", "value": [65552]}}}, {"rule-number": 20, "rule-definition": {"match-conditions": [{"type": "asn-in-as-path", "value": 65000}], "condition-logic": "and", "action": {"type": "replace-asn-list", "value": [65551]}}} ] } ] } ステップ3：ポリシーをアタッチメントに関連付ける routing-policy-label にマッチする attachment-routing-policy-rules を定義することで、各ルーティングポリシーをアタッチメントに関連付けます。routing-policy-label パラメータまたはコンソールを使用して、各アタッチメントに指定の routing-policy-label をタグ付けします。 { "attachment-routing-policy-rules": [ {"rule-number": 100, "conditions": [{"type": "routing-policy-label", "value": "dc1inbound"}], "action": {"associate-routing-policies": ["replaceasndc1"]}}, {"rule-number": 200, "conditions": [{"type": "routing-policy-label", "value": "dc2inbound"}], "action": {"associate-routing-policies": ["replaceasndc2"]}} ] } 最後に、routing-policy-label パラメータまたはコンソールを使用して、各アタッチメントに指定の routing-policy-label をタグ付けします。このシナリオでは、ラベル dc1inbound を DC1 の Direct Connect ゲートウェイアタッチメントに、dc2inbound を DC2 の VPN アタッチメントに割り当てます。 知っておくべきこと AWS Cloud WAN への Direct Connect ゲートウェイアタッチメントを作成する際、DXGW が接続する CNE を選択できます。各 CNE は自身のローカルリージョンの VPC ルートのみを DXGW にアドバタイズするため、関連付けを制限する特別な理由がない限り、シナリオ2に示すようにすべての CNE を選択することを推奨します。 IPv6 がサポートされています。同じマッチ条件、アクション、ポリシー構造が IPv6 プレフィックスにも適用されます（ワイルドカードマッチとして ::/0 を使用）。本記事で説明したすべてのシナリオにおいて、IPv6 のルート伝播に同一のルーティングポリシーパターンを適用できます。 シナリオ2に示すように複数の Direct Connect ゲートウェイをデプロイすると、単一の Direct Connect ゲートウェイ（DXGW）を使用する場合よりも、きめ細かなルーティング制御が可能になります。AWS Cloud WAN のルーティングポリシーは、VIF や DXGW のレベルで利用できるものよりも幅広い BGP 属性の制御を提供します。オンプレミス接続を複数の DXGW に分散させることで、ルーティングの決定を AWS Cloud WAN に移し、トラフィックエンジニアリングのためのより豊富なポリシー制御を利用できるようになります。 ルーティングポリシー内のルールは、rule-number の順に評価されます。評価を停止する終端アクションは drop と allow のみです。replace-asn-list、set-local-preference、add-community などのその他のアクションは非終端であり、評価は残りのルールへと続き、各変更が引き継がれていきます。replace-asn-list アクションは、個々の ASN を置換するのではなく、AS-path 全体を上書きします。その結果、先のルールによって変更されたルートは、後のルールがマッチするための元の ASN をもはや持ちません。シナリオ3の DC2 を経由する DC3 のルートのように、ルートが複数の ASN を持ちうる場合は、最も具体的なマッチが最初に適用されるようにルールを順序付けてください。 AWS Cloud WAN は、CNE ごとに BGP AS-path のループ検出を実行し、このチェックはインバウンドルーティングポリシーが適用される前に実行されます。受信ルートの AS-path に、そのアタッチメントが接続する CNE の ASN が含まれている場合、replace-asn-list ポリシーが変更を加える前にそのルートは拒否されます（詳細な例についてはシナリオ3を参照してください）。 クリーンアップ 本記事で説明したルーティングポリシーは、AWS Cloud WAN のコアネットワークポリシードキュメント内で定義されるものであり、単独で課金対象となるリソースを作成することはありません。これらの設定を削除するには、次の手順を実行します。 AWS Cloud WAN コンソールでアタッチメントを編集するか、AWS CLI を使用して、各アタッチメントから routing-policy-label を削除します。 ポリシーを参照している attachment-routing-policy-rules と、すべての segment-actions を削除します。 コアネットワークポリシーの routing-policies セクションから、ルーティングポリシーの定義（tagTgwRoutes、filterRoutesToHybrid、pathPreferenceDxgw*、replaceasn*）を削除します。 変更を適用するために、コアネットワークポリシーのバージョン更新を送信します。 シナリオ2でマネージドプレフィックスリストを作成し、それらが不要になった場合は、AWS CLI または AWS マネジメントコンソールを使用して削除します。 まとめ 本記事では、AWS Cloud WAN のルーティングポリシーが、ハイブリッド環境やマルチサイト環境における一般的なルーティングの課題をどのように解決できるかを示す、3つの実運用シナリオを取り上げました。コミュニティのタグ付けとフィルタリングを使用して Transit Gateway 環境からのルート伝播を制御する方法、ローカルプリファレンスを使用して複数の DXGW と Direct Connect ロケーション間のパス選択を改善する方法、そして AS-path の置換を使用して BGP の ASN の競合を解決する方法を紹介しました。ルーティングポリシー設定の基礎を扱った Part 1 と合わせて、これらのシナリオは、AWS Cloud WAN をグローバルネットワークの統合的なルーティング制御レイヤーとしてどのように使用できるかを示しています。始めるには、 AWS Cloud WAN のドキュメント を参照してください。 著者について Jordan Rojas Garcia Jordan は、AWS の Worldwide Specialist Organization に所属するシニアネットワークスペシャリストソリューションアーキテクトです。従来型のデータセンターネットワークの分野でキャリアをスタートし、2018年に AWS に入社しました。AWS では、クラウドネットワーキングソリューションの設計に注力し、AWS クラウドでネットワークを構築するためのガイダンスとベストプラクティスを提供しています。仕事以外では、旅行、新しい料理の開拓、ハイキングを楽しみ、二輪車と四輪車の運転への情熱を燃やしています。 Akeef Khan Akeef Khan は、オーストラリアのシドニーを拠点とする Amazon Web Services のソリューションアーキテクトです。Cross-Industries セグメントのお客様を担当し、小売業や QSR（クイックサービスレストラン）の組織が AWS を採用、運用、スケールできるよう支援しています。彼の専門分野はネットワーキングであり、AWS のサービスを使ってお客様のグローバルなネットワーク接続をシンプルにすることに情熱を注いでいます。仕事以外では、新しいテクノロジーの探求と継続的な学習を楽しんでいます。 翻訳は Solutions Architect の田村 大地が担当しました。原文は こちら です。

本記事は 2026 年 7 月 2 日に公開された Ranjith Ramakrishnan による “ Set a cap on overage spend, or pre-pay for it ” を翻訳したものです。 現在 Kiro で超過利用 (overage) をしている場合、いくら使ったかがわかるのは、すでに使い切ってしまった後です。ヘビーな利用の結果は翌月の請求書に金額として現れ、その時点ではもう支払うしかありません。チームで Kiro をご利用のお客様からは、自分たちでコントロールできる上限が欲しいという声を聞いてきました。個人開発者からは、予測できない請求書を受け取るくらいなら前払いしたいという声を聞いてきました。 チーム向け: Service Quotas コンソールから超過利用に上限を設定する 2026 年 7 月 2 日より、チームが AWS IAM Identity Center または外部 ID プロバイダーで Kiro にサインインしている場合、AWS Service Quotas コンソールで超過利用の上限設定が利用可能になりました。Service Quotas コンソールを開き、サービス一覧から Kiro を選択し、アカウントレベルで上限の引き上げをリクエストします。上限が設定されると、そのアカウントでサブスクライブしているすべてのユーザーに適用されます。 上限の最大値は、アカウントの利用履歴や状態に応じて自動的に調整されます。自動で設定される上限よりも高くしたい場合は、同じコンソールから追加の引き上げをリクエストしてください。 この仕組みにより、AWS 管理者がすでにクォータを管理している場所に上限が置かれるため、別途確認する場所も、新しく覚えるべき権限モデルもありません。 個人開発者向け: クレジットパックによる前払い GitHub、Google、または AWS Builder ID でサインインし、有料プラン (Kiro Pro、Pro+、Pro Max、または Power) を利用している場合、 アドオンクレジットを購入 して、プランの上限を超えて Kiro を使い続けられるようになりました。 アカウントページ にアクセスし、クレジットパック (最小 5 ドルから) を購入すれば、あとは通常どおり Kiro を使うだけで残高が自動的に消費されます。 後から請求される超過利用を積み上げるのではなく、いつでも確認できる残高に対して使っていく形になります。残高が少なくなってきたら、チャージするか、通常のサブスクリプションのクレジット上限がリセットされるまで待つかを、自分で決められます。クレジットはすでに支払い済みなので、請求書で驚かされることもありません。 支出をよりコントロールしやすく これらの機能が最も役立つのは、支出の予測が難しいことが実際にリスクとなるケースです。たとえば、どのメンバーでも利用量を押し上げられる共有のチームアカウントや、ヘビーな利用が続いた 1 か月分がそのまま想定外の請求として計上されてしまう個人の作業などです。利用量がプランの範囲内に十分収まっているなら、どちらの機能も使わないかもしれません。すでに両アップデートを ご利用いただけます 。 翻訳は Solutions Architect の吉村 が担当いたしました。

数回前の号で、スタートアップと仕事をすることがどれほど活力になるかについて書きました。2026 年 6 月 29 日週、それを改めて感じました。AWS スタートアップチームと数日過ごし、創業者たちが実際に解決しようとしている問題について語る話に耳を傾けたのです。私の心に残った話の 1 つは、眼科医療へのアクセスを拡大しているブラジルのヘルステック企業 EyeCare Health の創業者である Marco Negreiros 氏から聞いたものです。彼は驚くべき事実を明かしました。ブラジルの自治体の 70％ 以上には眼科医が一人もいないというのです。彼の対応策は、ほぼすべての人が既に持ち歩いているデバイス、つまりスマートフォンで視力検査機能を搭載することでした。これにより、基本的な視力検査を受けるために診療所の近くに住む必要がなくなりました。創業者があれほど大きなギャップを、これほど具体的な解決策に変えていく姿を見ることができるからこそ、私はこの分野が大好きなのです。 今週は、いくつかの主要なリリースについて詳しく見たあと、四半期ごとの AWS サービスの可用性アップデートを取り上げます。 2026 年 6 月 29 日週のリリース 6 月 29 日週の AWS ニュースブログで取り上げられた発表の一部を以下にご紹介します。 AWS Graviton5 プロセッサを搭載した Amazon EC2 C9g および C9gd インスタンス : これらは、Graviton4 ベースのインスタンスよりも最大 25% 優れたコンピューティングパフォーマンス、5 倍大きいキャッシュ容量、クラウド内のプロセッサインスタンスの中で最速のメモリ、ローカル NVMe ストレージオプション (C9gd) を実現します。 新しい AWS CloudFormation Express モード : AWS CloudFormation Express モードを使用すると、インフラストラクチャのデプロイを高速化できます。これにより、AI エージェントとデベロッパーは数秒でデプロイの確認を受け取り、より迅速に反復できます。すべての AWS 商用リージョンで追加費用なしでご利用いただけます。 Kubernetes バージョンロールバックを活用し、Amazon EKS クラスターを安心してアップグレード : Amazon EKS の Kubernetes バージョンロールバックにより、クラスターのアップグレードを 7 日以内にロールバックできます。この新機能は、アップグレードが失敗した場合のセーフティネットを提供し、クラスターの再構築を不要にします。これにより、Kubernetes のバージョンアップグレードがロールバック可能な、低リスクのオペレーションになります。 AWS Certificate Manager の ACME サポートによるパブリック TLS 証明書発行の自動化 : AWS Certificate Manager が ACME プロトコルをサポートするようになりました。これにより、広く採用されている標準ツールを使用して、パブリック TLS 証明書の発行と更新を自動化できます。 私が注目したいくつかのリリースや最新情報をいくつかご紹介します: Claude Sonnet 5 が AWS で利用可能 – Anthropicの最も高性能な Sonnet モデルは、コーディング、エージェント、そして日常のプロフェッショナルワークを大規模に処理するための一流のインテリジェンスを、Sonnet の価格で提供します。大規模なコードベースを効率的に探索し、ツールを正確に呼び出し、長時間におよぶエージェントタスクでも状態を保持します。詳細については、 AI ブログの記事 をご覧ください。 AI エージェント向け Amazon WorkSpaces が一般公開 : AI エージェントは、アプリケーションのモダナイズやカスタム統合を必要とせずに、マネージド WorkSpaces 環境を通じてデスクトップアプリケーションに安全にアクセスして操作できるようになりました。詳細については、 デスクトップとアプリケーションストリーミングのブログ記事 をご覧ください。 Amazon OpenSearch Service がログ分析用に最適化 : このリリースでは、ログ分析ワークロード専用に設計された新しいエンジンが導入されました。このエンジンは、OpenSearch が誇る全文検索機能を維持しながら、内部ベンチマークで最大 4 倍のコストパフォーマンスを実現します。チームは、集計と高精度なテキスト検索を 1 か所で行えるようになりました。詳細については、 ビッグデータブログの記事 をご覧ください。 Amazon SageMaker AI は、生成 AI 推論のスケールアウト時間を最大半分に短縮 : SageMaker Inference がコンテナイメージのキャッシュをサポートし、スケールアウトイベント中の生成 AI モデルのエンドツーエンドスケーリングが最大 2 倍高速になります。詳細については、 AI ブログの記事 をご覧ください。 Amazon CloudWatch はログクエリからのアラーム作成をサポート : ログクエリの結果に対して直接アラームを作成し、単一のワークフローでしきい値を設定できるようになり、中間ステップとしてメトリックスフィルターやカスタムメトリクスを事前に作成する必要がなくなりました。 AWS のお知らせに関する詳しいリストについては、「 AWS の最新情報 」ページをご覧ください。 AWS サービス可用性アップデート AWS のサービスまたは機能の可用性が変化した場合、私たちは運用の中断を最小限に抑えるために、利用可能な代替案について AWS 製品ライフサイクル の変更に関するガイダンスをお客様に提供し、移行をサポートします。次のライフサイクル変更は、2026 年 6 月 30 日に更新されました。 メンテナンスフェーズへの移行 (2026 年 7 月 30 日以降、新規のお客様は利用できなくなります): Amazon Bedrock Agents (2023 年 11 月リリース) は Amazon Bedrock Agents Classic になりました Amazon Cognito Sync Amazon Kendra Amazon Q Business AWS Directory Service — Simple AD AWS IoT Device Defender — 検出 (2026 年 8 月 31 日以降、新規のお客様は機能にアクセスできなくなります) AWS Mainframe Modernization — セルフマネージドエクスペリエンス AWS マネジメントコンソール — myApplications AWS リソースグループ — グループライフサイクルイベント AWS Service Catalog — アプリケーションレジストリ AWS Systems Manager — アプリケーションマネージャー Amazon SageMaker AI の機能: A2I 、 Clarify 、 Debugger 、 GeoSpatial 、 Ground Truth 、 Mechanical Turk 、 Model Monitor 、Role Manager、Studio Lab サンセットフェーズに入るサービス: Amazon WorkSpaces – PCoIP Amazon WorkSpaces – Pool AWS Managed Services (AMS) Advanced AWS re:Post Private Amazon SageMaker AI – Profiler サポート終了間近のサービス (2026 年 6 月 30 日現在): Amazon Chime SDK — キャリアボイスフォーカス Amazon SageMaker AI – Ground Truth Plus 私たちは、可用性の変化がお客様の業務に影響を与える可能性があることを理解しています。具体的なガイダンスについては、関連するサービスドキュメントを参照するか、AWS サポートにお問い合わせください。 近日開催予定の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう: AWS Summit — AWS Summit は、クラウドや AI のコミュニティが一堂に会し、最新のテクノロジーを学び、探求するための無料のイベントです。カレンダー全体をご覧になって、2026 年後半にお近くで開催されるサミットを見つけてください。 AWS Community Days – コミュニティリーダーたちがコンテンツを計画、調達、提供するコミュニティ主導のカンファレンス。ラテンアメリカにお住まいの場合は、8 月 22 日に開催される AWS Community Day Belo Horizonte をお見逃しなく。登録は awscommunityday.com.br で受け付けています。 AWS Builder Center に参加して、ビルダーとつながり、ソリューションを共有し、開発をサポートするコンテンツにアクセスしましょう。 こちら から、今後開催されるすべての AWS 主導の対面イベントおよび仮想イベントとデベロッパー向けのイベントをご覧いただけます。 2026 年 7 月 6 日週のニュースは以上です。7 月 13 日週に再びアクセスして、新たな Weekly Roundup をぜひお読みください! – Daniel Abib この記事は、Weekly Roundup シリーズの一部です。AWS からの興味深いニュースや発表を簡単にまとめて毎週ご紹介します! 原文は こちら です。

本ブログは 2026 年 7 月 7 日に公開された AWS Blog “ Enforce zero data retention on Amazon Bedrock with Bedrock Projects and service control policies ” を翻訳したものです。 Claude Fable 5 のように、サードパーティープロバイダーとのデータ共有を必要とするモデルの登場により、組織には データ保持 ポリシーを一元的に適用する方法が求められています。 Amazon Bedrock では、推論リクエストの完了後にプロンプトとモデル出力を保持するかどうかを制御できます。すべてのアカウントに保持設定を適用しつつ、選択したモデルが対応している場合にはプロジェクト単位でデータ保持をきめ細かく制御したい、というケースもあるでしょう。 本記事では、Amazon Bedrock のデータ保持モードの仕組み、保持を管理するために利用できるツール ( Amazon Bedrock Projects や サービスコントロールポリシー (SCP) など)、およびポリシー設定が正しく機能していることを検証する方法を説明します。 本記事では、以下の内容を取り上げます。 Amazon Bedrock のデータ保持モードの仕組みと、各モードがデータに対して何を意味するか 互換性のあるモデルで Amazon Bedrock Projects を使用して、保持要件が異なるワークロードを分離する方法 組織内の誰もデータ共有を有効にできないようにする SCP の作成とデプロイの方法 データ保持モードとクロスリージョン推論プロファイルの相互作用 設定が正しく機能していることを検証する方法 データ保持モードを理解する Amazon Bedrock では、アカウントのモード設定を通じてデータ保持を制御できます。この設定は、各推論リクエストの後にプロンプトと出力がどのように扱われるかを決定するものであり、コンプライアンス要件を評価するうえで理解しておくことが重要です。すべてのモデルがデータ保持やデータ共有を必要とするわけではなく、これらを必要としないモデルで Amazon Bedrock を引き続き利用することもできます。データ保持またはデータ共有を必要とするモデルの最新リストについては、「 Amazon Bedrock ドキュメント 」を参照してください。最終的には、コンプライアンス要件に合致するモデルを選択することはお客様の責任となります。 重要な注意事項 : 児童性的虐待コンテンツ (CSAM) の拡散を防止するため、Amazon Bedrock は自動化されたメカニズムを使用して、モデルの入力/出力に含まれる CSAM を特定します。モードが none の場合でも、フラグが付けられたコンテンツを保存および確認し、報告目的で CSAM に該当するかどうかを判断することがあります。 以下のモードによって、Amazon Bedrock がデータをどのように扱うかが決まります。 モード 動作 プロバイダーとのデータ共有 none ゼロデータ保持。プロンプトとレスポンスは処理後、直ちに破棄されます。 なし default モデルプロバイダーとデータは共有されません。一部のモデルでは、信頼と安全性のチェックのために最大 30 日間のデータ保持が必要になる場合があります。詳細は各モデルの利用条件を確認してください。このモードでは、本質的に保持を必要とする API (例: Batch API、store=true を指定した Responses API) も使用できます。ゼロデータ保持をサポートするモデルは、引き続きゼロデータ保持で動作します。 なし inherit 明示的な設定は適用されず、1 つ上のスコープに従います (プロジェクトはアカウントに、アカウントはサービスのデフォルトに従います)。新しいアカウントのデフォルトはこのモードです。 なし provider_data_share データは信頼と安全性のために最大 30 日間保持され、モデルプロバイダーと共有される場合があります。 あり モードは下限ではなく上限であることを理解する 最も重要な概念は、 設定したモードは許容できる保持の上限であり 、すべてのリクエストがそのモードで動作するわけではないという点です。アカウントを provider_data_share に設定しても、すべてのリクエストが突然データの保持や共有を始めるわけではありません。ゼロデータ保持をサポートするモデルは、アカウントレベルの設定にかかわらず、引き続きゼロデータ保持で動作します。 アクセス許可の上限として考えてみましょう。 アカウントのモード 呼び出すモデル 動作 provider_data_share Claude Sonnet (none をサポート) ゼロデータ保持。Sonnet はデータ共有もデータ保持も必要としません。 provider_data_share Claude Fable 5 ( provider_data_share が必要) データは最大 30 日間保持され、プロバイダーと共有される場合があります。Fable 5 はデータ共有とデータ保持を必要とします。 none Claude Sonnet ( none をサポート) ゼロデータ保持、データ共有なし none Claude Fable 5 ( provider_data_share が必要) ブロックされます。上限がモデルの要件を下回っているため、このモデルの呼び出しは拒否されます。 default Claude Sonnet ( none をサポート) ゼロデータ保持。Sonnet はゼロデータ保持をサポートしており、データ保持もデータ共有もありません。 default 安全性チェックのために保持を必要とするモデル データは保持されます。モデルが保持を必要としており、上限がそれを許可しているためです。 重要なポイント: モード設定は、許容するデータ保持の最大レベルを宣言するものです。ゼロデータ保持をサポートするモデルは、アカウント設定にかかわらず、引き続きゼロデータ保持で動作します。Amazon Bedrock は、アカウントのモードが許可しているという理由だけで、必要以上のデータ保持が発生 しない ように設計されています。 重要: provider_data_share はモデルから継承されるものではなく、アカウントまたはプロジェクトレベルでの明示的なオプトインです。アカウントが inherit または default に設定されている場合、アカウントまたはプロジェクト内で設定しない限り、どのモデルを使用してもプロバイダーとのデータ共有が行われることはありません。 注: inherit の動作について: inherit モードは、階層の 1 つ上のスコープに従います (プロジェクトはアカウントに、アカウントはサービスのデフォルトに従います)。プロジェクトが inherit に設定され、その上のアカウントが provider_data_share に設定されている場合、プロジェクトは provider_data_share を継承します。 モデル から provider_data_share を継承することはなく、アカウントまたはプロジェクトレベルでの明示的な設定が必要です。 注: 保持を必要とする API について: 一部の Amazon Bedrock API は、モデルのサポート状況にかかわらず、動作にデータ保持を必要とします。例えば、 Batch API と store=true を指定した Responses API が該当します。モードを none に設定すると、これらの API はブロックされますが、これは想定どおりの動作です。上限が none であるということは保持を一切許容しないという意味であり、保持を必要とする API は利用できなくなります。 なぜ provider_data_share が存在するのか 一部の基盤モデルは、動作に provider_data_share モードを必要とします。AI モデルの進化に伴い、お客様と、お客様による安全な利用を保護するメカニズムも進化していく必要があります。 provider_data_share を必要とするモデルには allowed_modes: ["provider_data_share"] が設定されており、アカウントが明示的にオプトインしない限り、 利用不可 として表示されます。 これは意図的な設計です。 AWS では、お客様がこれらのモデルを使用する前に、データを共有するという意識的な決定を行うことを求めています。Amazon Bedrock で利用可能なモデルとその保持要件については、「 現在のモデルリスト 」を参照してください。この内容は新しいモデルのリリースに伴い変わる可能性があります。 規制要件、社内ポリシー、またはお客様への約束事項により、サードパーティーのモデルプロバイダーとのデータ共有が禁止されている場合は、複数のレベルでこれを強制できます。Amazon Bedrock は、きめ細かいプロジェクトレベルの設定から組織全体での強制まで、データ保持を管理するための複数のツールを提供しています。 データ保持を管理するためのツール Amazon Bedrock は、データ保持に対する複数レイヤーの制御手段を提供しています。これらは個別に使用することも、多層防御のために組み合わせることもできます。 ツール スコープ ユースケース Amazon Bedrock コンソール アカウントごと、AWS リージョンごと 迅速な設定と可視化。新しい Amazon Bedrock (mantle エンドポイント) コンソールで保持モードを直接表示および変更できます。 Amazon Bedrock Projects アカウント内のプロジェクトごと 互換性のあるモデル について、同一アカウント内で保持要件が異なるワークロードを分離 SCP 組織全体 どのアカウントもデータ共有にオプトインできないようにする IAM ポリシー アカウントごとまたはプリンシパルごと 管理アカウント (SCP の対象外) を含む、きめ細かい制御 Amazon Bedrock Projects によるきめ細かい制御 アカウント内のすべてのワークロードが同じデータ保持要件を持つとは限りません。 bedrock-mantle エンドポイント (OpenAI 互換 API など) を使用している場合、Amazon Bedrock Projects を使用することで、データ保持を許容できるトラフィックと保持してはならないトラフィックを、同じアカウント内であっても分離できます。 例えば、以下のような状況が考えられます。 チームが実験のために最新のモデル ( provider_data_share を必要とするモデルを含む) へのアクセスを必要とするリサーチプロジェクト ゼロデータ保持が必須である、顧客データを扱う本番プロジェクト Amazon Bedrock Projects を使用すると、リサーチプロジェクトには provider_data_share を設定しながら、本番プロジェクトは none にロックしたままにできます。各プロジェクトは、それぞれ独立して保持の上限を強制します。 プロジェクトレベルの保持の仕組み: 各プロジェクトは、それぞれ独自のデータ保持モードを設定できます inherit に設定されたプロジェクトは、アカウントレベルからモードを継承します none に設定されたプロジェクトは、アカウント設定にかかわらずゼロデータ保持を強制します。そのプロジェクトを経由するトラフィックでデータ共有が行われることはありません provider_data_share に設定されたプロジェクトは、データ共有を必要とするモデルを許可しますが、そのプロジェクト内のリクエストに限られます これにより、組織は機密性の高いワークロードに対して厳格なデータガバナンスを維持しながら、新しいモデルを段階的に導入する柔軟性を得られます。プロジェクト設定は、Amazon Bedrock コンソールまたは bedrock-mantle API を使用して管理できます。 重要: Amazon Bedrock Projects は bedrock-mantle エンドポイントでのみ利用可能です。mantle エンドポイント上の OpenAI 互換 API ( Responses 、 Chat Completions ) および Anthropic Messages API を使用してアクセスするモデルで動作します。すべてのモデルが bedrock-mantle で利用できるわけではありません。最新のサポート状況については、「 モデルごとのエンドポイントの可用性 」ページを確認してください。 bedrock-runtime エンドポイントでのワークロードの分離 bedrock-runtime エンドポイント ( Invoke 、 Converse API) を使用している場合、プロジェクトレベルのデータ保持は利用できません。 bedrock-runtime を通じて行われるすべてのリクエストには、アカウントレベルの保持モードが適用されます。 bedrock-runtime でワークロードレベルの分離を実現するには、別々の AWS アカウントを使用してください。 provider_data_share を必要とするワークロードは、SCP を適用しないアカウント (または OU) に配置します ゼロデータ保持を必要とするワークロードは、SCP を適用した別のアカウント (または OU) に配置します AWS Organizations の OU を使用して、保持ポリシーごとにアカウントをグループ化し、SCP を選択的に適用できます。 Organization Root ├── OU: Zero-Retention (SCP attached — blocks provider_data_share) │ ├── Account: Production-App-A │ └── Account: Production-App-B └── OU: Research (no SCP — allows provider_data_share) └── Account: ML-Experimentation プロジェクトと SCP の組み合わせ: SCP を使用して組織レベルで none を強制すると、 bedrock-mantle 上のすべてのプロジェクトレベル設定より優先されます。プロジェクトレベルの柔軟性が必要なアカウントには SCP を適用せず、代わりにプロジェクトレベルの分離を使用してください。いかなる状況でもデータ共有を許可してはならないアカウントに対しては、SCP を使用することで、両方のエンドポイントにおいて回避不可能な保証が得られます。 SCP による組織全体での強制 誰が管理者アクセス権を持っていても、どのエンドポイントを使用していても、どのアカウントもデータ共有を有効にできないという絶対的な保証が必要な組織にとって、SCP は最も強力な強制メカニズムです。SCP は、Amazon Bedrock コントロールプレーン ( bedrock:PutAccountDataRetention ) と mantle エンドポイント ( bedrock-mantle:PutAccountDataRetention 、 bedrock-mantle:CreateProject 、 bedrock-mantle:UpdateProject ) の両方に適用されます。 SCP によるゼロデータ保持の強制 このセクションでは、SCP を使用してデータ保持ポリシーを管理する方法を説明します。まず SCP とは何かを紹介し、続いて組織で使用できるポリシーの例をいくつか示します。 SCP とは サービスコントロールポリシー (SCP) は、組織レベルで設定されるガードレールです。アカウント管理者やルートユーザーを含む、組織内のすべてのプリンシパルより優先されます。たとえフル管理者権限を持っていても、SCP による拒否を AWS Identity and Access Management (IAM) ポリシーで上書きすることはできません。 SCP は AWS Organizations で管理され、以下のさまざまなレベルにアタッチできます。 ルート – 組織内のすべてのアカウントに適用されます 組織単位 (OU) – その OU 内のすべてのアカウントに適用されます 個別のアカウント – その特定のアカウントにのみ適用されます 重要: すべてのアカウントをカバーするには、SCP をルート OU にアタッチする必要があります。子 OU にアタッチした場合、その OU の外にあるアカウントは保護されません。また、組織の管理アカウントには SCP による制御は適用されません。 SCP ポリシー 以下のポリシーを使用すると、組織内の誰も Amazon Bedrock のデータ保持モードを none 以外に変更できなくなります。 重要: 新しいアカウントのデフォルトは inherit です ( none ではありません)。この SCP をアタッチする前に、各アカウントを明示的に none に設定する必要があります。まず、各アカウントで以下を実行してください。 aws bedrock put-account-data-retention --region us-east-1 --mode none 数百、数千の AWS アカウントを持っている場合は、この作業をスケールさせる方法が必要になります。その方法については、AWS re:Post の記事「 Automate Bedrock Zero Data Retention Across All Accounts in Your Organization 」を参照してください。 Amazon Bedrock ポリシー: このポリシーは、データ保持を none にのみ設定できるように制限するために使用します。 none 以外の値は拒否されます。 { "Version": "2012-10-17", "Statement": [ { "Sid": "RESTRICTBEDROCKDATARETENTION", "Effect": "Deny", "Action": [ "bedrock:PutAccountDataRetention" ], "Resource": "*", "Condition": { "StringNotEquals": { "bedrock:DataRetentionMode": "none" } } } ] } 仕組み Condition ブロックでは StringNotEquals を使用しており、 none 以外の値に対して拒否が発動します。これにより、以下が保証されます。 アクション 結果 モードを none に設定 許可 モードを provider_data_share に設定 SCP により拒否 モードを default に設定 SCP により拒否 モードを inherit に設定 SCP により拒否 この設定が組織にとって意味することは、以下のとおりです。 誰もモデルプロバイダーとのデータ共有を有効にできない – アカウント管理者であっても Access Denied を受け取ります provider_data_share を必要とするモデルは恒久的に利用不可になる – データ共有を必要とするモデル (Claude Fable 5 や Claude Mythos 5 など) は組織全体で動作しなくなります その他のすべてのモデルは引き続き通常どおり動作する – none モードをサポートするモデルは影響を受けません この設定は回避できない – IAM ポリシーで SCP の deny を上書きすることはできません オプション: プロジェクトレベルの上書きをブロックする bedrock-mantle エンドポイントは、プロジェクトレベルのデータ保持設定をサポートしています。追加の SCP でカバーしない場合、誰かが provider_data_share を設定したプロジェクトを作成または更新することで、アカウントレベルの制限を回避できてしまいます。これを防ぐには、SCP を拡張して bedrock-mantle のプロジェクトアクションを含めます。 { "Version": "2012-10-17", "Statement": [ { "Sid": "RESTRICTBEDROCKDATARETENTION", "Effect": "Deny", "Action": [ "bedrock:PutAccountDataRetention", "bedrock-mantle:PutAccountDataRetention", "bedrock-mantle:CreateProject", "bedrock-mantle:UpdateProject" ], "Resource": "*", "Condition": { "StringNotEquals": { "bedrock:DataRetentionMode": "none" } } } ] } なぜ bedrock-runtime にはプロジェクトレベルのブロックが不要なのか？ bedrock-runtime エンドポイントにはプロジェクトが存在しません。bedrock-runtime のトラフィックの保持設定を変更する唯一の方法は、アカウントレベルの bedrock:PutAccountDataRetention アクションであり、これは基本の SCP で既にブロックされています。追加の CreateProject と UpdateProject アクションが必要なのは、 bedrock-mantle がプロジェクトごとの保持設定の上書きを許可しているためであり、 bedrock-runtime ではプロジェクトレベルの制御は必要ありません。 データ保持とクロスリージョン推論 クロスリージョン推論プロファイルを使用する場合、データ保持モードがどのように評価されるかを理解しておくことが重要です。モードは、リクエストのソースリージョン、つまり API コールを行う AWS リージョンで評価されます。すべてのデスティネーションリージョンで保持モードを設定する必要はありません。 ただし、重要な注意点があります。モードのチェックはソースリージョンで行われますが、データ自体は推論が処理されるデスティネーションリージョンで保持される可能性があります。これは、保持されたデータが地理的にどこに存在するかを追跡している組織にとって重要なポイントです。 実際には何を意味するか データ保持と推論が実際にどのように動作するかを、以下に示します。 ソースリージョン (例: us-east-1) が provider_data_share に設定されている場合、クロスリージョン推論プロファイルを使用するリクエストは、デスティネーションリージョンの保持設定にかかわらず許可されます ソースリージョンが none に設定されている場合、 provider_data_share を必要とするモデルへのリクエストは、デスティネーションリージョンにルーティングされる前に、ソース側でブロックされます SCP は引き続きグローバルに適用されます。ルート OU の単一の SCP により、すべてのリージョンで provider_data_share が自動的にブロックされます SCP はグローバルに適用される データ保持設定はきめ細かい制御に役立ちますが、SCP を使用すれば、すべてのリージョンにわたってデータ保持の制限をグローバルに自動適用できます。ルート OU にアタッチされた単一の SCP により、リージョンごとに設定を行うことなく、すべてのリージョンで provider_data_share がブロックされます。これが、手動設定に頼るのではなく SCP を強制手段として使用することの主な利点の 1 つです。 設定を検証する データ保持設定と SCP の強制は、AWS SDK、 AWS コマンドラインインターフェイス (AWS CLI) 、または Amazon Bedrock コンソールを使用して検証できます。 現在の保持モードを確認する 現在の保持モードは、以下の方法で確認できます。 Amazon Bedrock コンソールを使用する場合: AWS マネジメントコンソールで新しい Amazon Bedrock (mantle エンドポイント) コンソールに移動し、[ 設定 ] を選択してから、[ データ保持 ] を選択します。ここで、現在のアカウントレベルの保持モードを確認し、直接変更できます。 訳注: bedrock-runtime 経由 ( aws bedrock コマンド、Invoke / Converse API) と bedrock-mantle 経由のアカウントレベルのデータ保持モードは、それぞれ独立した設定です。一方を変更しても他方には反映されません。コンソールで変更できるのは mantle 側のみのため、 bedrock-runtime のトラフィックを制御するには、別途 aws bedrock コマンドまたは API での設定が必要です。 AWS CLI を使用する場合 (CLI バージョン 2.35 以降が必要): aws bedrock get-account-data-retention --region us-east-1 想定されるレスポンス: { "mode": "none", "updatedAt": "2026-07-01T01:58:34.684Z" } bedrock-mantle API を使用する場合 (Amazon Bedrock API キーを使用): curl https://bedrock-mantle.us-east-1.api.aws/v1/data_retention \ -H "x-api-key: $BEDROCK_API_KEY" 想定されるレスポンス: { "mode": "none", "updated_at": 1719792000 } モデルの有効なモードと許可されているモードを確認する bedrock-mantle API を使用して、特定のモデルでどの保持モードが有効になっているか、およびそのモデルがどのモードをサポートしているかを確認することもできます。 curl https://bedrock-mantle.us-east-1.api.aws/v1/models/anthropic.claude-fable-5 \ -H "x-api-key: $BEDROCK_API_KEY" レスポンス: { "id": "anthropic.claude-fable-5", "status": "available", "data_retention": { "mode": "provider_data_share", "source": "account", "allowed_modes": ["provider_data_share"] } } モデルが "status": "unavailable" と表示される場合、 status_reason フィールドに保持モードの競合に関する説明が表示されます。 SCP が機能していることを検証する SCP がデータ保持の変更を実際にブロックしていることを確認するには、モードを provider_data_share に設定してみてください。 AWS CLI を使用する場合: aws bedrock put-account-data-retention \ --region us-east-1 \ --mode provider_data_share bedrock-mantle API を使用する場合: curl -X PUT https://bedrock-mantle.us-east-1.api.aws/v1/data_retention \ -H "x-api-key: $BEDROCK_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "mode": "provider_data_share" }' SCP が機能している場合 、 Access Denied エラーが返されます。 An error occurred (AccessDeniedException) when calling the PutAccountDataRetention operation: User: arn:aws:iam::123456789012:user/admin is not authorized to perform: bedrock:PutAccountDataRetention with an explicit deny in a service control policy SCP が機能していない場合 、リクエストは成功してしまいます。この場合は、直ちに設定を元に戻してください。 aws bedrock put-account-data-retention \ --region us-east-1 \ --mode none その後、SCP のアタッチについて、以下の観点でトラブルシューティングを行います。 SCP が子 OU ではなくルート OU にアタッチされていることを確認する SCP ポリシーの構文と条件キーを確認する AWS Organizations の管理アカウントは SCP の対象外であることに注意する。そのアカウントにポリシーを強制するには IAM ポリシーを使用してください データ保持を必要とするモデルでデータ保持を有効にする provider_data_share を必要とするモデルを使用したいアカウント (SCP が適用されていないアカウント) では、AWS CLI、API、またはコンソールを使用してモードを設定します。 AWS CLI を使用する場合: aws bedrock put-account-data-retention \ --region us-east-1 \ --mode provider_data_share bedrock-mantle API を使用する場合: curl -X PUT https://bedrock-mantle.us-east-1.api.aws/v1/data_retention \ -H "x-api-key: $BEDROCK_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "mode": "provider_data_share" }' 新しい Amazon Bedrock (mantle エンドポイント) コンソールの [ 設定 ] にある [ データ保持 ] からも設定できます。 データ保持を none に戻す ゼロデータ保持に戻すには、以下を実行します。 AWS CLI を使用する場合: aws bedrock put-account-data-retention \ --region us-east-1 \ --mode none bedrock-mantle API を使用する場合: curl -X PUT https://bedrock-mantle.us-east-1.api.aws/v1/data_retention \ -H "x-api-key: $BEDROCK_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "mode": "none" }' プロジェクトレベルのデータ保持を管理する プロジェクトレベルでデータ保持を設定することで、同じアカウント内の異なるワークロードに異なる保持ポリシーを適用できます。プロジェクトのデータ保持モードを更新するには、 bedrock-mantle API を使用します。 # Set a project to provider_data_share curl -X POST https://bedrock-mantle.us-east-1.api.aws/v1/organization/projects/proj_abc123 \ -H "x-api-key: $BEDROCK_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "data_retention": { "mode": "provider_data_share" } }' # Set a project to none (zero retention) curl -X POST https://bedrock-mantle.us-east-1.api.aws/v1/organization/projects/proj_abc123 \ -H "x-api-key: $BEDROCK_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "data_retention": { "mode": "none" } }' # Check a project's current setting curl -X POST https://bedrock-mantle.us-east-1.api.aws/v1/organization/projects/proj_abc123 \ -H "x-api-key: $BEDROCK_API_KEY" プロジェクトレベルの保持の解決方法: リクエストに対する有効なモードは、プロジェクト、アカウント、モデルのデフォルトという階層の中で、最初に見つかった inherit 以外の値によって決まります。プロジェクトが none に設定されている場合、アカウント設定にかかわらずゼロデータ保持が強制されます。プロジェクトが inherit に設定されている場合は、アカウントレベルの設定に従います。 注: プロジェクトレベルのデータ保持は、 bedrock-mantle API を通じてのみ管理できます。プロジェクトレベルの設定用の AWS CLI コマンドはありません。前述の AWS CLI コマンドは、Amazon Bedrock コントロールプレーンを通じてアカウントレベルの設定のみを管理します。 まとめ 本記事では、プロジェクトレベルのデータ保持や、SCP を使用して実装できる組織全体での制御など、Amazon Bedrock でデータ保持を管理するさまざまな方法を紹介しました。要件に合った組み合わせを選択し、デプロイ前に Amazon Bedrock のドキュメントで各モデルのモード要件を確認してください。 Amazon Bedrock のデータ保持の詳細については、「 データ保持のドキュメント 」を参照してください。SCP については、AWS Organizations ユーザーガイドの「 サービスコントロールポリシー 」を参照してください。 その他のリソース Amazon Bedrock のデータ保持 – 保持モード、設定、IAM による強制に関する完全なドキュメント クロスリージョン推論プロファイル – 推論が AWS リージョン間でどのようにルーティングされるかを理解する Amazon Bedrock の不正使用検出 – 安全性の目的で保持されるデータ 拒否されたリクエストに対するフォールバッククレジット – Fable 5 が Opus 4.8 にフォールバックした場合の請求の仕組み Claude Fable 5 と Mythos 5 の発表 – 新しいデータ保持ポリシーに関する Anthropic の説明 Anthropic データ処理補遺 – Anthropic と共有されるデータを管理する法的条件 サービスコントロールポリシー (SCP) – AWS Organizations のドキュメント ぜひ本記事の例をお試しください。フィードバックは、 AWS re:Post for Amazon Bedrock または通常の AWS サポートの窓口を通じてお寄せください。 Rob Higareda Rob は AWS の Security Risk and Compliance 組織のプリンシパルソリューションアーキテクトで、AI を活用したサービスのリスク評価に注力しています。システムエンジニアとして 20 年以上の経験を経て AWS に入社しました。主に AWS の規制対象のお客様を担当し、セキュリティとインフラストラクチャの設計に取り組んでいます。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本記事は 2026 年 7 月 6 日 に公開された「 Deploying VCF 9.1 on Amazon EVS with End-to-End Automation 」を翻訳したものです。 はじめに Amazon Elastic VMware Service (Amazon EVS) を使用すると、Amazon VPC 内の AWS ベアメタル EC2 インスタンス上で VMware Cloud Foundation (VCF) を直接実行できます。EVS では、使い慣れた VMware スタックの運用一貫性を維持しながら、AWS クラウドサービスの弾力性、セキュリティ、豊富な機能を活用できます。 VCF 9 は VMware Cloud Foundation の最新リリースであり、以前の VCF 5.2 リリースとは根本的に異なる方法で Amazon EVS と連携します。VCF 5.2 では、EVS サービスがデプロイ全体をエンドツーエンドで処理していました。VLAN サブネットのデプロイ、ホストを含む EVS 環境、および完全な VCF スタックはすべて、サービスが自動的にプロビジョニングおよび設定していました。VCF 9 では、Amazon EVS はセルフデプロイモードと呼ばれる方式でのみ動作します。 セルフデプロイモードとは？ セルフデプロイモードでは、Amazon EVS が基盤となる AWS インフラストラクチャをプロビジョニングします。具体的には、VCF に必要な VLAN サブネットと、選択した ESXi バージョン（9.0 または 9.1）を実行するベアメタル EC2 ホストです。ただし、サービスが担うのはここまでです。EVS は VCF 自体のインストールや設定は行いません。EVS が代わりに VCF 9 をデプロイするオプションは存在しません。 つまり、EVS がホストとネットワークを提供した後は、VCF のインストールはお客様の責任となります。VMware のドキュメントに従って手動でインストールするか、自動化を使ってプログラム的に処理できます。本ブログ記事ではまさにその自動化を取り上げます。AWS が公開した エンドツーエンドの自動化ツールキット は、前提条件となる AWS インフラストラクチャと EVS 環境のプロビジョニングから、VCF のインストールおよび設定まで、ワークフロー全体を処理します。このツールキットは VCF 9.0 と 9.1 の両方に対応しています。 VCF デプロイを自動化する理由 セルフデプロイモードでは VCF 9 のインストールはお客様の責任であるため、自動化が特に効力を発揮します。VCF の手動インストールには、数十もの設定ステップ、複雑な JSON 仕様の作成、パスワード生成、そして数時間の待機が必要です。本ツールキットはそれを 3 つの CLI コマンドに集約します。 再現性：リージョンやアカウントをまたいで同一環境をデプロイ可能 スピード：数時間かかる手動プロセスを 3 コマンドに短縮 監査性：すべての設定判断がバージョン管理されたコードに記録 エラー削減：DNS レコード、VLAN CIDR、bringup 仕様における手動入力ミスを排除 セキュリティ：パスワードを自動生成して AWS Secrets Manager に保存 構築するもの 自動化ツールキットは VCF 9.0 と 9.1 の両方に対応していますが、本ブログでは VCF 9.1 のデプロイに絞って説明します。このウォークスルーを完了すると、以下が構築されます。 Route 53 DNS、BGP 対応 Route Server、必要なネットワーキングを備えた VPC ESXi 9.1 を実行する 3 台のベアメタルホストを持つ Amazon EVS 環境 完全に動作する VCF 9.1 スタック：vCenter、SDDC Manager、NSX Manager、VCF Operations、VCF Cloud Proxy、2 台の NSX Edge NSX オーバーレイセグメントと VPC ルートテーブル間で動的なルート伝播を行う Tier-0 および Tier-1 ゲートウェイ EVS サービス内の Ops Manager Connector コストの考慮事項 本自動化でデプロイされるリソースには、EC2 ベアメタルコンピューティング、Amazon EVS コントロールプレーン、VPC Route Server、Transit Gateway（有効化した場合）、NAT Gateway、EBS ボリューム、Route 53 ホストゾーンなど、相当な月額費用が発生します。デプロイ前に Amazon EVS 料金ページ を確認し、 AWS Pricing Calculator を使って環境全体のコストを把握することをお勧めします。 アーキテクチャの概要 本自動化は、完全な Amazon EVS 環境と VCF 9 を 3 つのステージにわたってデプロイします（1 ステージにつき 1 つのレイヤー）。最初に設定の詳細を入力するだけで、各ステージで生成されたリソース ARN などのメタデータとともに設定値が次のステージへ自動的に引き継がれます。同じ情報を 2 度入力する必要はなく、設定ミスを大幅に削減できます。各ステージの内容は次のとおりです。 AWS 前提条件とアンダーレイ： VPC、サービスアクセスサブネット、Route 53（フォワードおよびリバースゾーン）、2 つの BGP エンドポイントを持つ Route Server、セキュリティグループ、オプションの Transit Gateway、オプションの Windows ジャンプボックス（踏み台サーバー）、オプションのパブリックまたはプライベート HCX 接続などを構築します。 EVS レイヤー： まず、管理、vMotion、vSAN、vTEP、エッジアップリンクなどに使用する 10 個の VLAN サブネットを作成し、EVS 環境を構築します。次に、ESXi 9.1 で起動する 3 台のベアメタルホスト（ユーザーが指定する i4i.metal または i7i.metal-24xl）をプロビジョニングします。最後に、VCF Installer をステージングするデータストアとして EBS ボリュームを作成し、いずれかのホストにマウントします。 VCF のインストールと NSX ルーティング： VCF Installer のデポを設定し、ターゲット VCF バージョンに基づいてバイナリのダウンロードを自動的にトリガーします。次に vCenter、SDDC Manager、NSX Manager、VCF Operations、VCF Cloud Proxy、アクティブ/スタンバイ構成の 2 台の NSX Edge をデプロイします。エッジは BGP で AWS Route Server とピアリングし、NSX セグメントルートを VPC にアドバタイズします。 3 フェーズの自動化アプローチ 本自動化は 3 つの順次フェーズで構成されており、それぞれ独自のツールと目的を持ちます。 フェーズ スタック 内容 1 Terraform VPC、Route 53、Route Server、セキュリティグループ、オプションの Transit Gateway、オプションのジャンプボックス、オプションのパブリック接続など 2 Python (boto3) EVS 環境と VLAN サブネットの作成、ESXi 9.1 を搭載したベアメタルホストのプロビジョニング、インストーラーステージング用 EBS ボリュームの作成とアタッチ 3 Python (VCF SDK + boto3) デポの設定、バイナリのダウンロード、VCF bringup、インストーラーのクリーンアップ、NSX Edge Cluster とルーティングのデプロイ、Ops Manager Connector の作成 フェーズ 1 と 2 は Mac、Linux、または Windows ワークステーションからローカルで実行します。フェーズ 3 は VPC 内のジャンプボックスから実行します（VCF Installer および NSX Manager への直接接続に必要）。唯一の手動ステップは、フェーズ 2 と 3 の間に行う 2 つの簡単な ESXi 設定と VCF Installer OVA のデプロイです。デプロイ全体の所要時間はおよそ 3.5〜6 時間で、大部分はフェーズ 3 の VCF bringup プロセスが占めます。 前提条件 AWS アカウントと権限 以下を満たす AWS アカウント AWS Business Support 以上 EVS 環境あたりのホスト数サービスクォータが 3 以上に設定済み オンデマンドスタンダード（A、C、D、H、I、M、R、T、Z）インスタンスのサービスクォータが 256 以上に設定済み コードリポジトリのフェーズ 1 配下にある iam_policy.json ファイルで定義された権限ポリシーを持つ IAM ユーザーまたはロール ローカルワークステーションのツール Terraform 1.7 以降 Python 3.12 以降 AWS CLI v2 （AWS_PROFILE または環境変数でクレデンシャルを設定済み） pip （Python 依存関係のインストール用） git （コードリポジトリのクローン用） Broadcom デポトークン フェーズ 3 では Broadcom デポから VCF コンポーネントのバイナリをダウンロードします。Broadcom サポートポータルの「My Dashboard」→「Quick Links」→「Generate Download Token」からダウンロードトークンを生成してください。このトークンはフェーズ 3 の実行前に VCF_DEPOT_TOKEN 環境変数として設定します。 VCF Installer OVA Broadcom ダウンロードポータルから VCF 9.1 Installer OVA をダウンロードしてください。このアプライアンスはフェーズ 2 と 3 の間に、いずれかの ESXi ホスト上へ手動でデプロイします。 リポジトリのクローン 自動化リポジトリをクローン してローカルワークステーションに配置してください（このコマンドは Linux と Windows の両方で使用できます）。 git clone https://github.com/aws/solutions-for-amazon-evs.git cd solutions-for-amazon-evs/Deploy/VCF9-Phased-Deployment  フェーズ 0：デプロイ前の入念な計画 自動化を実行する前に、設定ファイルを慎重に計画して入力する必要があります。このステップは非常に重要です。インフラストラクチャをデプロイした後は、環境全体を解体して再構築しなければ変更できない値が多数あるため、時間をかけて正確に設定してください。 自動化では、最初に 1 度だけ入力する 2 つの設定ファイルを使用します。その後のフェーズはこれらのファイルから値を読み取り、次のフェーズへ自動的に引き継ぎます。 terraform.tfvars（フェーズ 1 の入力） このファイルは AWS インフラストラクチャの基盤を定義します。 terraform.tfvars.example を terraform.tfvars にコピーして以下を設定してください（Linux）。 cd Phase_1_Base_Infrastructure cp terraform.tfvars.example terraform.tfvars  Windows の場合： cd Phase_1_Base_Infrastructure copy terraform.tfvars.example terraform.tfvars  以下の値を実際の環境に合わせて更新してください。 region ：デプロイ先の AWS リージョン（例：us-east-2）。Amazon EVS が利用可能なリージョンを指定してください。 availability_zone ：リージョン内の特定の AZ（例：us-east-2a）。すべてのリソースは単一の AZ にデプロイされます。EC2 キャパシティ予約がある場合は、予約済みの AZ と一致させてください。 fqdn ：環境の完全修飾ドメイン名（例：mylab.evs.aws）。Route 53 フォワードホストゾーンとなり、すべての DNS レコードに使用されます。慎重に選択してください。 cidr_prefix ：VPC CIDR の最初の 2 オクテット（例：”10.0.”）。自動化はこのプレフィックスからすべての VLAN サブネット CIDR を導出します。Transit Gateway または Direct Connect で接続する予定のネットワークと重複しないようにしてください。 DNS ホスト名 ：各 VCF アプライアンスと ESXi ホストの短い DNS 名（esxi01_name から vcf_fleet_name まで）。 create_tgw ：他の VPC やオンプレミスネットワークへの Transit Gateway 接続が必要な場合は true に設定してください。 create_jumpbox ：Windows ジャンプホストを作成する場合は true に設定してください。VPC 内から実行する必要があるフェーズ 3 に必須です。このフラグを有効にすることをお勧めします。 enable_public_hcx ：HCX インターネット接続用のパブリック IP スペースを割り当てる場合は true に設定してください。false の場合、HCX はプライベート VLAN を使用します（Direct Connect または Transit Gateway 経由の HCX に適しています）。 VPC CIDR の分割方法 cidr_prefix で最初の 2 オクテットのみ指定します（例：”10.0.”）。自動化は /16 の VPC を作成し、ハードコードされた第 3 オクテットを使って /24 の VLAN サブネットに分割します。 <prefix>0.0/24 — サービスアクセスサブネット <prefix>10.0/24 — ホスト vmkernel 管理（vmkManagement） <prefix>20.0/24 — vMotion <prefix>30.0/24 — vSAN <prefix>40.0/24 — Host TEP (vTep) <prefix>50.0/24 — Edge TEP (edgeVTep) <prefix>60.0/24 — VM 管理（vmManagement） <prefix>70.0/24 — HCX <prefix>80.0/24 — NSX アップリンク（nsxUplink） <prefix>90.0/24 — 拡張 VLAN 1 <prefix>100.0/24 — 拡張 VLAN 2 config.json でこれらの VLAN サブネット CIDR を変更する場合は、NSX Edge IP、Route 53 インバウンドリゾルバーエンドポイント（<prefix>0.100 および <prefix>0.101）、BGP アップリンクアドレスなど、サブネット内に設定されるハードコードされた IP アドレスと競合しないよう注意してください。 config.json（フェーズ 2 の入力） このファイルは EVS 環境と VCF デプロイパラメーターを定義します。 config.example.json を config.json にコピーして以下を設定してください（Linux）。 cd Phase_2_evs_env/python cp config.example.json config.json Windows の場合： cd Phase_2_evs_env/python copy config.example.json config.json  以下の値を実際の環境に合わせて更新してください。 environmentName ：EVS 環境のわかりやすい名前。AWS コンソールに表示され、リソースのタグ付けに使用されます。 vcfInstallerProductVersion ：VCF Installer の製品バージョン番号のみ（ビルド文字列は含めない）。例：”9.1.0.0″。正確な値は OVA ファイル名またはインストーラー UI の設定ページで確認してください。 simpleDeployment ：単一ラック・シンプルデプロイ（最小 3 ホスト）の場合は true、単一ラック・HA デプロイ（最小 4 ホスト）の場合は false を設定してください。この設定は、デプロイされる NSX Manager と VCF Operations ノードの数に影響します。詳細は Single-Rack vSphere クラスターモデルのドキュメント を参照してください。 vcfSizing ：vCenter（vmSize、storageSize）、NSX（nsxSize）、VCF Operations（operationsApplianceSize、operationsCollectorApplianceSize）のアプライアンスサイジング。ほとんどのデプロイでは “medium” のデフォルト値が適切です。 ヒント： FQDN、CIDR プレフィックス、ホスト名の選択は事前に十分確認してください。フェーズ 1 のデプロイ後にも検証することをお勧めします。フェーズ 1 の削除と再デプロイは数分で完了するため、この時点であれば変更は容易です。フェーズ 2 で FQDN や CIDR などの値を組み込んだ EVS 環境がデプロイされると、変更には最初から再構築が必要になります。 フェーズ 1：基盤 AWS インフラストラクチャ（Terraform） フェーズ 1 で作成されるもの フェーズ 1 は、EVS が必要とする AWS ネットワークおよびサポートリソースをすべてプロビジョニングします。 terraform apply が完了すると（通常 3〜5 分）、以下が構成されます。 VCF アプライアンスと ESXi ホスト用の Route 53 プライベートホストゾーン フォワードホストゾーン（A レコード） リバースホストゾーン（PTR レコード） 2 つの IP を持つインバウンドリゾルバーエンドポイント Amazon VPC 専用サービスアクセスルートテーブルに関連付けられたプライベートサービスアクセスサブネット 専用パブリックアクセスルートテーブルに関連付けられたパブリックアクセスサブネット Elastic IP を持つ NAT Gateway Internet Gateway FQDN、Route 53 インバウンドリゾルバー IP、NTP（169.254.169.123：AWS NTP サーバー）を設定した DHCP オプションセット VPC CIDR からの受信を許可する専用 EVS サービスアクセスセキュリティグループ VPC Route Server VPC に関連付け済み それぞれピア IP、ピア ASN（65000）、BGP キープアライブを設定した 2 つの Route Server エンドポイント サービスアクセスルートテーブルとパブリックアクセスルートテーブルへの 2 つの Route Server 伝播 EVS ホスト用の EC2 キーペア （オプション）アンダーレイ VPC への VPC アタッチメントを持つ Transit Gateway （オプション）VPC 内の Windows ジャンプホスト ジャンプホスト用の VPC パブリックサブネット Internet Gateway へのルートを持つジャンプホスト用専用ルートテーブル 専用ルートテーブルへの Route Server 伝播 VPC CIDR と EVS サービスアクセスセキュリティグループからのすべてのトラフィックを許可するジャンプホスト用専用セキュリティグループ 50 GB 暗号化 gp3 ルートボリュームとパブリック IPv4 アドレスを持つ、Windows Server 2025 を実行する t3.2xlarge EC2 インスタンス ジャンプホスト用専用 EC2 キーペア 注：このキーペアは “Jumpbox-KeyPair” という名前です。同名のキーペアが既に存在する場合、このコードは失敗します。その場合はコード内でキーペア名を変更してください。 （オプション）パブリック HCX 接続 IPv4 IPAM プール 連続したパブリック IP スペースの /28 VPC CIDR へのパブリック /28 の追加 デプロイの実行（Linux）： export AWS_PROFILE=your-profile-name    terraform init  terraform plan  terraform apply  Windows の場合： $env:AWS_PROFILE = "your-profile-name" terraform init terraform plan terraform apply Terraform は VPC ID、サブネット ID、Route Server エンドポイント IP、セキュリティグループ ID などの値を出力します。フェーズ 2 はこれらを terraform.tfstate ファイルから直接読み取ります。フェーズ 1 のデプロイはおよそ 5〜10 分で完了します。 インフラストラクチャの検証 フェーズ 1 の完了後、AWS コンソールで以下を確認してください。 期待される CIDR で VPC が作成されていること Route 53 ホストゾーンに、すべての VCF アプライアンスと ESXi ホストの A レコードおよび PTR レコードが含まれていること Route Server の 2 つのエンドポイントが “Available” 状態であること ジャンプボックスを使用する場合：インスタンスが実行中でパブリック IP を持つこと ジャンプボックスをデプロイした場合は、以下の手順で RDP アクセスを確立してください。 Jumpbox-SG セキュリティグループに、自分の IP アドレスからの RDP（TCP 3389）を許可するインバウンドルールを追加する EC2 キーペアを取得して Windows Administrator パスワードを復号する。PEM ファイルをダウンロードする（Linux）： KEY_PAIR_ID=$(terraform output -raw jumpbox_key_pair_id) aws ssm get-parameter --name /ec2/keypair/$KEY_PAIR_ID --with-decryption \ --region us-east-2 --query 'Parameter.Value' --output text > jumpbox.pem chmod 400 jumpbox.pem Windows の場合： $KEY_PAIR_ID = terraform output -raw jumpbox_key_pair_id aws ssm get-parameter --name "/ec2/keypair/$KEY_PAIR_ID" --with-decryption ` --region us-east-2 --query 'Parameter.Value' --output text | Out-File -Encoding ascii jumpbox.pem icacls jumpbox.pem /inheritance:r /grant:r "$($env:USERNAME):(R)" この PEM ファイルを EC2 コンソール（Connect > Get Windows Password）で使用して Administrator パスワードを復号してください。 最後に、VCF Installer OVA をジャンプホストにダウンロードまたはコピーしてください。フェーズ 2 と 3 の間の手動作業ステップで必要になります。 フェーズ 2：EVS 環境のデプロイ（Python） フェーズ 2 の処理内容 フェーズ 2 は Python CLI で、AWS API 経由で EVS デプロイを調整し、SDDC bringup 仕様と NSX デプロイ仕様を構築します。単一の CLI コマンドで、以下の 6 つのサブステップを順番に実行します。 pre-evs-sync-config ：フェーズ 1 の Terraform ステートを読み取り、VCF bringup 仕様とエッジクラスター仕様の初期版を生成 create-environment-and-hosts ：AWS API を呼び出して EVS 環境を作成し、完了後にベアメタルホストをプロビジョニング（15〜20 分） すべてのホストが CREATED ステータスになるまで待機（20〜40 分） post-evs-sync-config ：環境とホスト ID から派生した名前で SDDC 仕様を確定し、対応する VCF パスワードを Secrets Manager にプロビジョニング associate-vlan-subnets ：10 個の EVS VLAN サブネットをすべてサービスアクセスルートテーブルに関連付け create-and-attach-ebs ：256 GB の gp3 EBS ボリュームを作成し、VCF Installer VMFS 用として 1 台のホストにアタッチ deploy-environment の実行 Python 環境をセットアップし、単一コマンドでフェーズ 2 のパイプライン全体を実行します（Linux）。 python -m venv .venv source .venv/bin/activate pip install -r requirements.txt python -m src.main deploy-environment \ --profile your-aws-profile \ --config config.json \ --tfstate ../../Phase_1_Base_Infrastructure/terraform.tfstate \ --instance-type <INSTANCE_TYPE> # 'i4i.metal' or 'i7i.metal-24xl' Windows の場合： py -m venv .venv .venv\Scripts\Activate.ps1 pip install -r requirements.txt python -m src.main deploy-environment ` --profile your-aws-profile ` --config config.json ` --tfstate ..\..\Phase_1_Base_Infrastructure\terraform.tfstate ` --instance-type <INSTANCE_TYPE> # 'i4i.metal' or 'i7i.metal-24xl' このコマンドは 6 つのサブステップを自動的に連結して実行します。合計所要時間はおよそ 30〜45 分で、大部分はベアメタルホストがプロビジョニングされて CREATED ステータスになるまでの待機時間が占めます。デバッグ用に各サブステップを個別に実行することも可能ですが、単一コマンドによるアプローチを 強く推奨 します。 Secrets Manager によるパスワード管理 フェーズ 2 の構築中、post-evs-sync-config サブステップがすべての VCF アプライアンス用の複雑なパスワードを自動生成し、AWS Secrets Manager に保存します。命名パターンは evs-<environment-id>_<role> です。 VCF のアカウントには vcenterRoot 、 vcenterSso 、 nsxRoot 、 nsxAdmin 、 nsxAudit 、 sddcManagerRoot 、 sddcManagerSsh 、 sddcManagerLocal 、 operationsAdmin 、 operationsMaster 、 operationsCollector 、 edgeAppliance が含まれます。 bringup 仕様はプレースホルダートークンを通じてこれらのパスワードを参照します。フェーズ 3 は実行時に Secrets Manager からパスワードを解決するため、平文パスワードがディスクに書き込まれることはありません。 手動による事前作業：ESXi 設定とインストーラー OVA フェーズ 2 と 3 の間に、いくつかの簡単な手順を手動で実施する必要があります。デプロイ全体を通じて唯一の非自動化部分であり、所要時間はおよそ 30 分です。以下の手順はすべて、フェーズ 2 で EBS ボリュームを受け取った 1 台の ESXi ホスト上で実施します。 EBS ボリュームへの VMFS データストアの作成 フェーズ 2 でいずれかの ESXi ホストに 256 GB の EBS ボリュームをアタッチしました。フェーズ 2 のコンソール出力で、どのホストがボリュームを受け取ったか確認できます。VCF Installer アプライアンスをホストするために、VMFS データストアとしてフォーマットする必要があります。 ESXi ホスト UI（ https://<esxi-host-ip> ）に root としてログインします。root パスワードは AWS Secrets Manager から取得してください（シークレット名は evs-<environment-id>_<role> のパターンです）。 Storage に移動し、New Datastore を選択する NVMe デバイス（256 GB EBS ボリューム）を選択して VMFS データストアを作成する VM Network ポートグループへの VLAN タグ付け EBS ボリュームを持つ ESXi ホストで、デフォルトの “VM Network” ポートグループに VLAN ID 20 をタグ付けし、VCF Installer が VM 管理ネットワークで通信できるようにします。 ESXi UI で Networking に移動し、Port groups を選択する “VM Network” ポートグループを編集する VLAN ID を 20 に設定する VCF Installer OVA のデプロイ VMFS データストアを持つホスト上に VCF Installer アプライアンスをデプロイします。 ESXi UI で Virtual Machines > Create/Register VM > Deploy OVF template に移動する VCF 9.1 Installer OVA ファイルをアップロードする 上記で作成した 256 GB VMFS データストアに配置する “VM Network” ポートグループにアタッチする 管理 IP を DNS 設定の SDDC Manager IP アドレスに設定する ネットマスクを 255.255.255.0 に設定する admin@local パスワードを設定する。手動で選択する唯一のパスワードです。独自のパスワードを作成するか、Secrets Manager に生成済みのパスワードを使用することもできます。フェーズ 3 で必要になるためパスワードを控えておいてください。 アプライアンスの電源を入れ、起動を待つ（ https://<sddcm_name>.<your-fqdn> でアクセスを確認） フェーズ 3：VCF Bringup と NSX Edge Cluster（Python） フェーズ 3 の処理内容 フェーズ 3 は EVS 環境をホストする VPC 内のジャンプホストから実行する必要があります。公式 VMware VCF Python SDK（vcf-installer、vcf-nsx）と vCenter 操作用 pyvmomi、および対応する AWS 操作用 boto3 ライブラリを使用します。単一の CLI コマンドで、以下の 7 つのサブステップを順番に実行します。 Secrets Manager 事前確認 ：開始前に必要なすべての Secrets Manager シークレットが存在することを確認。不足している場合、不足している VCF アカウントを明示したエラーでパイプラインを即座に終了。 prepare-depot ：Broadcom ダウンロードトークンをインストーラーに設定し、デポカタログを同期して必要なすべてのコンポーネントバイナリをダウンロード（約 30〜60 分） start-bringup --wait ：bringup 仕様を VCF Installer に送信し、ワークフローが完了するまでポーリング。vCenter、NSX Manager、SDDC Manager、VCF Operations をデプロイ（約 2〜4 時間） remove-installer-datastore ：手動で作成した 256 GB VMFS データストア上の VM を vSAN にストレージ vMotion し、データストアをアンマウント（約 5〜10 分） destroy-ebs-volume ：AWS 側からアンマウント済み VMFS データストアをホストしていた EBS ボリュームをデタッチして削除（約 30 秒） deploy-edge-cluster ：2 台の NSX Edge アプライアンスをデプロイし、エッジクラスターを作成し、Tier-0/Tier-1 ルーティングを設定し、AWS Route Server との BGP ピアリングを確立（約 30〜50 分） create-connector ：VCF Operations Manager コネクターを CreateEnvironmentConnector 経由で EVS に登録。 ACTIVE になるまでポーリング（約 2〜5 分） 以下のサブセクションでは、フェーズ 3 の内部処理をより詳細に段階的に説明します。 deploy-vcf-and-edge の実行 と題したセクションに、フェーズ 3 のワークフロー全体を実行する単一コマンドが記載されています。 デポとバンドルの管理 prepare-depot サブステップは、VCF Installer UI にログインして Broadcom デポを設定する手動プロセスを自動化します。具体的には以下を実行します。 VCF SDK 経由でデポトークンをインストーラーに保存 メタデータ同期をトリガーしてバンドルカタログを更新 ターゲットバージョンに一致するすべての INSTALL タイプバンドルを特定 必要なすべてのコンポーネントバイナリ（vCenter、NSX、SDDC Manager、VCF Operations、ESXi）をダウンロード すべてのダウンロードが完了するまでポーリングし、その後 bringup に進む ヒント ：デポの問題をデバッグする必要がある場合、list-bundles、get-depot-settings、sync-depot などの個別アクションをスタンドアロン CLI コマンドとして実行できます。 VCF bringup ワークフロー start-bringup アクションは型付きの SddcSpec を VCF Installer に送信し、ワークフローを監視します。bringup 中にインストーラーは以下を実行します。 ESXi ホストを VCF 管理ドメインにコミッション vCenter Server をデプロイして設定 NSX Manager をデプロイして仮想 IP アドレスでクラスター化 SDDC Manager をデプロイ VCF Operations をデプロイ すべてのホストで vSAN ESA を設定 必要なすべてのポートグループを持つ分散仮想スイッチを作成 ヒント： CLI は 10 分ごとにインストーラーをポーリングして進捗を報告します。bringup が失敗した場合は、 https://<sddcm_name>.<your-fqdn> のインストーラー UI でタスクごとの詳細なエラー情報を確認してください。 インストーラーのクリーンアップ bringup が正常に完了した後、自動化は 2 つのクリーンアップステップを実行します。 remove-installer-datastore ：ローカル VMFS データストアに配置された VM を vSAN にストレージ vMotion し、データストアをホストからアンマウントします。これにより EBS ボリュームが削除可能になります。 destroy-ebs-volume ：EC2 インスタンスから EBS ボリュームをデタッチして削除します。ボリュームは ManagedBy タグと EnvironmentId タグで識別され、他のボリュームを誤って削除しないよう保護されています。 NSX Edge Cluster のデプロイ 次のサブステップは NSX Manager と vCenter API を直接使用して NSX Edge Cluster をデプロイします。7 つのステージで実行されます。 prep-edge-cluster ：DVS TRUNK ポートグループ、IP プール、アップリンクプロファイル、VLAN トランスポートゾーンを作成 deploy-edge-nodes ：2 台のラージフォームファクター エッジトランスポートノードを作成（OVA デプロイをトリガー） create-edge-cluster ：両方のトランスポートノードをグループ化するエッジクラスターを作成 create-tier0 ：ロケールサービスと BGP を有効にした Tier-0 ゲートウェイを作成 create-tier1 ：Tier-0 とエッジクラスターにアタッチした Tier-1 ゲートウェイを作成 configure-routing ：アップリンクセグメント、インターフェース、BGP ネイバー、プレフィックスリスト、スタティックルート、再配布を設定 create-anti-affinity ：エッジ VM 用の vCenter DRS アンチアフィニティルールを作成 各エッジアプライアンスは ASN 65000（NSX 側）と 65022（AWS 側）を使って 1 つの AWS Route Server エンドポイントと BGP ピアリングします。ピアリングが確立されると、NSX オーバーレイセグメントが VPC ルートテーブルにルートとして自動的にアドバタイズされます。 Ops Manager Connector 最後のサブステップは VCF Operations Manager コネクターを Amazon EVS に登録します。これは仮想マシンの Windows Server ライセンスエンタイトルメントの作成など、後続のアクションに使用されます。 環境変数の設定 フェーズ 3 では Secrets Manager に保存されていない 2 つのシークレットが必要です。手動手順で設定した VCF_INSTALLER_PASSWORD と、Broadcom ポータルから取得した VCF_DEPOT_TOKEN です。以下のコマンドで環境変数として設定します（Linux）。 # The admin@local password you set when deploying the installer OVA: read -rs VCF_INSTALLER_PASSWORD ; export VCF_INSTALLER_PASSWORD # Your Broadcom depot download token: read -rs VCF_DEPOT_TOKEN ; export VCF_DEPOT_TOKEN Windows の場合： # The admin@local password you set when deploying the installer OVA: $env:VCF_INSTALLER_PASSWORD = Read-Host -MaskInput "VCF Installer Password" # Your Broadcom depot download token: $env:VCF_DEPOT_TOKEN = Read-Host -MaskInput "VCF Depot Token" 他のパスワード（vCenter、NSX、SDDC Manager など）はすべて Secrets Manager から自動的に解決されます。 deploy-vcf-and-edge の実行 Python 環境を作成し、単一の CLI コマンドでフェーズ 3 のパイプライン全体をエンドツーエンドで実行します（Linux）。 cd Phase_3_VCF9/python python -m venv .venv source .venv/bin/activate pip install -r requirements.txt python -m src.main deploy-vcf-and-edge \ --installer-host sddcm.<your-fqdn> \ --target-version 9.1.0 \ --nsx-manager-host nsx.<your-fqdn> \ --vcenter-host vc.<your-fqdn> \ --aws-profile your-aws-profile Windows の場合： cd Phase_3_VCF9\python python -m venv .venv .venv\Scripts\Activate.ps1 pip install -r requirements.txt python -m src.main deploy-vcf-and-edge ` --installer-host sddcm.<your-fqdn> ` --target-version 9.1.0 ` --nsx-manager-host nsx.<your-fqdn> ` --vcenter-host vc.<your-fqdn> ` --aws-profile your-aws-profile デバッグ用に各サブステップを個別に実行することも可能ですが、単一コマンドによるアプローチを 強く推奨 します。 検証と次のステップ deploy-vcf-and-edge が正常に返ったら、以下でエンドツーエンドの接続性を確認してください。 Route Server BGP ピアの確認 AWS コンソールで VPC > Route Servers > Peers に移動してください。両方の BGP ピアの BGP ステータスが “Up” になっているはずです。”学習済みルート” タブには NSX から発信された CIDR が表示されます（後で作成したセグメントも自動的にここに表示されます）。 テスト用 NSX セグメントの作成 NSX Manager（ https://nsx.<your-fqdn> ）にログインし、Tier-1 ゲートウェイにアタッチした新しいオーバーレイセグメントを作成します。 Networking > Segments > Add Segment に移動する セグメント名を test-segment とする 作成した Tier-1 ゲートウェイにセグメントをアタッチする サブネットを設定する（例：ゲートウェイ 172.16.1.1 の 172.16.1.0/24） このセグメントにテスト VM をデプロイし、IP アドレスを受け取ることを確認する オーバーレイからアンダーレイへの接続確認 NSX セグメント上のテスト VM から以下を実行します。 パブリックサブネット内のジャンプボックスに Ping する（デプロイ済みの場合） サービスアクセスサブネット内の EC2 インスタンスに Ping する セグメント CIDR（172.16.1.0/24）が VPC ルートテーブルに学習済みルートとして表示されることを確認する 3 つの確認がすべて成功すれば、NSX オーバーレイと AWS アンダーレイ間の動的なルート伝播が確立された、完全に動作する EVS 環境の構築完了です。 次のステップ： VMware HCX やその他の移行ツールを使用してオンプレミスからワークロードを移行する データセンターへのハイブリッド接続のために AWS Transit Gateway を設定する（フェーズ 1 でオプションとして作成しなかった場合） 補足ストレージとして Amazon FSx for NetApp ONTAP をセットアップする 運用監視のために AWS Systems Manager を統合する SDDC Manager 経由で追加のワークロードドメインをデプロイする トラブルシューティング よくある障害パターンと解決策を以下にまとめます。 フェーズ 1 および 2：AWS リソースエラー 対象リソースの AWS コンソールを確認してください。Terraform または boto3 のエラーテキストは通常、正しくプロビジョニングされなかった特定のリソース（AZ の誤り、サブネットの欠落、API コールのスロットリング）を指しています。 サービス制限を確認してください：EVS サービスクォータ、Dedicated Host の割り当て、VPC Route Server クォータ、EBS ボリューム制限。 ホストの実現がタイムアウトした場合（90 分超）、コンソールで EVS 環境のステータスを確認してください。FAILED 状態はキャパシティまたは設定の問題を示します。 フェーズ 3：デポの同期問題 Broadcom デポトークンが有効で有効期限が切れていないことを確認してください インストーラーアプライアンスが depot.broadcom.com へのアウトバウンドインターネットアクセス（ポート 443）を持つことを確認してください ダウンロードが止まった場合、自動化は指数バックオフで再試行し、5 回失敗後にエラーを報告します。その場合は download-all-product-binaries --wait で手動再試行できます フェーズ 3：Bringup の失敗 VCF Installer UI（ https://<sddcm_name>.<your-fqdn> ）はタスクごとの進捗と詳細なエラーメッセージを提供しており、API エラー本文よりも参考になります。 スタックトレースについてはインストーラーアプライアンスの /var/log/vmware/vcf/domainmanager/domainmanager.log を確認してください。 bringup が “VMwareProductVersion can not be null or empty” で失敗した場合、デポに必要なバイナリがキャッシュされていません。 prepare-depot を再実行して再試行してください。 フェーズ 3：Edge Cluster のデプロイ vSAN データストアに十分な空き容量がない場合、エッジノードのデプロイが失敗することがあります（各エッジ VM には約 200 GB が必要） BGP ピアリングの問題：エッジクラスター仕様の Route Server エンドポイント IP がフェーズ 1 の Terraform 出力と一致することを確認してください configure-routing が失敗した場合、クラスターが作成される前に両方のエッジノードが Success 状態に達していることを確認してください ヒント ：自動化の各アクションはべき等です。ステップが失敗した場合は、根本的な問題を修正して同じコマンドを安全に再実行できます。副作用は発生しません。 クリーンアップ 構築した環境を解体する場合は、以下の順序で実施してください。 EVS 内の仮想マシンを保持したい場合は、まず別の場所に移行してください。 AWS コンソールから EVS ホストを 1 台ずつ削除してください。 AWS コンソールから EVS 環境を削除してください。 フェーズ 1 を実行した元のワークステーションから Phase_1_Base_Infrastructure ディレクトリに移動し、 terraform destroy を実行してください。Terraform は既存の状態ファイルを使用してすべてのフェーズ 1 リソースを特定して削除します。 まとめ 本ウォークスルーでは、3 フェーズの自動化ツールキットを使って VMware Cloud Foundation 9.1 を Amazon EVS にデプロイしました。空の AWS アカウントから出発し、Terraform で前提条件となる AWS インフラストラクチャをすべてプロビジョニングし、AWS API 経由の Python CLI で EVS 環境とベアメタルホストをデプロイし、公式 VCF Python SDK を使って NSX Edge Cluster ルーティングを含む完全な VCF スタックを立ち上げました。 terraform apply から BGP ピアリングの確認まで、デプロイ全体でおよそ 3.5〜6 時間かかります。自動化により、作業は 3 つの CLI コマンドと ESXi 設定・OVA デプロイに必要な約 30 分の手作業のみに削減されます。 このアプローチの主な利点： Infrastructure as Code：すべてのリソースが Terraform または Python 自動化で定義されています デフォルトセキュア：すべての VCF パスワードが厳格な複雑性要件に従って生成され、AWS Secrets Manager に保存されます 安全な再実行：フェーズ 1 と 3 は完全にべき等であり、デバッグや復旧のためにどのステップも副作用なく安全に再実行できます SDK 駆動：フェーズ 3 は公式 VMware VCF Python SDK を使用し、手動による REST ペイロードの構築を排除します モジュラー設計：1 つのコマンドでパイプライン全体を実行するか、デバッグや部分的な再実行のために個別ステップを実行できます 開発環境のセットアップ、本番環境のデプロイ、顧客デモ用の再現可能なラボなど、あらゆるユースケースに対応できる堅牢な基盤として、バージョン管理・カスタマイズ・拡張が可能です。 著者について David Piet Amazon Web Services (AWS) のプリンシパルソリューションアーキテクトとして、VMware ベースのワークロードを持つエンタープライズのお客様が AWS へ移行し、モダナイズするための支援を担っています。2018 年にパートナーソリューションアーキテクトとして AWS に入社し、VMware Cloud on AWS を専門としてきました。以来、AWS 最大規模のエンタープライズ顧客を数多くサポートし、VMware ベースのワークロードのクラウド移行と最適化戦略を牽引してきました。長年にわたり、AWS での VMware ビジネスの成長とともに担当範囲を広げ、現在もお客様のモダナイゼーションジャーニーの支援に深く関わっています。ノースウェスタン大学で博士号を取得しており、応用数学とエンジニアリングを専門としています。AWS 入社前はシリコンバレーのストレージスタートアップでソフトウェアデベロッパーとして勤務していました。 翻訳はパートナーソリューションアーキテクト 豊田が担当しました。原文は こちら です。

AWS Summit Japan 2026（2026年6月25日〜26日、幕張メッセ）では、「AWS パートナーと実現する生成 AI」と題したPartner Breakout Sessionを4部構成でお届けしました。AWSの4つのAIビルディングブロックをテーマに、8組のAWSパートナーとお客様が独自視点でお客様の課題に挑んだ実践事例を共有しました。 本ブログでは、各セッションのハイライトと、全セッションを通して見えてきた「AIの価値を現場で実現するために本当に必要なこと」についてお伝えします。 セッション全体のアーキテクチャ概念 本セッションは、AWSの4つのAIビルディングブロックに沿って構成されています。そして重要なのは、この4つのブロックにわたり一貫したセキュリティ、ガバナンス、運用の仕組みが支えていることです。 AIビルディングブロック 対応パート　　 該当事例　　　　　 AI を活用したアプリケーション開発 Part 1 Kiro × 東邦ガス / エッジAI × KMバイオロジクス 基盤モデルの活用 Part 2 文字起こし × 青森放送 / 音声AI × 品川区 AI エージェント活用 Part 3 エージェント本番化 × ミルボン / 従量課金AI × 36flip AI 基盤とデータ活用 Part 4 エンタープライズAI × カラクリ / GraphRAG × 日本取引所     Part 1: 現場を変える AI ソリューションの実践 事例1: Kiro 導入で得られた開発プロセス改善効果と、AI 駆動開発に向けた組織課題 登壇: 東邦ガス情報システム 日沖裕介氏（デジタルソリューション部 主任）/ ソニービズネットワークス 濱田一成氏（開発本部 クラウド開発部 マネージャー） 東邦ガス情報システム様は、エネルギー契約者向け会員サイトの開発効率向上PoCに取り組みました。ソニービズネットワークスのKiro伴走支援のもと、AI駆動開発を組織に定着させる挑戦です。 ポイント : Kiroのspec駆動開発により、要件定義〜実装の一連のプロセスを大幅に効率化 単なるツール導入ではなく、組織全体のマインドセット変革が最大の課題だった パートナーの伴走支援が「ツールの使い方」ではなく「開発文化の変革」を支えた インサイト : AI駆動開発は個人のスキルではなく、チーム全体の協調と学習意欲が成果を左右する。技術的なハードルよりも「人がどう向き合うか」が鍵。   事例2: 現場の “気づき・判断・対応” を、人依存から “流れる業務” へ 登壇: KMバイオロジクス 田崎裕三氏（デジタルIT部）/ 富士ソフト 飯法師祐輔氏（組込/制御ビジネスユニット 営業統括部 九州営業部 リーダー） 製造業における属人化・現場依存・技術承継の課題に対し、後付け可能なエッジAIカメラとAWSのクラウド基盤、生成AIを融合したAI/IoTソリューションを展開。 ポイント : レガシーな機器でも後付けAIカメラでデータ取得を可能に – 異常検知だけでなく、過去データから次のアクションをナビゲーション Amazon Quickを用いた予兆保全にも活用可能 「気づき→判断→対応」の全フローを標準化し、ベテラン不在でも品質を維持 インサイト : 製造現場のAI化は最新設備だけの話ではない。「今ある環境を活かしながら、AIを”流れる業務”に変える」という現場起点の発想が重要。   Part 2: Amazon Bedrock で言葉の業務を変革する 事例3: 青森の放送局が報道現場で磨き上げた Amazon Bedrock を活用した文字起こしシステム 登壇: 青森放送 内山匠氏（デジタル報道室）/ ヘプタゴン 三浦一樹氏（クラウドソリューション部 クラウドアーキテクト） 青森県で2025年度平均個人視聴率13%を誇る『RAB ニュースレーダー』。放送だけでなくネット配信にも注力する中で、日々のインタビュー文字起こし作業を劇的に効率化するシステム「dahande」を開発しました。 ポイント : 現役報道記者自身が課題を感じ、パートナーと共にシステムを構築 Amazon Bedrock を活用し、方言や専門用語にも対応する高精度文字起こしを実現 「報道のスピード」に耐えうる実用性 — 使われなければ意味がないという現場の厳しい基準をクリア インサイト : 「使う人自身」が課題解決の主語になったとき、AIは初めて現場に根付く。記者とエンジニアが対等に対話したからこそ生まれた成果。   事例4: 「区民の問い合わせ、AI にどこまで任せる？」品川区 × SHIFT が挑む自治体音声 AI 実証 登壇: 品川区役所 西澤拓氏（企画経営部 DX戦略担当部長 CIO・CISO）/ SHIFT 寅野理司氏（AI・DX開発部 シニアクラウドアーキテクト） 戸籍・異動手続きの音声AI対応実証実験。Amazon ConnectとAmazon Bedrockを組み合わせ、RAG設計・セッション管理・有人窓口へのシームレスな接続を実装しました。 ポイント : 区民の属性や状況によって聞き返しの分岐が複雑に変わる業務に対し、業務マニュアルをAIネイティブに変換するRAG設計を実施 「AIに任せる業務 / 人が担う業務」の境界線を実証を通じて明確  自治体DXの現場視点（品川区）と技術アーキテクチャ視点（SHIFT）の両輪が重要 インサイト : AIの価値は「全てを自動化する」ことではない。「どこまで任せ、どこから人が担うか」を現場と技術者が一緒に線引きするプロセスこそが、信頼されるAI実装の基盤。   Part 3: 企業が今すぐ始める AI エージェント活用 事例5: AI エージェントを”検証”から”本番活用”へ — ミルボン様と進める、Amazon Bedrock 活用の実践 登壇: ナレッジコミュニケーション 奥沢　明氏 案件初期から動くモックアップで活用イメージを具体化し、Amazon Bedrockを活用したセキュアなAWSアーキテクチャでAIエージェントの本番活用を実現する実践を紹介。 ポイント : モックアップファースト — 初期段階から動くプロトタイプを提示し、お客様の「使いたい」を引き出す PoCで終わらせない「本番活用」への確実なステップ設計 Amazon Bedrockのマルチエージェントコラボレーションを活用 インサイト : AIエージェントを「検証」で終わらせず「本番」に進めるには、初期段階での”手触り感のある体験”が意思決定者の背中を押す。   事例6: 無駄な費用ゼロ！「使った分だけ」で始める企業向け生成 AI ソリューション 登壇: 36flip 谷口慶多氏 / KDDIアイレット 平野健介氏 従来の定額・ユーザー数課金型AIサービスの常識を覆す、アクティブ数連動型の企業向け生成AIソリューション。コストを最適化しながら、ビジネス現場の生産性を最大化する新しいモデルを提案。 ポイント : 「使った分だけ」の料金体系で、組織全体への展開時のコストの壁を解消 Amazon Bedrockをバックエンドに、スケーラブルで安全な基盤を構築 「全社導入したいがコストが見えない」という経営層の最大の懸念に正面から回答 インサイト : AI全社展開の最大の障壁は技術ではなく「コストの不透明さ」。ビジネスモデルのイノベーションがAI普及を加速させる。   Part 4: AI実装を支える AI 基盤とデータ活用 事例7: 現場で機能するエンタープライズ AI とは — Upstage・Karakuri の実践知 登壇: カラクリ 中山智文氏（CPO）/ Upstage AI 松下紘之氏（代表取締役） 日本語特化LLM、Document AI、エージェント型AIワークフローを組み合わせ、実際の業務環境で機能するAIの実装方法を解説。AWSとともに、インフラ・学習・推論・本番運用までの実践知を共有。 ポイント : 汎用LLMだけでは不十分 — 日本語特化モデル × Document AI × エージェントの組み合わせが現場品質を実現 AWS Trainiumを活用したコスト効率の高い学習基盤 「実験」から「実装」への移行に必要なインフラ設計の勘所 インサイト : エンタープライズAIは「一つのモデルで全て解決」ではない。複数の技術を組み合わせ、現場の業務フローに溶け込ませる設計力が問われる。   事例8: GraphRAG Toolkit (ナレッジグラフ) による暗黙知の形式知化 登壇: 日本取引所グループ 夏目卓哉氏（IT企画部 課長）/ 豆蔵 高田恵子氏（AIコンサルティング事業部 データ戦略グループ シニアコンサルタント） 日本取引所グループにおけるベテラン職員の「暗黙知」を、オントロジー技術を基盤としたナレッジグラフ（GraphRAG Toolkit）により「形式知化」した事例。 ポイント : 従来のRAGでは捉えきれない構造的な知識の関係性をナレッジグラフで表現 データ前処理・実行環境・ユーザー評価の3観点で取り組みを整理 ベテランの「なぜそう判断するか」のプロセスをAIが再現可能に インサイト : 暗黙知の形式知化は、テクノロジーだけでは完結しない。ベテラン本人が「言語化」に協力する意思と、それを引き出すファシリテーション力がプロジェクトの成否を分ける。   全セッションを通して感じたこと — AIの価値を実現する「人の力」 4部・8事例を通して、一つの共通点が浮かび上がりました。 AIの本当の意味での価値を実現するには、単なる技術やプロセスではなく、多くの人の意思、協調、現場力が不可欠だということです。 技術的に優れたAIモデルは日々進化しています。しかし、それを現場で価値に変えるのは、課題を自分ごととして捉え、部署を超えて協調し、「変えたい」という意思を持った人々です。それが文化となり、プロセス変革の推進力となり、AIによるビジネス価値を実現できるのではないでしょうか。   まとめ AWS Summit Japan 2026のPartner Breakout Sessionは、AWSパートナーがお客様と共に挑んだリアルな実践の場でした。PoCで終わらず、現場で使われ続けるAIを作るために必要なのは、最先端の技術だけではありません。 現場の人々の意思と協調 — それこそが、AIの価値を最大化する最も重要なファクターです。 AWS パートナーエコシステムは、お客様の AI ジャーニーをあらゆるフェーズで支援しています。本セッションで紹介された各パートナーへのお問い合わせは、 AWS パートナーファインダー からご確認いただけます。     本ブログは AWS Summit Japan 2026 の Partner Breakout Session「AWS パートナーと実現する生成 AI」の内容をもとに作成しました。 タグ: #AWSSummitJapan #GenerativeAI #AmazonBedrock #AIAgent #PartnerSolutions #Kiro #GraphRAG #EdgeAI          

オンプレミスの HPC 環境からの移行を進める研究チームは、クラウドへのデプロイの複雑さに悩まされることがよくあります。従来のアプローチでは、AWS のネットワーク、ストレージアーキテクチャ、Slurm の構成管理に関する深い専門知識が必要でした。一般的な手動デプロイでは、インフラのプロビジョニング、ネットワークトポロジの設計、スケジューラの構成、パフォーマンスチューニングに数週間を要します。プラットフォームエンジニアリングのリソースが限られている研究チームは、計算能力に対する差し迫ったニーズと、デプロイの技術的な障壁との間で板挟みになってしまいます。 本記事では、業界のベストプラクティスを組み込んだ AWS PCS クラスターを、Kiro CLI を使って自動的にデプロイ・構成する方法をご紹介します。インフラのプロビジョニング、モニタリングのセットアップ、コスト最適化を担いながら、研究チームが特定のワークロードに必要とする柔軟性を維持する「カスタムエージェント」の作成手順を順を追って解説します。 クラウドにおける HPC クラウドベースの HPC は、柔軟なコンピューティングアクセス、幅広いリソースの可用性、そして価値あるインフラの抽象化により、標準的な手法となっています。本記事では、AWS Parallel Computing Service (PCS) と Kiro CLI を活用して、このアプローチを実演します。 AWS PCS : AWS PCS は、自動構成・スケーリング・メンテナンスを備えたマネージドな Slurm スケジューラを提供することで、HPC のデプロイを簡素化します。本サービスはクラスターのライフサイクル管理を担う一方で、コンピューティングリソースとジョブスケジューリングポリシーに対するコントロールはお客様が維持できます。PCS は、共有ストレージ向けの Amazon Elastic File System やモニタリング向けの Amazon CloudWatch といった AWS サービスとネイティブに統合され、HPC のデプロイで通常必要となる統合作業を削減します。 Kiro CLI : Kiro CLI は、特定のユースケースに合わせた専門的なガイダンスを備えた カスタムエージェント を定義することで、非常に強力なものになります。ドメインの専門知識をエージェント定義に直接エンコードすることで、組織のベストプラクティスや要件を理解した専用の自動化を構築できます。例えば本記事では、HPC ワークロード向けの AWS Parallel Computing Service のベストプラクティス（最適なインスタンスの選択、ネットワーク構成、ストレージの最適化など）を組み込んだ PCS デプロイエージェントを作成します。このエージェントは確立されたデプロイパターンを活用することで、複雑なクラスターのプロビジョニングを効率化し、デプロイ時間と構成ミスのリスクの両方を削減します。汎用的な自動化とは異なり、このアプローチは実証済みの方法論を特定のインフラのニーズに適応させる、インテリジェントでコンテキストを理解した支援を提供します。 はじめに 自動化された PCS デプロイのアプローチを実装する前に、3 つの前提条件が必要です。 インストールガイド に従って Kiro CLI をインストールする pcs-kiro デモリポジトリ からデモコードをダウンロードする ローカルの AWS 認証情報があることを確認する。 aws sts get-caller-identity を実行して確認できます （オプション） MCP 構成ガイド に従って AWS Knowledge MCP Server を構成する エージェントを使う まず、エージェントを初期化します。Kiro で TODO リスト設定を有効にしておくとよいでしょう。これによりエージェントのより詳細なプランニングが可能になり、クラスターの作成を進める際にタスクのリストを作成し、ステップごとに処理を進めるようになります。 kiro settings chat.enableTodoList true 対話型の PCS デプロイエージェントを起動します。 kiro chat --agent pcs-interactive-agent ディスカバリーフェーズ ここで、エージェントにクラスターの作成を手伝ってもらいます。 User: I am new to PCS. Help me create my first cluster with best practices. （訳: PCS は初めてです。ベストプラクティスに沿って最初のクラスターを作成するのを手伝ってください。） エージェントはまずアクティブな AWS 認証情報を確認し、詳細が不明な場合はいくつかのディスカバリーのための質問を返します。また、既存の環境を調査し、ベストプラクティスに基づいた推奨事項を提示します。これは、既存の VPC やその他の AWS リソースをエージェントに使ってもらいたい場合に役立ちます。 ここで詳細を調整・指定でき、エージェントは最終的なサマリーを作成して、お客様の AWS アカウント内でインフラの作成を開始します。 インフラの作成 以下はインフラ作成プロセスの抜粋です。環境や要件によって、この出力は変わる可能性があります。 Agent: VPC Created:vpc-█████████████████ (10.3.0.0/16) - Public Subnet:subnet-████████████ (10.3.0.0/20) - ログインノード用 - Private Subnet:subnet-████████████ (10.3.32.0/20) - コンピュートノード用 - Internet Gateway:igw-████████████ - NAT Gateway:nat-████████████ (52.38.92.80) - Route Tables:Public (rtb-████████████), Private (rtb-01484185571aabba1) Security Groups Created: - Cluster SG:sg-████████████ (Slurm ポート 6817-6818) - SSH SG:sg-████████████ (SSH ポート 22) IAM Role Created:AWSPCS-scientific-cluster-role - Instance Profile:AWSPCS-scientific-cluster - Policies:AmazonSSMManagedInstanceCore + PCS registration Cluster Created:pcs_xfzpdypb7z (scientific-cluster) - Status:CREATING → エンドポイント取得中 - Size:SMALL (最大 100 ノード、1000 ジョブ) - Slurm Version:24.11 - Controller Endpoint:10.3.45.99:6817 Launch Templates Created: - Compute:lt-████████████ (c6i.xlarge) - Login:lt-████████████ (c6i.xlarge + SSH key) Compute Node Groups Created: - Login Group:pcs_ndgfaikhwl (パブリックサブネット内に 1 台の c6i.xlarge) - Compute Group:pcs_████████████ (プライベートサブネット内に 0〜10 台の c6i.xlarge) - AMI Used:ami-████████████ (Slurm 24.11) - Status:CREATING (3〜5 分かかります) Queue Created:pcs_bogst8bszr (scientific) - Status:CREATING → ACTIVE - Targets:コンピュートノードグループ (pcs_dficwpzin2) - Purpose:科学計算ワークロード インフラの作成が完了すると、エージェントは詳細を提示します。AWS リソースのデプロイが失敗する場合もあります。エージェントに与えられた指示には、そうした問題のトラブルシューティングを行い、処理を続行する前に修正するように記載されています。また、エージェントは /generated ディレクトリにクラスターのサマリーとドキュメントを作成し、何がどのように構築・構成されたかを正確に示します。 完了すると、エージェントはクラスターへの接続方法とテスト方法を示し、コストの見積もりも提示します。 このわずかなやり取りの中で、完全に機能するネットワーク、コントローラー、キュー、コンピュートノードとログインノード、適切なテンプレートとロールを備えた、相応に複雑なアーキテクチャを作成しました。これらすべてを、一般的なニーズとユースケースを定義するだけで実現できたのです。 図 1: Virtual Private Cloud (VPC) 内での AWS Parallel Computing Service (PCS) クラスターのデプロイを示すアーキテクチャ図。 この図では、VPC の外側に配置された PCS コントローラーが PCS キューに接続されています。VPC の内側には 2 つのサブネットがあります。パブリックサブネットには、静的な起動テンプレートを使用する 1 台の c6i.xlarge インスタンスを含むログインノードグループがあり、プライベートサブネットには、動的な起動テンプレートを使用する c6i.xlarge インスタンス（0〜10 台のキャパシティ）を含むコンピュートノードグループがあります。両方のノードグループにはロールの割り当てが含まれ、コンピュートインスタンスや起動テンプレートのシンボルなどの AWS サービスアイコンで表現されています。 これらすべてのプロセスは、ユーザーとのいくつかのやり取りを含めて約 30 分で完了し、すぐにログインしてジョブの実行を開始できます。このアーキテクチャは、共有ストレージや追加のコンピュートノードグループ・キューなどを含むように拡張できます。 推奨されるベストプラクティス エージェントへの指示は、直接的・具体的・明示的に行う 例えば、本記事のアーキテクチャではファイルシステムを要求しませんでしたが、FSx for Lustre 分散ファイルシステムのセットアップを併せて依頼することも簡単にできる可能性があります デプロイをモニタリングし、混乱しているようであればコマンドをキャンセルする 時折の失敗は許容する — エージェントは回復する傾向があります 特定のユースケースに合わせてエージェントの構成をカスタマイズする ワークロードのコンテキストと要件を包括的に提供する 既知の制限事項 エージェントは詳細を見失うことがある — 必要に応じて指示を再度伝えてください 手動での検証が必要 — 結果が要件に合致しているか確認してください まとめ AWS Parallel Computing Service (PCS) は、Slurm クラスターを大規模に運用する際の運用の複雑さを取り除く、フルマネージドな HPC サービスを研究チームに提供します。Kiro CLI のマルチエージェントアーキテクチャと組み合わせることで、チームは本番環境対応の HPC 環境を数週間ではなく数時間でデプロイできるようになります。このアプローチは、基盤となるインフラの管理にかかるオーバーヘッドなしに計算能力を必要とする研究組織にとって、特に価値があります。 それでは、よい構築を！（Happy Building!） 著者について Markus Adhiwiyogo Markus Adhiwiyogo は、Amazon EC2 インスタンスを担当するシニアプロダクトマーケティングマネージャーであり、AWS Graviton、AWS Inferentia、AWS Trainium を含む AWS カスタムシリコンに注力しています。 Kyle Bush Kyle Bush は、AWS のヘルスケア・ライフサイエンスチームでグローバルなヘルスケア ISV を支援するシニアソリューションアーキテクトです。Kyle は、お客様が最新のテクノロジーを活用してデジタルトランスフォーメーションを推進し、ヘルスケアの提供と成果を近代化できるよう支援することに情熱を注いでいます。 Charunethran Panchalam Govindarajan Charunethran Panchalam Govindarajan は、AWS のシニアプロダクトマーケティングマネージャーであり、ハイパフォーマンスコンピューティングと量子テクノロジーに注力しています。彼は幅広いテクノロジー領域で活躍してきましたが、特に R&D と製品開発の交差点に関心を持っています。Charunethran はスタンフォード大学で電気工学の修士号を取得しています。仕事以外では、スケッチや哲学的な会話を楽しんでいます。 Kareem Abdol-Hamid Kareem は、スタートアップ向けのシニアアクセラレーテッドコンピュートスペシャリストです。アクセラレーテッドコンピュートのスペシャリストとして、Kareem は生成 AI、ハイパフォーマンスコンピューティング、超大規模ワークロードに関する新たな課題に日々取り組んでいます。余暇にはピアノを演奏し、ビデオゲーム『ストリートファイター』で腕を競っています。 翻訳はソリューションアーキテクトの 山田航司 が担当しました。原文は こちら です。

2022年にスタートし、毎年全国の地域を巡ってきた「AWS デジタル社会実現ツアー」が今年で 5年目 を迎えます。2026年は 全国8都市（北海道・宮城・新潟・静岡・愛知・広島・愛媛・福岡）  を約2週間で巡り、最新のAI・クラウド技術と、地域の未来を動かすプログラムをお届けします。 本イベントでは、AIやクラウドの「今」と「これから」を一日で体感できる多彩なセッションをご用意しました。 いま注目のAIエージェント技術をデモを交え、わかりやすく解説。続いて、地域企業のAI/クラウド活用事例を当事者が語ります。社会課題に挑んだ学生コンテスト入賞者のプレゼンテーション、自治体・地銀・大学・AWSパートナーが地域のAI活用の未来を議論する産学官金パネルディスカッションも開催。さらに経済産業省「GENIAC PRIZE」による懸賞金企画の最新情報もお届けします。 開催日程・会場など 日程 県道 会場 申込リンク 8/18（火） 北海道 DO-BOX EAST アジェンダおよびお申し込みはこちら 8/19（水） 新潟 NINNO3 アジェンダおよびお申し込みはこちら 8/20（木） 静岡 M20 アジェンダおよびお申し込みはこちら 8/21（金） 愛知 中日ホール＆カンファレンス アジェンダおよびお申し込みはこちら 8/25（火） 広島 エディオンピースウイング広島 アジェンダおよびお申し込みはこちら 8/26（水） 愛媛 E:N BASE アジェンダおよびお申し込みはこちら 8/27（木） 福岡 Growth1 アジェンダおよびお申し込みはこちら 8/28（金） 宮城 せんだいメディアテーク アジェンダおよびお申し込みはこちら ※ 会場によって時間が異なりますのでご注意ください。 ※参加無料・事前登録制です。 こんな方におすすめ AI・クラウドの最新情報を効率よくキャッチアップしたい方 地域でのDX推進・AI導入に関心のある経営者・自治体関係者 AI活用の先行事例を知りたい方 地域の産学官金ネットワークを広げたい方 学生AIコンテストの成果に興味がある教育関係者   主催・共催 主催：アマゾンウェブサービスジャパン合同会社 共催：共同通信社、河北新報 後援・協力：広島県、愛媛県、仙台市、名古屋市、北海道新聞、 新潟日報、 静岡新聞、 中日新聞、 中国新聞、 愛媛新聞、 西日本新聞 皆さまのご参加を心よりお待ちしております。ふるってお申し込みください！  

2026 年 7 月 6 日に公開された “ Announcing support for VCF 9.0 and 9.1 on Amazon EVS ” を翻訳したものです。 VMware Cloud Foundation (VCF) 9.0 および 9.1 が Amazon Elastic VMware Service (EVS) で利用可能になり、VCF インストールを完全に制御できるようになったことをお知らせいたします。Amazon EVS における私たちの焦点は、お客様が現在お持ちのツール、運用プロセス、スキルを使用して、ニーズに合わせて VCF をデプロイおよび構成できる柔軟性を提供することです。 Amazon EVS での VCF 9 エクスペリエンス VCF 9.x では、AWS インフラストラクチャのプロビジョニングを VCF ソフトウェアから分離します。Amazon EVS は、ESX 9.x を実行する EC2 ベアメタルインスタンスをお客様の Amazon Virtual Private Cloud (VPC) にデプロイし、VCF デプロイメントのアンダーレイとして機能するプライベート VLAN に接続します。そこから、Broadcom の VCF Installer をダウンロードしてデプロイし、Broadcom のネイティブワークフローを使用して VCF インストールを完了します。 評価モードでの VCF 9.x のデプロイ VCF 9.x を有効化する一環として、Amazon EVS は VCF 評価モードをサポートするようになりました。ライセンスキーを事前に提供することなく、EVS 環境を作成して VCF のデプロイを開始できます。これにより、サブスクリプションを適用してワークロードの移行を開始する前に、環境を構築し、設計を検証し、実装をテストする余地が生まれます。評価モードを超えて使用する際には、適切な VCF サブスクリプションカバレッジを維持する責任はお客様にあります。 Solutions for EVS GitHub リポジトリ エンドツーエンドのデプロイをより簡単にするため、開始を支援するサンプル、テンプレート、Infrastructure as Code アーティファクトを含む新しい Solutions for EVS GitHub リポジトリ を公開します。今後、このリポジトリを拡張し、追加のリファレンスアーキテクチャ、新しいベアメタルインスタンスおよびストレージ構成、ネイティブ AWS サービス統合を含める予定です。AWS CloudFormation や HashiCorp Terraform などの Infrastructure as Code ツールを使用している場合、これらのアーティファクトを、AWS インフラストラクチャから稼働中の VCF 環境までの経路を自動化するための基盤として使用できます。 EVS コネクタを使用した VCF の接続 VCF がインストールされ、VCF 管理アプライアンスに到達可能になったら、2026 年 4 月に Windows Server ライセンス機能 で初めて導入した EVS コネクタ を使用して、VCF デプロイメントを Amazon EVS コントロールプレーンに接続します。コネクタは、AWS Secrets Manager に保存された認証情報を使用して、EVS から VCF 管理アプライアンスへの永続的で認証された接続です。この接続により、EVS はお客様のデプロイメントを継続的に把握し、VCF ソフトウェアの運用上に介在することなく、環境状態の監視、Windows ライセンスエンタイトルメントの有効化、ライセンス使用状況のレポートを可能にします。 クラウドへのファーストパス 多くのお客様にとって、Amazon EVS はクラウドへ移行する最も高速な方法の 1 つであり、特にデータセンター契約の満了やインフラストラクチャの更新サイクルといった時間的制約に直面している場合に有効です。 Aeroméxico のようなお客様は、最大のメリットは VMware ワークロードを AWS へいかに迅速かつ容易に移行できるかにあると語っています。オンプレミスと同じように VCF をデプロイ、構成、運用することで、ソース環境とデスティネーション環境のアーキテクチャ上の差異を最小限に抑え、大規模な移行を簡素化・加速できます。 速度と制御の組み合わせこそが、今回のリリースの本質です。Amazon EVS 上の VCF 9.x は、最新の VMware Cloud Foundation ソフトウェアを現在と同じ方法で実行できる能力を提供しながら、AWS グローバルインフラストラクチャのスケールと信頼性を兼ね備えています。組織で VMware を使用している場合、私たちは Amazon EVS が VMware ベースのワークロードを実行する世界最高の場所となることを目指しています。 Amazon EVS の詳細については、 製品詳細ページ および ユーザーガイド をご覧ください。 著者について Andy Reedy Andy Reedy は EC2 Commercial Applications のシニアプロダクトマネジメントマネージャーで、VMware、SAP、Red Hat OpenShift ワークロードに注力するチームを率いています。IT インフラストラクチャ、ネットワーキング、セキュリティ、クラウド戦略、エンタープライズソフトウェアにおいて 25 年以上の経験を持ち、お客様のビジネスクリティカルなアプリケーションの移行とモダナイゼーションを支援することに情熱を注いでいます。 Spiros Tsitsonis Spiros Tsitsonis は AWS のシニアテクニカルプロダクトマネージャーで、インフラストラクチャ移行と Amazon Elastic VMware Service に注力しています。以前は Amazon Elastic Container Service とサーバーレスの Fargate チームを管理しており、AWS サービスを使用してお客様がビジネス成果を達成できるよう支援することに情熱を注いでいます。休日は、旅行やさまざまな場所、人々、文化を体験することを楽しんでいます。 翻訳はソリューションアーキテクト齋藤が担当しました。原文は こちら です。

本記事は 2026 年 6 月 16 日 に公開された「 Modernize Amazon Redshift: RA3 to RG Migration best practices 」を翻訳したものです。 Amazon Redshift は、フルマネージドで AI を活用したクラウドデータウェアハウスです。数万のお客様がエクサバイト規模のデータを業界最高水準のコストパフォーマンスで分析しています。Amazon Redshift は Amazon SageMaker Unified Studio でレイクハウス全体にわたる SQL 分析を提供し、複数のソースからのデータを統合します。 Zero-ETL 統合により、ストリーミング、データベース、エンタープライズアプリケーションを接続して複雑なパイプラインを排除し、ほぼリアルタイムのインサイトを得られます。 2026 年 5 月 12 日、Amazon Redshift はプロビジョンドノードの新世代である Graviton ベースの RG インスタンス をリリースしました。RG インスタンスは、 RA3 インスタンスと比較して、データウェアハウスワークロードで最大 2.2 倍、データレイクワークロードで最大 2.4 倍高速で、vCPU あたりの価格は 30% 低くなっています。RG インスタンスは RA3 がサポートするすべてのデータレイクフォーマットをサポートし、 Amazon Redshift Spectrum の TB あたりのスキャン料金が不要になります。 本記事では、Amazon Redshift RA3 クラスターを Graviton ベースの RG インスタンス に移行する方法を説明します。Elastic Resize、Classic Resize、Snapshot/Restore の 3 つの移行戦略を比較し、スムーズな移行に向けた考慮事項とベストプラクティスを紹介します。また、RA3 から RG へのノードマッピングガイダンスも紹介します。 RG への移行対象 すべての RA3 のお客様に、コストパフォーマンスを最大化するため RG への移行を推奨します。RG は RA3 と比較して、コンピューティング集約型と I/O 集約型の両方のワークロードでパフォーマンスが向上するよう設計されており、ワークロードパターンを問わず性能向上が期待できます。Amazon Redshift Graviton RG インスタンスは前世代の RA3 インスタンスと機能パリティを維持しており、機能を失わず移行できます。 RG ノードタイプ RG インスタンスファミリーには現在 2 つのノードタイプがあります。次の表に RG インスタンスタイプ、ハードウェア仕様、対応する RA3 ノードタイプを示します。RA3 からの移行時のサイジング判断に活用してください。 ノードタイプ 構成 vCPU メモリ 最大ストレージ/ノード ノード範囲 ステータス RA3 相当 RG.xlarge マルチノード 4 32 GB 16 TB 2-32 GA (05/12/2026) RA3.xlplus と直接対応 RG.4xlarge マルチノードのみ 16 128 GB 128 TB 2-64 GA (05/12/2026) RA3.4xlarge と比較して vCPU とメモリが 1.33 倍 注意 : 今後、Amazon Redshift ワークロードに最適なコストパフォーマンスを提供するため、追加のインスタンスタイプのサポートを拡大する予定です。 インスタンスタイプの詳細については、 Amazon Redshift のドキュメント を参照してください。 RA3 から RG へのノードマッピング 現在のノードタイプ ノード範囲 推奨 RG タイプ 推奨 RG ノード数 RA3.xlplus 1-32 RG.xlarge 1:1 マッピング（同じノード数） RA3.4xlarge 2 RG.4xlarge RA3.4xl 2 ノードに対して RG.4xl 2 ノード RA3.4xlarge 3-64 RG.4xlarge RA3.4xl 4 ノードに対して RG 3 ノード（偶数に切り上げ） 注意 : これらは初期の推奨値です。ワークロードによっては、ターゲット RG ノード構成の調整が必要です。ターゲット構成を確定する前に、下位環境でワークロードをテストしてパフォーマンスを検証してください。本番ワークロード全体をテストするには、 Amazon Redshift Test Drive ユーティリティ も使用できます。 マッピングの考慮事項: RG ファミリー内では、RG.4xlarge 1 ノードは RG.xlarge 4 ノードに相当します。 RG ノードタイプの選択: Amazon Redshift クラスターのサイジングでは、少数の大きなノードと多数の小さなノードのどちらを使うかが重要な判断ポイントです。RG ノードタイプ間の主な差別化要因はローカル SSD キャッシュ容量です。大きなノードはノードあたりのローカルキャッシュが多く、マネージドストレージからのデータ読み込みが減り、I/O 集約型クエリの性能が向上します。 次のようなワークロードでは、大きなノードタイプを検討してください: 大量のディスクスピル – メモリを超える中間結果セットが生じる複雑なクエリ。 リーダーノード負荷の高い処理 – 多数の同時クライアント接続、多数の結合やサブクエリを含む複雑なクエリコンパイル、または負荷の大きい最終段階の集約処理。 大量の頻繁にアクセスされるデータ – ローカル SSD キャッシュの活用でマネージドストレージからの読み込みを抑えたいホットデータセット。 大きな結果セット – クライアントアプリケーションに大量のデータを返すクエリ。 頻繁なメタデータ操作 – カタログルックアップの多いワークロードや、多数の小バッチでの CURSOR ベースのフェッチ。 前提条件 本記事の手順には、以下が必要です。 RA3 ノードタイプで稼働中の Amazon Redshift クラスター。 リサイズ操作に必要な AWS Identity and Access Management (IAM) アクセス許可（ redshift:ResizeCluster 、 redshift:DescribeClusters ）。 AWS CLI のインストールと設定（CLI ベースの移行の場合）。 Classic Resize を使用する場合、10 時間以内の最新の手動スナップショット。 既存データに対するターゲット RG 構成の十分なストレージ容量。 移行方法 次の図は、3 つの移行アプローチを比較したものです。 1. Elastic Resize（推奨） Elastic Resize は、ターゲットの RG ノード構成が Elastic Resize のサポート範囲内にある場合に、ノードアップグレードの推奨方法です。ノードタイプの変更（例: RA3 から RG）やノードの追加・削除に使用できます。 Elastic Resize を実行すると、Amazon Redshift はまずソースクラスターのスナップショットを作成します。スナップショットの最新データを使用して新しいターゲットクラスターがプロビジョニングされ、バックグラウンドでデータが新しいクラスターに転送されます。この間、データは読み取り専用になります。リサイズが完了に近づくと、Amazon Redshift はエンドポイントを新しいクラスターに向けて更新し、ソースクラスターへのすべての接続を切断します。障害が発生しても、ほとんどの場合は手動介入なしに自動ロールバックされます。 利点 平均約 10〜15 分で完了します。最初の選択肢として推奨します。 リサイズ中もクラスターが読み取り専用で利用できるため、ダウンタイムが最小限です。 クラスターエンドポイントが変わらないため、接続文字列の変更が不要です。 オンデマンドで実行するか、メンテナンスウィンドウ中にスケジュールできます。 考慮事項 プロデューサークラスターでノードタイプを変更する Elastic Resize では、接続が新しいターゲットクラスターに切り替わる間、データ共有が利用できなくなります。 ターゲットノード構成に既存データ用の十分なストレージがあることを確認してください。 Elastic Resize で対応できないターゲット構成もあります。その場合は Classic Resize または Snapshot/Restore を検討してください。 Elastic Resize 操作は開始後にキャンセルできません。 データスライスは変更されません。データや CPU のスキューが発生する可能性があります。 Elastic Resize は AWS マネジメントコンソールまたは AWS CLI で開始できます。 コンソールでクラスターをリサイズする手順 AWS マネジメントコンソールにサインインします。 https://console.aws.amazon.com/redshiftv2/ で Amazon Redshift コンソールを開きます。 左側のナビゲーションメニューで Provisioned clusters を選択します。 リサイズするクラスターを選択します。 Actions で Resize を選択します。 Resize cluster ページが表示されます。 Resize cluster ページで、リサイズタイプとして Elastic resize (recommended) を選択します。 New configuration で、ノードタイプ（例: rg.4xlarge ）を選択します。 ノード数を入力します。 選択内容に応じて、 Resize now または Schedule resize を選択します。 AWS CLI でクラスターをリサイズする手順 # Initiate an Elastic Resize to upgrade from RA3 to RG node type aws redshift resize-cluster \ --cluster-identifier <my-RA3-cluster> \ # Source cluster ID --node-type rg.4xlarge \ # Target RG node type --number-of-nodes <#nodes> \ # Target node count --no-classic # false = Elastic Resize 2. Classic Resize Classic Resize は、クラスターサイズやノードタイプの変更が Elastic Resize でサポートされていない場合に推奨されます。シングルノードからマルチノードへの変換にも必要です。 Classic Resize を実行すると、Amazon Redshift はターゲットクラスターを作成し、バックアップとリストアでソースクラスターからデータとメタデータを移行します。データベーススキーマやユーザー設定を含むすべてのデータが正確に転送されます。ソースクラスターは最初に再起動され、数分間利用できなくなります。その後、クラスターは読み書き可能な状態になり、リサイズはバックグラウンドで続行されます。 Enhanced Classic Resize は 2 つのステージで構成されます: ステージ 1（クリティカルパス）: ソースクラスターからターゲットクラスターへのメタデータの移行。このステージ中、ソースクラスターは読み取り専用モードになります。通常、非常に短い時間です。その後、クラスターは読み取りと書き込みクエリで利用可能になります。KEY ディストリビューションスタイルのすべてのテーブルは一時的に EVEN ディストリビューションで保存され、ステージ 2 で KEY スタイルに再配分されます。 ステージ 2（オフクリティカルパス）: 以前のディストリビューションスタイルに従ったデータの再配分。バックグラウンドで実行されます。所要時間はデータ量、クラスターワークロード、ノードタイプによって異なります。 詳細については、「 Accelerate resizing of Amazon Redshift clusters with enhancements to classic resize 」を参照してください。 利点 すべてのターゲットノード構成をサポートします。 ソースクラスターを柔軟に再構成できます。 データスライスをノードあたりのデフォルトにリバランスし、ノード間で均等なデータ分散を実現します。 考慮事項 ソースクラスターのデータサイズが 2 PB 未満である必要があります。2 PB を超えるデータには Snapshot/Restore アプローチを使用してください。 開始前に 10 時間以内の手動スナップショットがあることを確認し、なければ新たに取得してください。 Classic Resize に使用されたスナップショットは、テーブルリストアやその他の目的には使用できません。 クラスターは Virtual Private Cloud (VPC) 内にある必要があります。 リサイズ中はクエリの完了に時間がかかる場合があります。Concurrency Scaling の有効化を検討してください。 Classic Resize の前に不要なテーブルを削除すると、データ分散が高速化されます。 Classic Resize は Elastic Resize よりも完了までに時間がかかります。 リサイズ操作をオフピーク時間帯またはメンテナンスウィンドウ中にスケジュールしてください。 Classic Resize はコンソールまたは次の AWS CLI コマンドで開始できます。 コンソールで Classic Resize を実行するには、前述のリサイズ手順で次のスクリーンショットのように Classic resize を選択します。 AWS CLI による Classic Resize # Initiate Classic Resize via AWS CLI aws redshift resize-cluster \ --cluster-identifier <my-ra3-cluster> \ # Source cluster ID --node-type rg.4xlarge \ # Target RG node type --number-of-nodes <#nodes> \ # Target node count --classic # true = Classic Resize プロビジョンドクラスターの Classic Resize（KEY ディストリビューションを含む）の進捗を監視するには、 SYS_RESTORE_STATE を使用します。変換中のテーブルの完了パーセンテージが表示されます。アクセスにはスーパーユーザー権限が必要です。 Elastic Resize と Classic Resize の比較 動作 Elastic Resize Classic Resize システムテーブル Elastic Resize はシステムログデータを保持します。 Classic Resize はシステムテーブルとデータを保持しません。 ノードタイプの変更 ノードタイプが変わらない場合、Elastic Resize はインプレースリサイズとなり、ほとんどのクエリは保持されます。新しいノードタイプを選択した場合、新しいクラスターが作成され、リサイズ完了時にクエリが切断されます。 新しいクラスターが作成されます。リサイズ中にクエリが切断されます。 セッションとクエリの保持 Elastic Resize は、ソースとターゲットのノードタイプが同じ場合、セッションとクエリを保持します。新しいノードタイプを選択した場合、クエリは切断されます。 Classic Resize はセッションとクエリを保持しません。クエリが切断され、パフォーマンスの低下が予想されます。使用量の少ない時間帯にリサイズを実行してください。 リサイズ操作のキャンセル Elastic Resize はキャンセルできません。 RG または RA3 クラスターへの Classic Resize はキャンセルできません。 3. Snapshot, Restore, Resize 移行中もほぼ常時書き込みアクセスが必要な場合や、既存クラスターに影響を与えず新しい RG セットアップを検証したい場合に使用します。 手順 Amazon Redshift コンソールで Provisioned clusters dashboard を選択し、ソースクラスターを選択して Actions から Create manual snapshot を選択します。スナップショット名を指定して Create snapshot を選択します。 スナップショットを選択します。 Restore from snapshot を選択します。 クラスター ID と構成（ターゲットクラスター）を指定します。 次の手順でターゲットクラスターにデータが存在することを確認します: 新しいエンドポイントを使用してターゲットクラスターに接続します。 主要なテーブルに対して SELECT COUNT(*) FROM <table_name> を実行し、ソースクラスターとカウントを比較します。 すべてのスキーマが存在することを確認します。 ユーザー権限が正しくリストアされたことを検証します。 スナップショット取得後にソースクラスターにデータを書き込んだ場合は、手動でターゲットクラスターにデータをコピーします。 アプリケーションの接続文字列を新しいクラスターエンドポイントに更新します。 利点 既存クラスターに影響を与えずに新しい RG セットアップを検証できます。 異なるリージョンやアベイラビリティーゾーンへのリストアが柔軟に行え、追加の災害復旧オプションを提供します。 クラスターが書き込み操作で利用できない時間を最小限に抑えます。 考慮事項 クラスターのセットアップとデータリストアは Elastic Resize より時間がかかることがあります。 スナップショット後にソースクラスターへ書き込まれたデータは、手動でターゲットにコピーが必要です。 新しいエンドポイントが作成されるため、接続文字列の変更が必要です。 エンドポイントを維持するには、ターゲットクラスターがソースクラスターと同じ名前になるように 両方のクラスターの名前を変更する ことを検討してください。 フォールバック 同じ移行アプローチでいつでも RA3 に戻せます。 移行時の DMS、Zero-ETL、データ共有に関する考慮事項 Amazon Redshift クラスターが AWS Database Migration Service (AWS DMS) のターゲット、Zero-ETL 統合のターゲット、またはデータ共有のプロデューサーとして使用されている場合、RA3 から RG へのリサイズ時に以下の点に留意してください。 AWS DMS の変更データキャプチャ (CDC) タスクはリサイズの影響を受けません。レプリケーションインスタンスは独立して動作し、クラスター復帰後に書き込みを再開します。タスクの再起動は不要です。 Zero-ETL テーブルはリサイズ中に一時的に利用できなくなり、再同期状態になります。再同期にかかる時間はデータ量に依存します。 svv_integration_table_state を使用して、すべてのテーブルが Synced に戻ったことを確認してください。詳細については、「 Zero-ETL considerations 」を参照してください。 プロデューサークラスターをリサイズすると、接続が新しいクラスターに転送される間、 データ共有 が一時的に利用できなくなります。通常、数分間です。この間、コンシューマークラスターは共有データにアクセスできません。リサイズ完了後、データ共有は再設定不要で自動的に再開します。リサイズ対象のプロデューサーに依存するコンシューマーワークロードには、短いメンテナンスウィンドウを計画してください。 Snapshot/Restore が DMS、Zero-ETL、データ共有に与える影響 Zero-ETL 統合は元のクラスターに紐づいています。リストア先は新しいクラスターとして扱われるため、レプリケーションは自動再開されません。リストア後、新しいクラスターを指す Zero-ETL 統合を再作成する必要があります。初回同期が実行され、データが最新の状態になります。 AWS DMS 接続はエンドポイントベースです。リストア先は新しいエンドポイントになるため、AWS DMS タスクは自動接続しません。リストア後、AWS DMS エンドポイント設定を新しいアドレスに更新し、タスクを再起動してください。 データ共有はクラスターの名前空間に紐づいています。リストア先は異なる名前空間になるため、既存のデータ共有は引き継がれません。プロデューサー側は、新しいデータ共有を作成してコンシューマーと再共有する必要があります。コンシューマー側は、プロデューサーが新しいクラスターから共有を再確立するまでアクセスできません。 移行のベストプラクティス 移行前に、データ共有のコンシューマー、Zero-ETL アプリケーション、BI/ETL パイプラインなど下流チームに通知してください。 本番環境への影響を軽減するため、メンテナンスウィンドウ中に移行をスケジュールしてください。 リサイズ開始前に手動スナップショットを取得し、ロールバックポイントとして確保してください。 本番環境を移行する前に、代表的なワークロードでターゲットの RG 構成をテストしてください。 完了後に下流のアプリケーションが正常に動作していることを確認してください。 クリーンアップ 不要な課金を防ぐため、テスト用の RG クラスターと移行テスト中に作成した手動スナップショットを削除してください。クラスター削除時はすべてのデータが完全に消去されます。テストクラスターのみを削除していることを確認してください。テストデータを保持する必要がある場合は、削除前に最終スナップショットの取得を検討してください。 まとめ 本記事では、Amazon Redshift RA3 インスタンスから Graviton ベースの RG インスタンスへのアップグレードに関する移行オプション、考慮事項、ベストプラクティスを説明しました。RG のパフォーマンス上のメリットの詳細については、 発表ブログ記事 を参照してください。 本記事のガイダンスを参考に、今すぐ Amazon Redshift RG インスタンス へのアップグレードを開始して、コストパフォーマンスの向上を活用してください。アーキテクチャのサポートや概念実証 (POC) の支援については、 AWS Support にお問い合わせください。 著者について Nita Shah Nita は AWS のシニアアナリティクススペシャリストソリューションアーキテクトで、ニューヨークを拠点としています。20 年以上にわたりエンタープライズデータプラットフォーム、データウェアハウジング、アナリティクスソリューションの構築に携わり、Amazon Redshift を専門としています。エンタープライズ規模の Well-Architected なアナリティクスおよび意思決定支援プラットフォームの設計・構築を支援しています。 Ankit Sahu Ankit は革新的なデータ製品とサービスの構築において 18 年以上の経験を持ちます。プロダクト戦略、Go-to-Market の実行、デジタルトランスフォーメーションなど多様な経験があります。現在は AWS のシニアプロダクトマネージャーとして、Amazon Redshift のビジョンと戦略を推進しています。 Vinayaka Gangadhar Vinayaka は Amazon Web Services（AWS）のアナリティクススペシャリストです。スケーラブルなデータプラットフォームの構築・トラブルシューティングや、AWS の分析サービスを活用した有意義なインサイトの導出を通じてお客様を支援しています。Amazon Redshift とAmazon OpenSearch に深い専門知識を持っています。複雑な分析課題に取り組んでいないときは、新しいテクノロジーの探求や家族との時間を楽しんでいます。 Ricardo Serafim Ricardo は AWS のシニアアナリティクススペシャリスト Solutions Architect です。 この記事は Kiro が翻訳を担当し、Solutions Architect の Kenji Hirai がレビューしました。

はじめに エムシーディースリー株式会社様（MCD3：以下同社）は、三菱商事グループの一員として、AI・デジタル技術を活用したオペレーティングモデルを構築することで顧客価値の最大化を目指し、社会課題の解決に取り組まれています。 同社では、建設業界向けの Vertical SaaS「 グリーンサイト 」「 ワークサイト 」や、流通・食品を取り扱う小売業界向けに特化した、マーケティングDXサービス「 cacicar（カシカル） 」など、複数の事業領域で産業DXを推進されています。三菱商事グループの持つ幅広い産業ネットワークと、AI・データサイエンスの専門性を掛け合わせ、各産業に特化したデジタルプロダクトを通じて顧客企業のオペレーション変革を実現されています。 同社では、プロダクトの急成長に伴い、開発生産性の抜本的な向上という課題への取り組みとして生成AIの活用にも注力されています。本ブログでは、2026年6月8日から10日の3日間にわたり実施された AI 駆動開発ライフサイクル（AI-Driven Development Life Cycle、略称 AI-DLC）Unicorn Gym について、その実施内容と成果を紹介いたします。 開発生産性向上への課題とこれまでの取り組み 同社のプロダクト群 同社が開発・運用するプロダクト群は多岐にわたります。 建設業界向けプロダクト グリーンサイト — 建設現場の労務安全書類をクラウドで一元管理するSaaS。元請け・協力会社間の書類やり取りをデジタル化し、建設業界の生産性向上と安全管理の高度化を支援。全国数万の建設現場で利用されている業界スタンダードのプラットフォーム。 ワークサイト — 建設現場の施工管理・工程管理を支援するSaaS。現場の進捗状況のリアルタイム共有、帳票作成・カスタマイズ、作業員の入退場管理など、現場業務のデジタル化を包括的にサポート。 流通・小売業界向けプロダクト cacicar（カシカル） — 食品を取り扱う小売業界向けに特化した、マーケティングDXに関わる多様な機能を有するクラウドサービスです。データ分析機能（cacicarBI）／1to1マーケティング機能（cacicarMA）／お客様向けアプリ（cacicarCommu）を提供。 直面していた課題 これらのプロダクトが成長し利用者が拡大する一方で、開発生産性の向上が不可欠でした。 主な課題 機能カスタマイズ要望の開発リードタイムが長い — 複数のお客様の要望を広く満たせるほど機能の柔軟性が高くない レガシーワークロードのモダナイゼーションが不十分 — グリーンサイトの基盤アプリケーションをコンテナ環境へ移行できていない 運用業務の属人化 — 一部業務で多くの関係者が手動対応しており、オペレーションミスが発生しやすい状況にあった 新規プロダクト開発への挑戦 — AIネイティブな新サービスプロダクトの構想があり、開発機会を求めていた こうした課題を解決し、生産性向上を実現するためには、従来の延長線上の改善ではなく、開発プロセスそのものを根本的に変革する新しいアプローチが必要でした。 AI-DLC：新しいアプローチ このような課題に対し、同社はAI-DLCを実践しました。AI-DLC は、コーディング支援にとどまらず、要件定義からリリースまでの開発プロセス全体に AI を深く組み込む開発手法です。AI-DLC の詳細については、 解説ブログ をご覧ください。 お客様に AI-DLC を体験いただくにあたり、AWS は「AI-DLC Unicorn Gym」という体験型プログラムを提案しました。これは、AI-DLC を組織の特徴やニーズに合わせてカスタマイズし、実際のプロダクト開発を通じてその効果を検証するプログラムです。 AI-DLC Unicorn Gym の実施と成果 実施概要 今回の AI-DLC Unicorn Gym では、同社から 7つの異なるチーム が参加し、それぞれが実際のプロダクトや業務課題に対して AWSのAIエージェントであるKiroを使ってAI-DLC の手法を適用しました。エンジニアだけでなく、ビジネス部門のメンバーも参加し、3日間で実際に動くプロダクトの開発に挑戦しました。 参加チームとテーマ チーム名 人数 取り組み内容 成果 グリーンサイトチーム 4名  業務の一部自動化ツール作成（手動オペレーション・属人化の解消）  マスターデータ自動取得、PDF→CSV変換、重複チェック、SQL自動生成を実装。属人化していたID採番ルールを明文化 グリーンサイト インフラチーム 3名  グリーンサイトの AWS 稼働環境のモダナイゼーション（最小構成での検証）  既存アプリのコンテナ化完了。AWS環境デプロイ・ブラウザ操作確認まで達成。ローカル環境ワンコマンド起動も完成 DataHub チーム 4名 エンジニアだけでなくビジネスサイドも気軽にグリーンサイトの環境を立ち上げ・削除できるワンコマンド構築ツールの開発  Docker Composeワンコマンド起動を実現。テーブル自動作成、ログイン・操作確認まで達成 CTO室チーム 5名 新プロダクト SaaS のフルスクラッチ開発（マルチテナント対応、ガントチャート、リアルタイム共同編集）  3日目だけで219コミット・20件超のPR。ガントチャート、リアルタイム共同編集、AI自然言語工程修正など高度機能を実装しデモ可能な状態に BD部チーム 5名 AIで業務を効率化する新プロダクト開発（過去案件のナレッジDB化＋ベクトル検索による類似案件検索・見積もり支援） 5ユニット完成・16PR作成。Next.js/PGVector/Bedrockフルスタックアプリ構築。App Runnerデプロイまで完了 cacicarチーム 3名 Amazon Personalizeを活用したリコメンドAPIの開発、および iPad 会員入会フォームWebアプリの開発 リコメンドAPIの設計・実装完了、入会フォームWebアプリをローカル動作確認まで完了。本番運用アーキテクチャ（DynamoDBキャッシュ方式）を確立 ワークサイトチーム 6名 新規機能の開発（お客様にてカスタマイズ可能となるよう機能の拡張）  エクセル取込→マッピング→プレビュー出力のUIモック完成。ユーザーストーリー整理・詳細設計完了 各チームのAI-DLC Unicorn Gym からの学び 最終日には成果発表会を開催し、各チームからAI-DLC Unicorn Gymを通じて得られた学びを共有いただきました。 AI-DLCの醍醐味である要件定義からAIに委ねる手法を取り入れたことで、「人間は判断・方向性決定・レビューに集中することができた。」という声や、「暗黙知がAIへのインプットを通じて明文化し、要件に落とし込むことができた。」というコメントをいただきました。 全チームが対面で集まり実施できたことで、AIの実装待ち時間を活用して仕様確認や議論ができること、リアルタイムでのフィードバックが可能なこと、複数部門のドメイン知識を即座に引き出せること、ユニット分割により2名以上が同時にユニットを並列実装し、3日間という短期間で商用レベルに近いアプリケーションを構築できることが大きな利点として挙げられました。 また各チームが、AIによる開発生産性を最大化するために、以下のような工夫をして活用されていたことも印象的でした。 HTMLモックで事前にUI合意を得て、共通仕様（ドメインモデル・API仕様）も最初に固めたことで翌日からの並列開発を可能にする 複数の案がある時は、それぞれのメリットとデメリットも一緒に出させることで、チーム内の意思決定を高速化させる 人間が軌道修正に介在する手間を減らすために、レビュー専用のAIを導入し、要件充足を自動チェックする仕組みを入れ込む 今後の展望 同社では、今回の AI-DLC Unicorn Gym の成果を踏まえ、以下の取り組みを進められる予定です。 1. 各チームの成果物のブラッシュアップと本番環境への適用 2. AI-DLC の他プロジェクトへの適用 3. AIの活用拡大による開発速度と品質の両立 まとめ エムシーディースリー株式会社様との AI-DLC Unicorn Gym は、実際のプロダクト開発・業務改善に取り組むという大規模な実践の場となりました。 特筆すべきは、単にAIでコードを生成するだけでなく、 要件定義からアーキテクチャ設計、実装、テスト、デプロイまでの開発ライフサイクル全体 でAIを活用し、従来数か月かかっていた開発を3日間で実現可能なレベルまで圧縮できることを実証した点です。 今回の取り組みについて、同社の本間 嗣崇様は、 「今回のAI-DLC Unicorn Gymでは、グリーンサイトやcacicarなど実際のプロダクト課題に7チームで同時に挑み、3日間でここまで形にできたことに正直驚いています。Kiroを中心としたAI-DLCという開発手法を体験する場を提供いただいたAWSの皆様に感謝します。”コードを書く”から”意図を伝える”へという開発体験のシフトは、私たちエンジニアの働き方を根本から変える可能性を感じました。この体験を社内で広げ、各プロダクトの現場へ着実に展開していくことが、次のステップだと捉えています。」 とコメントしています。 著者について エムシーディースリー株式会社 エンジニアリング部 チームリード グループマネージャー エンジニアリングマネージャー 本間嗣崇 新卒でSI会社へ入社し、一貫してシステム開発に携わる。 2019年より大手通信会社へ転職後も複数のBtoCシステム開発に従事。主に新規システム構築に強みを持つ。 その後、ソフトウェアエンジニアとして旧エムシーデジタル(現 MCD3)に入社​へ入社。 入社後は物流最適化、プロダクト開発、LLM を活用した SaaS システムの開発など多岐にわたって開発を推進。ビジネス検討から運用・問い合わせ窓口、また開発プロセスの最適化も行うフルスタックエンジニア 兼 エンジニアリングマネージャー。 アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 三宅穂波 主に商社業界、サービス業界のお客様に対して技術支援しています。好きなサービスはAmazon Quick、GlueなどのAnalyticsサービスです。