はじめに こんにちは、クラウドセキュリティグループの小林です。 普段は AWS を中心としたクラウド環境のセキュリティ運用と改善を担当しています。 本記事では、GuardDuty のアラートを全件目視で確認していた運用を、AWS Security Incident Response（以下 SIR）の導入と自作の Slack 連携でどのように変えたかを紹介します。 本記事の対象読者 GuardDuty のアラート対応に負担を感じている方 AWS Security Incident Response の導入を検討している方 インシデント対応の導線を Slack に統合したい方 背景 当社はマルチアカウントの AWS 環境を GuardDuty で監視しています。 SIR 導入前の運用は、アラートが発火するたびにマネジメントコンソールを開き、GuardDuty の検出内容・関連リソース・CloudTrail ログなどを確認し、実害のある検知なのか過検知なのかを毎回判断する運用でした。 アラート 1 件ごとの作業は短時間でも、アカウント数に比例して検出件数が増えるため、確認に使う時間は無視できない量になっていました。 特に 2026 年 5 月〜6 月、GitHub Actions に起因する検知アラートが目立つようになりました。 GitHub がホストするランナーの IP アドレスは多数の利用者で共有されており、他の利用者による悪用などを原因としてこの IP が GuardDuty の参照する脅威インテリジェンスに登録されると、同じ IP 帯から実行される正規の GitHub Actions の通信まで脅威由来として検知され、アラートが多発します。 このアラートへの対応が、SIR の導入を検討したきっかけになりました。 AWS Security Incident Response とは？ AWS Security Incident Response は、セキュリティイベントの検知から対応までを支援する AWS のマネージドサービスです。 SIR は GuardDuty の検出結果と、Security Hub 経由で連携したサードパーティー製品の検出結果を取り込み、自動でトリアージします。 過検知と判定されたものはアーカイブされ、緊急度の高いものだけがケースとして起票されます。 これにより、それまで人手で行っていた確認とアーカイブの作業の大部分をサービスに置き換えられます。 なお、一部の Finding タイプは自動トリアージの対象外です。 ケース化された検出結果は、分析から封じ込め、クローズまでのライフサイクルがケース上に記録され、対応状況を一元的に追跡できます。 また、AWS サポートが必要なケースについては、SIR エンジニア（セキュリティ脅威のトリアージ・調査・封じ込めを支援する AWS の専門エンジニア）から 15 分以内に初回応答があり、ケースクローズまで継続して調査の支援を受けられます。 例えば、アカウント乗っ取りのような明確なインシデントだけでなく、疑わしい検知が本物の侵害かどうかの調査や、GuardDuty のトリアージ設定・抑制ルールに関する問い合わせなども AWS サポートが必要なケースとして起票できます。 費用面では、エンタープライズサポート契約があれば SIR のサービス全体を追加費用なしで利用できます。 Slack 連携 当社はエンタープライズサポートを契約していたため、SIR は追加コストなしですぐに導入できました。 しかし、運用に載せると導線の問題が見えてきました。 SIR ケースの確認や操作にはマネジメントコンソールへのログインが必要なため、社内標準のコミュニケーションツールである Slack での会話とマネジメントコンソール上の記録を行き来する手間があり、ケースの変化に気づくのが遅れる懸念もありました。 そこで AWS 公式のサンプル実装（ sample-aws-security-incident-response-integrations ）を参考に、Slack との双方向連携を作成しました。 起票は Slack のスラッシュコマンドから行います。 /sir create を実行すると入力モーダルが開き、ケースタイプやタイトル、影響を受けるアカウントなどを入力してケースを作成できます。 説明欄には「何が起きたか」「現在の影響」などの定型見出しが初期表示されるため、埋めるだけで報告の体裁が整います。 起票は誰でもできる一方、ステータス変更や内容の編集といった影響の大きい操作は管理者に限定しており、変更時、誰が何のアクションを実行したか Slack 上に記録するようにしています。 起点が Slack か SIR かを問わず、ケースが作成されるとチャンネルに初報が投稿され、指定した個人やグループへメンションが送られます。 以後の更新やコメントの通知はすべて初報へのスレッド返信として集約しています。 対応中はスレッド内の発言や画像が SIR ケースに自動で記録され、SIR 側のコメントもスレッドに届くため、スレッドがそのまま作業記録になり、Slack から SIR へ転記する手間と記録漏れがなくなります。 複数のケースが動いているときは /sir list でオープン中のケースを一覧でき、一覧の各ケースに対して内容の編集やステータス変更も行えます。 ケースは対応完了まで Open のまま残り、クローズ時にもスレッドへ通知されます。 アーキテクチャと設計上の注意点 この連携は API Gateway、Lambda（4 関数）、EventBridge カスタムバス、DynamoDB に、Slack の認証情報などコードに含めたくない設定を保管する Secrets Manager を加えたサーバーレス構成で、Terraform で管理しています。 主要な流れは次の図のとおりです。 SIR のイベント通知機能はメールのみで、ケースの変化をイベントとして受け取る手段がありません。 そのため SIR から Slack への方向は、poller が SIR の API を定期的に呼び、DynamoDB に保存した前回のスナップショットと比較して差分を検知するポーリング構成になります。 ポーリング間隔は、未クローズのケースがある間は 1 分、なければ 5 分になるよう、poller が自身をトリガーする EventBridge ルールを実行のたびに書き換えて調整しています。 対応中の即時性と平常時の API 呼び出し削減を両立するためですが、それでも通知には最大 1〜5 分の遅延が残ります。 逆方向の Slack から SIR への経路では、コマンドやボタン操作への応答を 3 秒以内に返すという Slack の制約が存在するため、入口では即座に応答だけを返し、実処理は後段の Lambda へ非同期で委譲する構成となっています。 ただし、モーダルの入力エラーのように応答の内容そのものを返す場面は非同期にできないため、API Gateway のルートは同期・非同期の 2 本に分けています。 また、モーダルを開くための trigger_id も 3 秒で失効するため、EventBridge で 5 分ごとに Lambda を空起動してコールドスタートを避けています。 なお、リクエストの真正性は入口での Slack 署名の検証で確認しています。 双方向に同期させると、Slack からの変更を poller が SIR 側の変化として検知し、Slack へ通知し返すループが起こり得ます。 これは、Slack 起点の変更時に DynamoDB へ書き込むケース単位のフラグを poller が確認して通知をスキップする仕組みと、SIR へ書き込むコメントにタグを付けて同期対象から除外する仕組みで防いでいます。 導入後の効果 導入後は SIR の自動トリアージが機能し、多い月では過検知の 70% が自動アーカイブされていました。 その大半は、背景で挙げた GitHub Actions 起因の検知です。 導入のきっかけになったアラートを、人手を介さずに処理できるようになりました。 人が確認するのは、緊急度が高いと判定されてケース化されたアラートだけになり、その対応は Slack のスレッドの中で完結するため、対応漏れも起こりにくくなりました。 残っている課題と今後の対応 現時点で見えている課題は 2 点あります。 SIR の自動トリアージの対象外となる Finding タイプがあることです。対象外の検知は SIR を経由しないため、これまでどおり人が確認する必要があります。 自動アーカイブした履歴が SIR 側に残らないことです。何がいつ自動アーカイブされたのかを確認するには、CloudTrail のログを調べるしかないのが現状です。 今後は、この自動アーカイブ履歴を可視化する仕組みづくりに取り組む予定です。 SIR が過検知と判定したものでも社内の基準では調査が必要になるケースが考えられるため、SIR の判定を後から確認できる状態にしておきたいと考えています。 まとめ GuardDuty のアラートを全件目視する運用は、件数が増えると維持が難しくなります。そこで当社では、過検知の仕分けを SIR に任せて人が判断する対象を絞り、残ったケースの操作と通知を Slack に集約することで、本当に対応が必要なアラートに集中できる体制にしました。 エンタープライズサポート契約があれば SIR は追加費用なしで有効化できるので、まずは自動トリアージがどの程度の過検知を仕分けられるかを確かめてみてください。そのうえでマネジメントコンソール中心の導線に不便を感じたら、公式サンプルを土台に Slack 連携を検討することをおすすめします。 なお、アラート分析そのものについても、SOC AI Agent による自動化で、分析の高速化・属人化の解消・担当者の負荷軽減を進めています。詳細は「 アラート疲弊からの脱却へ ― SOC業務におけるAIエージェント活用の実践 」をご覧ください。 本記事が、同様の課題を抱えている方の参考になれば幸いです。 参考資料 AWS Security Incident Response ドキュメント sample-aws-security-incident-response-integrations (aws-samples)

この記事は 2026 年 7 月 27 日に公開され、2026 年 7 月 29 日に更新された AWS Security Blog「 AWS Shield Advanced is embracing the AWS WAF Anti-DDoS managed rule group: What changes and how to prepare 」を翻訳したものです。 2026 年 7 月 29 日 : AWS Firewall Manager の移行パスを明確にするため、この記事を更新しました。 アプリケーションレイヤーの分散型サービス拒否 (DDoS) 攻撃は、正規のトラフィックと非常によく似ているため、検出が困難です。現在、HTTP リクエストフラッドはウェブアプリケーションを標的とする最も一般的な攻撃ベクトルの 1 つであり、通常のユーザーアクティビティに紛れ込む、正規に見えるリクエストを使用します。 2025 年 6 月、AWS はアプリケーションレイヤー (L7) の DDoS 保護に特化して構築された AWS WAF Anti-DDoS マネージドルールグループの提供を開始しました 。AWS Shield Advanced は、これをアプリケーションレイヤー保護のデフォルトとして採用し、将来的には唯一の保護機能とします。2026 年 7 月 27 日から、 AWS Shield Advanced は対象となるウェブアクセスコントロールリスト (ウェブ ACL) に Anti-DDoS マネージドルールグループを Count モードで追加し始めます。既存の L7 自動緩和および WAF ルールと併用しても、トラフィックが中断されることはありません。この記事では、Anti-DDoS マネージドルールグループの詳細と、この変更がウェブ ACL に適用される時期について説明します。また、完了期日までのフェーズと実施する必要がある手順に加え、モニタリングとメトリクスがどのように変わるかについても解説します。 Anti-DDoS マネージドルールグループの機能 Anti-DDoS マネージドルールグループは、Shield Advanced の自動緩和がすでに提供している機能を基盤としています。トラフィックをプロファイリングし、アプリケーションの通常のトラフィックを学習して、数時間ではなく数分でベースラインを確立します。攻撃が始まると数秒以内に対応し、ヘルスチェックを設定する必要はありません。このルールグループでは、すでに使用している Block および Count アクションに Challenge アクションが追加されます。Challenge の判断は、検査した各リクエストの疑わしさのレベルを示す Anti-DDoS マネージドルール (AMR) ラベルに基づいて行われます。選択肢の 1 つであるサイレントブラウザチャレンジでは、訪問者のブラウザ上でバックグラウンド検証が実行され、インタースティシャルページは表示されません。そのため、自動化されたトラフィックを除外しながら、正規ユーザーの操作を中断することはありません。また、Challenge をサポートしていないワークロードのパスを除外し、代わりに Block による緩和を適用することもできます。感度は Low、Medium、High のいずれかに設定でき、Block と Challenge に対して個別に設定します。Block と Challenge は個別に調整できます。つまり、より多くの疑わしいトラフィックを検出するために Challenge の感度を High にしながら、正規のリクエストをドロップしないよう Block を Low に保つことができます。逆に設定して、より厳格な保護態勢にすることも可能です。 その他の利点は、コストと可視性に関するものです。 従来よりも少ないキャパシティで動作します。 このルールグループに必要なウェブ ACL キャパシティユニット (WCU) は 50 です。従来の保護機能で必要だった 150 WCU から削減されるため、他のルールで使用できるキャパシティが増えます。 AWS WAF の AWS マネジメントコンソールにダッシュボードが用意されています。 このダッシュボードはすでに利用可能で、進行中の DDoS イベント、マッチメトリクス、トラフィックの主な発生元となっている URI、地域、IP アドレスを確認できます。 検査するすべてのリクエストにラベルを付与します。 リクエストには、 event-detected 、段階的な疑わしさのレベル、特定のルールを示すラベルが付与されます。ルールグループだけでは対応できないロジックが必要な場合は、独自の AWS WAF ルールでこれらのラベルに対するマッチ条件を設定できます。 攻撃トラフィックに対する料金は発生しません。 緩和がアクティブな間、ブロックされた DDoS リクエストは月間リクエスト数から除外されます。この除外は、AWS WAF のリクエスト料金、Anti-DDoS マネージドルールグループのリクエスト料金、Shield Advanced のリクエスト料金に適用されます。 これらの機能を使用するために AWS Shield Advanced は必須ではありません。Shield Advanced をご利用のお客様は、このルールグループを AWS WAF に含まれる形で月間 500 億リクエストまで追加料金なしで利用できます。また、どのお客様でも個別に有効化できます。コストの詳細については、 AWS WAF の料金 を参照してください。 実装の詳細 Shield Advanced は、5 つのフェーズでアプリケーションレイヤー DDoS 保護をアップグレードします。以下の日付は AWS が自動的に対応を行う日付であり、お客様が対応を開始できる最も早い日付ではありません。2026 年 7 月 27 日にルールグループが Count モードでデプロイされた後は、10 月の自動アップグレードを待たずに、すぐに移行を開始できます。保護が中断する期間はありません。現在の自動緩和は、Anti-DDoS マネージドルールグループが引き継ぐまで、すべてのフェーズを通じて有効なままです。この引き継ぎは一度のオペレーションで行われるため、切り替え時間は発生せず、トラフィックフローの保護に空白期間は生じません。 フェーズ 1: Anti-DDoS マネージドルールグループを Count モードでデプロイ (2026 年 7 月 27 日 ～ 8 月 7 日に順次実施) AWS は、このロールアウトの対象となるすべてのウェブ ACL に Anti-DDoS マネージドルールグループを Count モードで追加します。対象となるのは、アプリケーションレイヤー自動緩和を使用しているリソースが少なくとも 1 つあり、Anti-DDoS ルールグループをまだ実行していない Shield Advanced のウェブ ACL です。この対象範囲は、より厳格な条件が適用される 10 月の自動アップグレード (フェーズ 3) の対象ウェブ ACL よりも広くなります。デプロイは 7 月 27 日から段階的に行われ、2026 年 8 月 7 日までに完了する予定です。そのため、ウェブ ACL によって更新日が異なる場合があります。既存の自動緩和が引き続き実行される一方で、ルールグループはリクエストを監視してラベルを付与するだけであり、リクエストに対するアクションは実行しないため、トラフィックへの影響はありません。評価期間中は、追加料金なしで DDoS イベント、メトリクス、AWS WAF ラベルを利用できます。 フェーズ 2: 無料評価期間 (2026 年 7 月 27 日 ～ 9 月 30 日) 既存の自動緩和と Anti-DDoS マネージドルールグループが並行して実行され、それぞれが独立して検出を行います。ルールグループが Count モードで動作する間も、自動緩和がリソースを引き続き保護します。両者の検出結果を比較するには、DDoSAttackRequests メトリクス、AWS WAF ラベル、Anti-DDoS ダッシュボードを使用します。この期間中は、フェーズ 1 の対象ウェブ ACL について、サブスクリプション料金、リクエストごとの料金、WCU 消費にかかる料金を含む、Anti-DDoS マネージドルールグループのすべての料金が免除されます。 フェーズ 3: 自動アップグレードを開始 (2026 年 10 月 1 日) 対象のウェブ ACL では、自動アップグレードによって既存の自動緩和設定が引き継がれます。ルールグループは現在の設定を継承するため、Block 設定の場合は Block モードで、Count 設定の場合は Count モードで、単一のアトミックなオペレーションで切り替わります。自動緩和を無効化するのと同時にルールグループが保護を引き継ぐため、一瞬たりとも保護が失われることはありません。これは切り替え時間を伴うカットオーバーではなく引き継ぎであり、リソースが保護されない期間はありません。 アップグレードを希望しない場合は、自動アップグレード日より前に AWS サポートに連絡することでオプトアウトできます。 フェーズ 4: ガイド付き移行 (2026 年 7 月 27 日 ～ 12 月 31 日に利用可能) 移行するために 10 月の自動アップグレードを待つ必要はありません。2026 年 7 月 27 日から 8 月 7 日までの間にルールグループが Count モードでデプロイされ次第、お客様のスケジュールに合わせて移行できます。これは、フェーズ 3 の自動アップグレードの対象にならないウェブ ACL、つまりモードが混在するウェブ ACL や、自動緩和が有効になっていないリソースを含むウェブ ACL で使用する移行パスです。この期間中はいつでも、AWS アカウントチームおよび AWS サポートと連携して移行を計画し、完了できます。対象のウェブ ACL は 10 月 1 日から自動的にアップグレードされるため (フェーズ 3)、ガイド付き移行は主に、自動アップグレードでは対応できないウェブ ACL を対象としています。 フェーズ 5: Shield Advanced のアプリケーションレイヤー自動緩和を終了 (2027 年 1 月 1 日) 2027 年 1 月 1 日をもって、Shield Advanced のアプリケーションレイヤー自動緩和機能は利用できなくなります。Anti-DDoS マネージドルールグループに移行していないリソースでは、アプリケーションレイヤー DDoS の自動緩和が失われます。 機能 Shield Advanced のアプリケーションレイヤー自動緩和 Anti-DDoS マネージドルールグループ (AWSManagedRulesAntiDDoSRuleSet) 機能の種類 Shield Advanced 自動緩和 AWS WAF マネージドルールグループ 検出と緩和の速度 ベースライン期間が必要で、緩和の開始時間はイベントごとに異なる 強化された検出と、より迅速な緩和 設定スコープ リソース単位 (Shield API) ウェブ ACL 単位 (AWS WAF API) 緩和アクション Count、Block Count、Block、Challenge 感度の制御 なし Block と Challenge の両方に対して Low、Medium、High 非 HTML パスの処理 該当なし URI 正規表現による Challenge 除外 WCU 消費量 150 WCU 50 WCU ヘルスチェック 必須 ( Amazon Route 53 のヘルスベース検出) 不要。トラフィックを自動的にプロファイリング 利用可能なサービス Shield Advanced のみ AWS WAF および Shield Advanced ( 料金 を参照) オブザーバビリティ 既存の自動緩和と Anti-DDoS マネージドルールグループは、それぞれ異なる Amazon CloudWatch 名前空間とメトリクス構造を使用します。このルールグループでは、3 つの階層 (ティア) でオブザーバビリティを提供します。ティア 1 では攻撃が発生しているかどうかを確認でき、ティア 2 ではフラグが付けられたリクエストとその理由を確認でき、ティア 3 ではそれらのリクエストに対して実行されたアクションを確認できます。最初から 3 つすべてを使用する必要はありません。多くのお客様のチームでは、まずティア 1 で検出が機能していることを確認し、その後、調整を進めながら他のティアを追加します。 ティア 1: イベント検出アラーム それぞれ異なる名前空間を使用する 2 つの CloudWatch メトリクスによって、DDoS イベントを検出できます。 DDoSDetected (Shield) DDoSAttackRequests (Anti-DDoS マネージドルールグループ) 名前空間 AWS/DDoSProtection AWS/WAFV2 Shield Advanced が必要 はい いいえ スコープ L3、L4、L7 のイベント L7 イベントのみ イベント中の値 バイナリ (0 または 1) 観測されたリクエスト数 イベント外の値 1 日 1 回報告 (メトリクスを有効な状態に維持) なし (データポイントなし) ディメンション ResourceArn Resource、ResourceType 既存のアラームへの影響: アプリケーションレイヤー自動緩和機能の終了後も、DDoSDetected はインフラストラクチャレイヤーであるレイヤー 3 およびレイヤー 4 のイベントに対して発報します。そのため、既存のネットワークレイヤーおよびトランスポートレイヤーのアラームは引き続き有効です。すべてのメトリクスについては、 AWS Shield Advanced メトリクス を参照してください。 DDoSAttackRequests は、Anti-DDoS マネージドルールグループにおけるアプリケーションレイヤーのイベント検出用メトリクスです。すべてのイベントを検出するには Sum >= 1 でアラームを設定します。重大度に基づくアラートを行う場合は、ボリュームのしきい値 (例えば、1 分あたり 10,000 リクエスト超) を設定します。 評価期間中は両方のメトリクスが独立して発報するため、アプリケーションレイヤーのアラームを移行する前に、検出の同等性を検証できます。 アクティブな DDoS イベントがない場合、DDoSAttackRequests はデータが存在しない状態になるため、このメトリクスのアラームでは treat-missing-data を missing または notBreaching に設定してください。 ティア 2: カスタムモニタリング用の検出ラベル Anti-DDoS マネージドルールグループが評価するすべてのリクエストにはラベルが付与されます。ティア 1 では攻撃が始まったことを確認できるのに対し、ティア 2 では疑わしいと判断されたリクエストと、ルールグループによる判断の確信度を確認できます。これらのラベルは、AWS/WAFV2 名前空間の AWS WAF メトリクス (AllowedRequests、BlockedRequests、CountRuleMatch) として公開されます。各メトリクスは、 awswaf:managed:aws:anti-ddos: 名前空間の LabelName および LabelNamespace ディメンションを持ちます。 event-detected – 検出された DDoS イベント中に観測されたリクエスト ddos-request – 攻撃の一部として識別されたリクエスト low-suspicion-ddos-request 、 medium-suspicion-ddos-request 、 high-suspicion-ddos-request – 段階的な疑わしさのレベル challengeable-request – ブラウザチャレンジの対象になりうるリクエスト CloudWatch ダッシュボードに疑わしさのレベルの傾向をグラフ表示すると、攻撃が拡大する様子を確認できます。独自の AWS WAF ルールでラベルに対するマッチ条件を設定することも、特定のイベントを事後に把握する必要がある場合に、 CloudWatch Logs Insights または Amazon Athena を使用して AWS WAF ログを詳しく調査することもできます。 ティア 3: 緩和アクションのメトリクス ティア 2 ではルールグループがフラグを付けた対象を確認できるのに対し、ティア 3 ではイベント中にそれらのリクエストに対して実行したアクションを確認できます。これらのメトリクスは ChallengeRequests、BlockedRequests、CountRuleMatch として確認でき、それぞれ、生成元のルールラベルごとに区分されます。 ChallengeAllDuringEvent – アクティブなイベント中にチャレンジされたリクエスト ChallengeDDoSRequests – 疑わしさのレベルに基づいてチャレンジされた、DDoS の疑いがあるリクエスト DDoSRequests – ブロックされた (Count モードでカウントされた) リクエスト 進行中のイベントでこれらを監視し、緩和が攻撃に対応できているかを確認してください。ブロックするリクエストよりもはるかに多くのリクエストにチャレンジしている場合、設定が慎重すぎる可能性があります。数値を信頼できるようになった後で、感度レベルを引き上げることができます。 オブザーバビリティのまとめ ティア 自動緩和 Anti-DDoS マネージドルールグループ イベントアラーム AWS/DDoSProtection の DDoSDetected (バイナリ、L3/L4/L7) AWS/WAFV2 の DDoSAttackRequests (リクエスト数、L7) 検出ラベル なし event-detected、ddos-request、疑わしさのレベル、challengeable-request 緩和アクション 表示不可 (Shield が管理するルールグループのメトリクスは公開されない) ChallengeAllDuringEvent、ChallengeDDoSRequests、DDoSRequests ダッシュボード Shield コンソールのイベント履歴 Shield コンソール、および AWS WAF コンソールの Anti-DDoS ダッシュボード 履歴分析 Shield のイベント履歴のみ AWS WAF ログ (CloudWatch Logs、 Amazon Simple Storage Service (Amazon S3) 、 Amazon Data Firehose ) 請求 Shield Advanced サブスクリプションには、組織全体について支払いアカウントレベルで集計される、1 か月あたり最大 500 億リクエスト分の Anti-DDoS マネージドルールグループの利用が含まれています。ほとんどのお客様にとって、この上限は通常のトラフィック量を大きく上回るため、非常に大規模なトラフィックを処理している場合を除き、この項目が請求に現れることはありません。正確な料金については、 AWS WAF の料金 および Shield Advanced の料金 を参照してください。 Anti-DDoS マネージドルールグループがアクティブに緩和を行っている間は、DDoS トラフィックに対する料金は発生しません。アクティブな緩和とは、Count モードではなく、Block または Challenge モードで動作している状態を指します。この措置は、AWS WAF のリクエスト料金、Anti-DDoS マネージドルールグループのリクエスト料金、Shield Advanced のリクエスト料金に適用されます。評価期間を過ぎてもルールグループを Count モードのままにしておくと、保護が得られないまま、請求免除も受けられなくなります。そのため、検証に必要な期間を超えて Count モードを継続することは避けてください。 評価期間 (2026 年 7 月 27 日 ～ 9 月 30 日) 中は、AWS が自動的に登録した対象ウェブ ACL について、Count モードで設定されている場合も含め、リクエストごとの料金や WCU 消費にかかる料金は発生しません。 Anti-DDoS マネージドルールグループはウェブ ACL レベルで動作するため、ウェブ ACL に関連付けられているすべてのリソースが同じ保護を共有します。単一のリソースがコスト全体を占めていると判断する前に、各ウェブ ACL の背後にあるリソースがどれくらいあるかを確認してください。20 個のリソースを保護するウェブ ACL と 2 個のリソースを保護するウェブ ACL では請求額が異なります。まずこの数を確認し、各ウェブ ACL が保護するワークロードを把握してください。 お客様自身でウェブ ACL に Anti-DDoS マネージドルールグループを追加することはアップグレードパスの一部ではないため、有効化した時点から標準料金が適用されます。ロールアウト前からルールグループを実行していたリソースについても同様です。無料評価を利用するには、ルールグループを事前に追加せず、自動ロールアウトがウェブ ACL に適用されるのを待ってください。お客様自身で追加してもペナルティはありませんが、そのウェブ ACL では料金免除を受けられません。 Infrastructure as Code の更新 AWS CloudFormation 、 AWS Cloud Development Kit (AWS CDK) 、Terraform、またはその他の Infrastructure as Code (IaC) でウェブ ACL を管理している場合、自動アップグレードによって、テンプレートの外部からインフラストラクチャ設定が変更されます。コードは引き続き信頼できる唯一の情報源であるため、2 つの作業が必要です。まず、保護を宣言する場所を変更します。現在、アプリケーションレイヤー自動緩和は Shield API ( EnableApplicationLayerAutomaticResponse ) を通じて有効化し、保護対象リソースごとに設定します。一方、Anti-DDoS マネージドルールグループでは、設定スコープはリソース単位ではなくウェブ ACL 単位となり、AWS WAF API ( CreateWebACL および UpdateWebACL ) を通じて、ウェブ ACL 内のマネージドルールグループステートメントとして設定します。IaC では、Shield の自動レスポンスブロック (例えば Terraform の aws_shield_application_layer_automatic_response ) を削除し、次のセクションで示す WAF マネージドルールグループステートメントを追加します。次に、次回のデプロイ前に、アップグレードされたウェブ ACL をツールに取り込みます。これを行わないと、パイプラインが変更を元に戻そうとします。 Terraform、CloudFormation、AWS CDK の完全なステートメントと、自動アップグレード後に状態を同期する方法 ( terraform plan 、CloudFormation のドリフト検出、 cdk diff ) については、 iac-webacl-examples ヘルパー を参照してください。 AWS Firewall Manager ポリシーの更新 現在 AWS Firewall Manager で Shield Advanced ポリシー を実行している場合、作業を開始する前に Automatic application layer DDoS mitigation (アプリケーションレイヤー DDoS の自動緩和) 設定を確認してください。この設定によって、本セクションのどの部分が該当するかが決まります。設定が Ignore (無視) または Disable (無効) の場合、そのポリシーはこの緩和を一切管理していません。リソースに適用されている緩和は、リソース自体または Shield を通じて有効化されたものであり、無効化する際もそれらの同じ場所で行う必要があります。 Shield Advanced ポリシーの設定が Enable (有効) の場合は、まず AWS WAF Firewall Manager ポリシーを追加するか既存のポリシーを再利用し、そのポリシーに Anti-DDoS マネージドルールグループを含めます。そのうえで、Shield Advanced ポリシーが対象としているものと同じアカウントおよびリソースを、そのポリシーのスコープに設定する必要があります。 移行プロセス全体を通じて、Shield Advanced ポリシーはそのまま維持してください。アカウントやリソースをスコープから削除したり、ポリシーを削除したりしないでください。Firewall Manager は、スコープから外れた対象について、自身が作成した Shield Advanced の保護を解除してしまいます。これにより、置き換えようとしているアプリケーションレイヤーの緩和に加えて、L3 および L4 の保護も終了します。代わりに、設定変更によって従来の緩和を終了します。新しいルールグループが有効になり、2 つの保護機能を比較した後、現在 Enable (有効) になっている Shield Advanced ポリシーの Automatic application layer DDoS mitigation (アプリケーションレイヤー DDoS の自動緩和) を Disable (無効) に設定します。 AWS WAF Firewall Manager ポリシーの設定 この変更は、コンソールまたはコードで実施できます。Firewall Manager ポリシーをコードで管理している場合は、コンソールで編集しないでください。テンプレートに新しい AWS WAF ポリシーを追加するか、既存のポリシーを更新して Anti-DDoS マネージドルールグループを含め、後述の「 IaC を使用する Firewall Manager ポリシー 」の手順に従ってデプロイします。それ以外の場合は、コンソールを使用します。 コンソールでは、 AWS WAF 用の AWS Firewall Manager ポリシーの作成 の手順に従ってポリシーを作成し、 Edit policy rules (ポリシールールの編集) ページに移動します。そこでは AWS AntiDDoS Protection for Layer 7 attacks ( AWSManagedRulesAntiDDoSRuleSet ) と表示される Anti-DDoS ルールグループを、 First rule groups (最初のルールグループ) の新しいルールグループとして追加します。これにより、他のマネージドルールグループより先に評価されます。ただし、既知の安全なトラフィックを迅速に処理するために使用している許可カスタムルールがある場合は、そのルールより後に配置します。 CloudFront ディストリビューションを保護する場合は、Global ポリシーでこの変更を行い、リージョンリソースについては各 AWS リージョンのポリシーで同じ操作を行います。ポリシーを保存すると、Firewall Manager がスコープ内のアカウントに変更をロールアウトします。これには数分かかる場合があります。 追加後、次のスクリーンショットのように、ルールグループがポリシーの最初のルールグループとして表示されます。 図 1: AntiDDoS が有効になっている状態 IaC を使用する Firewall Manager ポリシー Firewall Manager ポリシーをコードで管理している場合は、コンソールではなくテンプレートで変更します。Anti-DDoS マネージドルールグループは、AWS WAF ポリシーの ManagedServiceData に追加します。これは JSON 文字列として渡される WAFV2 ポリシー定義です。早い段階で評価されるよう、最初のルールグループに追加します。CloudFormation、Terraform、AWS CDK の例を含む ManagedServiceData JSON については、 firewall-manager-examples ヘルパー を参照してください。 どちらの方法を取る場合でも、移行中にアプリケーションレイヤーの保護を失うリソースがないよう、既存の Shield Advanced ポリシーが対象としているものと同じアカウントおよびリソースをポリシーのスコープに設定します。 開始方法 2026 年 7 月 27 日から 8 月 7 日までの間に、AWS は、アプリケーションレイヤー自動緩和を使用しているリソースを含み、Anti-DDoS ルールグループをまだ使用していない Shield Advanced のウェブ ACL に、Anti-DDoS マネージドルールグループを Count モードで追加します。ウェブ ACL に追加された後は、10 月の自動アップグレードを待たずにルールグループを評価し、準備が整い次第移行できます。 AWS WAF コンソール で Anti-DDoS ダッシュボードを確認します。 ダッシュボードには、リアルタイムの DDoS イベント、マッチメトリクス、トラフィックの主な発生元が表示されます。 イベント検出を並べて比較します。 Count モードでは、両方のシステムが独立して検出を行います。リソースにおける検出の同等性を検証するため、AWS/DDoSProtection の DDoSDetected メトリクスと AWS/WAFV2 の DDoSAttackRequests を並べて確認します。AWS Samples リポジトリから CloudWatch 比較ダッシュボード をデプロイすると、両方のシステムを 1 つのダッシュボードで確認できます。 AWS WAF ラベルを調査します。 AWS WAF ログを有効にし、 awswaf:managed:aws:anti-ddos: 名前空間のラベルをクエリします。疑わしさのレベル (low-suspicion-ddos-request、medium-suspicion-ddos-request、high-suspicion-ddos-request) と、event-detected、challengeable-request を確認し、検出されたイベントをリクエスト単位で可視化します。 Block アクションの感度は Low から開始します。 評価中は感度を Low にすることで、誤検知のリスクを最小限に抑えられます。Anti-DDoS ダッシュボードと AWS WAF ラベルのデータから確信を得られるようになったら、感度を引き上げます。 設定を計画します。 感度レベル、非 HTML パスに対する URI の除外設定、ウェブ ACL 内の優先順位を確認します。Anti-DDoS マネージドルールグループはウェブ ACL 内で最も高い優先順位に配置するか、Allow アクションを設定したカスタムルールがある場合は、その直後に配置します。 IaC テンプレートを同期します。 自動アップグレードによってウェブ ACL に Anti-DDoS マネージドルールグループが追加された後、次回のデプロイ前に、現在の状態を IaC ツールに取り込みます (Terraform refresh、CloudFormation のドリフト検出、AWS CDK import)。 まとめ Anti-DDoS マネージドルールグループは、数時間かけてベースラインを確立していた従来の自動緩和を基盤としながら、数分以内にトラフィックをプロファイリングし、数秒以内に緩和を行います。また、実行している処理を詳細に可視化できます。評価期間は、何かが変更される前に、お客様自身のトラフィックで両方のシステムが動作する様子を確認できるように設けられています。最初の数週間は Count モードで、新しい検出が現在確認している結果と一致することを検証してください。その後、アラームを移行し、適切と判断した感度レベルを選択します。複数のリソースにまたがってウェブ ACL を使用している場合や、AWS Firewall Manager でルールを管理している場合は、後から設定を元に戻す必要が生じないよう、作業を開始する前に AWS サポートに連絡してください。Shield Advanced のアプリケーションレイヤー自動緩和機能は 2027 年 1 月 1 日に終了します。この機能に依存しているリソースは、それまでにすべて移行する必要があります。 リソース アプリケーションレイヤー (L7) DDoS 保護のドキュメント Introducing the AWS WAF Application Layer DDoS Protection AWS Shield Advanced メトリクス 移行ヘルパーと CloudWatch 比較ダッシュボード AWS WAF の料金 AWS Shield Advanced の料金 著者について Eitav Arditti Eitav は AWS のシニアソリューションアーキテクトであり、テクノロジー業界で 15 年を超える経験を持つテクノロジーリーダーです。エッジコンピューティング、サーバーレス、プラットフォームエンジニアリングを専門とし、エンジニアリングチームと連携して、CloudFront と AWS WAF を使用した、安全でグローバルにスケーラブルなアーキテクチャを設計しています。現在は、グローバルなコンテンツ配信からエッジセキュリティまで、インターネット規模のシステムに注力しています。 Andrew Chen Andrew は、AWS で DDoS 保護を担当するシニアプロダクトマネージャーです。AWS Shield 製品群を統括し、AWS インフラストラクチャとお客様の双方を、ボリューム型およびネットワークレイヤーの脅威から保護する支援を行っています。Andrew はセキュリティチームやネットワーキングチームと緊密に連携し、インターネットの安全性強化に取り組んでいます。 Justin Kurpius Justin は、米国イリノイ州シカゴを拠点とする AWS のセキュリティ Go-to-Market スペシャリストです。Amazon CloudFront、AWS WAF、AWS Shield、AWS Firewall Manager など、AWS のエッジおよびセキュリティサービスを担当し、スケーラブルで回復力のあるウェブアプリケーション防御をお客様が設計できるよう支援しています。Justin は、収益化戦略、ISV パートナーシップ、フィールドイネーブルメントを横断して活動し、AWS エッジセキュリティポートフォリオの導入促進に取り組んでいます。 翻訳はテクニカルアカウントマネージャーの松本が担当しました。

本記事は 2026 年 9 月 8 日 に公開された「 Getting started with Oracle Database@AWS: A complete onboarding guide 」を翻訳したものです。 Oracle Database@AWS (ODB@AWS) は、Oracle Exadata Database Service と Oracle Autonomous Database を AWS データセンター内でネイティブに提供します。Oracle ワークロードは専用設計の Exadata インフラストラクチャ上で動作し、 Amazon Bedrock 、 Amazon Redshift 、 AWS Key Management Service (AWS KMS) 、 Amazon CloudWatch 、 AWS CloudTrail といった AWS サービスに低レイテンシーでアクセスできます。同時に、Oracle データベースエンジン、Exadata のパフォーマンス特性、そしてチームが現在使っている DBA ツールもそのまま維持できます。 本記事では、Oracle Database@AWS のオンボーディングを、サービスの選定からプロビジョニング可能な環境が整うまで通して解説します。必要なサービスに応じて、簡略化されたパブリックオファーの経路と、5 ステップからなるプライベートオファーの経路のどちらかをたどります。どちらの経路も解説します。 Autonomous Database Serverless (ADB-S) と Exascale Infrastructure (ExaDB-XS) 上の Exadata Database Service については、 AWS Marketplace でパブリックオファーが提供されており、事前の調達手続きは要りません。サブスクライブすれば数分でプロビジョニングを始められます。ステップ 1 のサービス選定表で、適切な出発点がわかります。 オンボーディングの全体像 サービスの選定からプロビジョニング可能な環境が整うまでの流れは、2 つのフェーズに分かれます。 調達 (ステップ 1〜2): サービスを選び、オファー (パブリックまたはプライベート) を確保し、AWS Marketplace で承諾します。 オンボーディング (ステップ 3〜5): アカウントの前提条件を確認し、OCI テナンシをリンクし、両クラウドで ID とアクセス許可を設定します。 ここまで終われば、プロビジョニングの準備が整います。ODB ネットワーク、Exadata インフラストラクチャ、VM クラスターの作成は「次のステップ」で扱います。 2 つのフェーズに対応する 5 つのステップは次のとおりです。 サービスを選定し、オファーを確保する。 オファーを承諾する。 前提条件を確認する。 OCI テナンシをリンクする。 AWS Identity and Access Management (IAM) のグループとロールを設定する。 次の図は、5 つのステップを 2 つのフェーズにグループ分けしたものです。 図 1: 調達フェーズとオンボーディングフェーズに分けた 5 つのオンボーディングステップ ステップ 1: サービスを選定し、オファーを確保する まず、ワークロードに適した Oracle Database@AWS のサービスを見極めます。選んだサービスによって、使える機能とたどる調達経路の両方が決まります。 サービスと調達経路を選ぶ サービス オファーの種類 選ぶ場面 Exadata Database Service on Dedicated Infrastructure (ExaDB-D) プライベートオファー (ステップ 1〜5) 次のいずれかが必要な場合。完全なシングルテナント分離を備えた専用 Exadata ラック、ノード数・ECPU・メモリを完全に制御できる Oracle RAC、大規模な統合環境向けの極めて高いスケーラビリティ、Oracle COTS アプリケーション (PeopleSoft、E-Business Suite、JD Edwards、Siebel、CC&B) 向けの認定 MAA アーキテクチャ。 Exadata Database Service on Exascale Infrastructure (ExaDB-XS) パブリックオファー (ステップ 3 へ) またはプライベートオファー 専用インフラストラクチャなしで Exadata の性能をフルに使いたい場合。規模の異なる本番データベース、サービス間 Data Guard による DR スタンバイ、開発・テスト環境、小さく始めて成長するワークロードに向いています。インフラストラクチャの最小コミットメントはありません。 Autonomous Database Serverless (ADB-S) パブリックオファー (ステップ 3 へ) またはプライベートオファー インフラストラクチャに関する判断が一切不要なフルマネージドの Oracle データベースを使いたい場合。パッチ適用、チューニング、スケーリング、可用性は Oracle が担います。OLTP、分析、混在ワークロード、アイドル時の自動一時停止に向いています。 Autonomous Database on Dedicated Exadata Infrastructure (ADB-D) プライベートオファー (ステップ 1〜5) 完全な専用インフラストラクチャ上で自律運用が必要な場合。パッチ適用とチューニングは Oracle が担いつつ、メンテナンスウィンドウとシングルテナント分離の制御は自社で保持します。 ワークロードが ExaDB-XS または ADB-S に合っていて、パブリックオファーで要件を満たせるなら、インフラストラクチャのサイジングや Oracle との事前調整は要りません。 Oracle Database@AWS の AWS Marketplace ページからサブスクライブし、ステップ 3 に進んでください。パブリックオファーで提供されるサービスの最新のリージョン対応状況は、 Regional Availability for Oracle AI Database@AWS を参照してください。 ExaDB-D または ADB-D をデプロイする場合、あるいは交渉価格やコミット条件が必要な場合は、以降のセクションのプライベートオファーのプロセスに進みます。 プライベートオファーをリクエストする プライベートオファーは、ワークロード要件に合わせて自社と Oracle の間で結ぶ交渉ベースの契約です。手順は次のとおりです。 AWS Management Console の Oracle Database@AWS 製品ページで Request private offer を選びます。OCI にリダイレクトされ、AWS リージョン、ワークロード要件、連絡先情報を入力します。 あるいは、Oracle のアカウントチームか AWS チャネルパートナーに直接依頼してリクエストを開始することもできます。 最初に AWS アカウント ID を伝えます。Oracle が正しいアカウント向けにオファーを生成するために必要です。 ヒント: AWR Miner や Oracle 提供のサイジングユーティリティ (Cloud Premigration Advisor Tool ( CPAT )、 ORAchk ) を、移行元データベースに対して早い段階で実行しておきましょう。出力はそのままサイジング作業に使えるため、最初から精度の高いオファーを組み立てられます。 購入者アカウントを選ぶ ODB@AWS を調達すると、エンタイトルメントは購入者アカウント (buyer account) と呼ばれる単一の AWS アカウントに紐付きます。マルチアカウント環境では、組織の管理アカウントである必要はありません。AWS のベストプラクティスとしては、商用契約を保持する専用の購入者アカウントを推奨します。購入者アカウントは AWS Resource Access Manager (AWS RAM) を使い、同一 AWS Organization 内のワークロードアカウントとエンタイトルメントを共有します。調達のガバナンスとインフラストラクチャのデプロイを分離でき、監査証跡も明確に保てます。単一ワークロードのデプロイなら、購入者アカウントとワークロードアカウントを同じにしても構いません。 概念 説明 ODB@AWS での役割 購入者アカウント プライベートオファーを承諾し、AWS Marketplace のサブスクリプションを保持する AWS アカウント ODB@AWS のエンタイトルメントを受け取り、OCI SKU の請求先となり、OCI テナンシとリンクされます。プロビジョニングはすべてこのアカウントから行うか、このアカウントから共有されます。 管理アカウント 一括請求と SCP を管理する AWS Organization のルートアカウント 購入者アカウントである場合もそうでない場合もあります。組織が専用の調達アカウントを使っているなら、管理アカウントではなくそのアカウントが購入者になります。 重要: 購入者アカウントは、オンボーディング後に OCI テナンシと恒久的にリンクされます。後から変更するには再オンボーディングが必要です。 オファーをリクエストする前に、概念実証 (PoC) の段階であってもアカウントの選定を済ませておきましょう。本番で使う予定の購入者アカウントで PoC を始めれば、プライベートオファーをその場で追加するだけで本番へ移行できます。OCI テナンシのリンク、ネットワーク構成、既存のインフラストラクチャはそのまま引き継がれます。オンボーディング後に購入者アカウントを変更すると、再オンボーディングを一からやり直すことになり、OCI テナンシの再マッピング、ネットワークの再構築、場合によってはデータ移行まで必要になります。 マルチアカウント構成の組織では、 AWS License Manager を使い、購入者アカウントから同一 AWS Organization 内のワークロードアカウントへ ODB@AWS のサブスクリプションを共有できます。アカウント間のリソース共有には AWS Resource Access Manager (AWS RAM) を使います。オファーをリクエストする前に、購入者アカウントの方針を決めておきましょう。 シンプル構成: 購入者アカウントとワークロードアカウントが同一。単一ワークロードや PoC のデプロイに向いています。 エンタープライズ構成: 専用の購入者アカウントまたは調達アカウントを用意し、License Manager でエンタイトルメントを共有します。複数のワークロードアカウントを持つランディングゾーンのパターンに向いています。 詳細な手順は Request Offer for Oracle AI Database@AWS を参照してください。マルチアカウントでの共有については Subscription Sharing for Oracle AI Database@AWS を参照してください。 ターゲットアーキテクチャとサイジングを決める (ExaDB-D と ADB-D) 専用インフラストラクチャのサービスでは、サイジングによって SKU の数量が決まり、それがそのままオファーに反映されます。サイジングは Oracle、AWS、そしてチャネルパートナーが関わる場合はパートナーも含めた共同作業です。移行元データベースの AWR Miner の出力を Oracle に提供します。そのデータをもとに、ワークロードの特性を Exadata の構成 (シェイプ、ECPU の割り当て、ストレージ容量、環境数) に落とし込む作業を Oracle が支援します。 データベース層では、次の点を計画します。 Exadata インフラストラクチャの配置 (アベイラビリティーゾーンの選定)。 VM クラスターの構成。一般には本番クラスター、マルチ AZ Data Guard 用の DR クラスター、1 つ以上の非本番クラスターです。 Oracle のマルチテナントアーキテクチャを使った CDB/PDB の統合方針。 Autonomous Recovery Service (ARS) 、Amazon Simple Storage Service (Amazon S3)、またはその両方を使ったバックアップ方針。 Navigating backup and recovery options for Oracle Database@AWS を参照してください。 クライアントサブネットとバックアップサブネットの CIDR を含む ODB ネットワークの設計。 アプリケーション層では、次の点を計画します。 app-to-DB のレイテンシーを 200 マイクロ秒未満にするため、ODB@AWS のプレイスメントグループ内に EC2 インスタンスを配置する。 高性能ネットワーキングのプレイスメントグループ を参照してください。 Virtual Private Cloud (VPC) の設計、サブネット、セキュリティグループ、ODB ピアリングの接続構成。 ロードバランシング (Application Load Balancer または Network Load Balancer) と Auto Scaling グループ。 コンテナ化したアプリケーションコンポーネント向けの Amazon Elastic Kubernetes Service (Amazon EKS) または Amazon Elastic Container Service (Amazon ECS)。 Amazon Elastic File System (Amazon EFS) による共有ストレージ、Amazon CloudWatch によるモニタリング、Terraform または AWS CloudFormation による Infrastructure as Code。 オファーの種類を選ぶ Oracle のプライベートオファーには、調達チャネルに応じて 2 種類あります。 オファーの種類 仕組み 選ぶ場面 Marketplace Private Offer (MPPO) Oracle が購入者アカウント向けに AWS Marketplace 上で直接オファーを生成します。 すでに Oracle と直接取引があり、条件を Oracle と直接交渉したい場合。 Channel Partner Private Offer (CPPO) チャネルパートナーが、Oracle 提供のオファーを AWS Marketplace から自社アカウントに提示します。 チャネルパートナー経由で調達する場合、またはそのパートナー経由で請求をまとめたい場合。 すでに Oracle と直接取引があるなら MPPO を選びます。 チャネルパートナー経由で調達する場合、またはそのパートナー経由で請求をまとめたい場合は CPPO が適しています。 請求モデルを最初に確認しておきます。自社の AWS アカウントへの直接請求 (MPPO) か、パートナー経由 (CPPO) かです。 オファーの前提情報を揃える: アカウント ID、SKU、契約条件 Oracle またはチャネルパートナーがオファーを生成する前に、次の情報を揃えます。 AWS 購入者アカウント ID: オファーを承諾する 12 桁の AWS アカウント ID。 検討対象の SKU: Exadata Cloud Infrastructure X11M および X11MV (データベースサーバーとストレージサーバーを含む固定インフラストラクチャコスト)。 Exadata Database ECPU、License Included または BYOL (変動するコンピュートコスト)。 Autonomous Database を使う場合は Autonomous AI Database ECPU (LI または BYOL)。 パブリックオファーのサービスを使う場合は ExaDB-XS または ADB-S (従量課金、最小コミットメントなし)。 バックアップ要件に応じて Autonomous Recovery Service または Zero Data Loss Recovery。 OCI 側のストレージを追加で必要とする場合は OCI Object Storage。 契約期間: 通常は 1 年、3 年、またはカスタム期間。 SKU ごとのライセンスモデル: License Included (LI) または Bring Your Own License (BYOL)。 各環境 (本番、DR、非本番) を、具体的な SKU の数量と使用時間に対応付けます。ECPU コストを最適化するため、非本番環境の稼働時間を決めておきます。非本番環境では月 264 時間が一般的な目安です。 Oracle がオファーを生成する 前提情報がすべて確定した後、最終的な入力からオファーが利用可能になるまでの目安は 2〜5 営業日です。流れは次のとおりです。 Oracle の営業担当が、指定された購入者アカウントを対象に AWS Marketplace 上でプライベートオファーを作成します。 オファーには、合意した SKU、数量、価格、契約期間が含まれます。 CPPO の場合、Oracle はチャネルパートナーから提供された情報をもとにオファーを生成します。 オファーは AWS Management Console の Oracle Database@AWS に表示されます。 View private offer を選んで内容を確認し、承諾します。 詳細な手順は Purchase Oracle AI Database@AWS を参照してください。 ステップ 2: オファーを承諾する Oracle からプライベートオファーが提示されたら、AWS Management Console で承諾し、Oracle Database@AWS のサブスクリプションを有効化します。 オファーを承諾する手順は次のとおりです。 AWS Management Console で Oracle Database@AWS に移動し、 View private offer を選びます。 オファーの条件、価格、EULA を確認します。 Create contract を選び、画面の指示に従って承諾します。 承諾後、コンソールに表示されるアクティベーションリンク、またはメールで届いたリンクから OCI アカウントを有効化します。 Oracle Cloud アカウントを新規作成するか、既存のアカウントをリンクするかを選びます。 アクティベーションを完了します。完了が確認されるとダッシュボードが使えるようになります。 マルチアカウント構成の組織では、次の対応が可能です。 AWS License Manager を使い、AWS Organization 内のアカウント間で ODB@AWS のサブスクリプションを共有する。 調達を単一の支払いアカウントに集約しつつ、プロビジョニングはワークロードアカウントで行う。 注: Oracle Database@AWS のダッシュボードは、プライベートオファーを承諾する (またはパブリックオファーでサブスクライブする) までは使えません。オンボーディングが完了するまで、プロビジョニングの API 呼び出しは失敗します。 オンボーディングが完了すると、AWS アカウントが OCI テナンシとリンクされ、サポート対象のリージョンに複製されます。OCI コンソールから使いたいリージョンを有効化すれば、サブスクリプションの手続きを繰り返さずに、サポート対象の AWS リージョンで Oracle Database@AWS を使えます。 ステップ 3: 前提条件を確認する OCI テナンシのリンクと AWS Identity and Access Management (IAM) の設定に進む前に、AWS アカウント環境の準備が整っているか確認します。次のチェックリストが主な確認項目です。 カテゴリ 確認する内容 重要な理由 Service Quotas 対象リージョンの VPC、サブネット、ENI の上限。 ODB ネットワークとピアリング接続に十分な余裕があるか確認します。 ネットワーク計画 クライアントサブネットとバックアップサブネットの CIDR 範囲。 既存の VPC CIDR と重複してはいけません。どちらも /24 以上が必要です。 IAM 必要な権限を持つ管理者ユーザーまたはロール。 詳細なポリシー設定はステップ 5 を参照してください。 DNS Amazon Route 53 のアウトバウンドリゾルバーエンドポイントと転送ルール。 アプリケーション VPC から ODB ネットワーク内の Oracle データベースのホスト名 (SCAN リスナー) を解決するために必要です。 ネットワーク計画の詳細 クライアントサブネットの CIDR: ODB ピアリング経由でアプリケーションがデータベースに接続するために使います。 バックアップサブネットの CIDR: OCI Autonomous Recovery Service または Amazon S3 へのバックアップトラフィックに使います。 どちらの CIDR も /24 以上が必要で、既存の VPC のアドレス空間と競合してはいけません。 アプリケーション VPC と ODB ネットワークの間の ODB ピアリング接続も計画しておきます。 Service Control Policy (SCP) に関する考慮点 リージョンを制限する SCP を適用している組織では、ODB@AWS のオンボーディング時に特有の注意点があります。主なデプロイ先がどこであっても、次の 2 つのリージョンを許可する必要があります。 米国東部 (バージニア北部) us-east-1: AWS License Manager のエンタイトルメント付与、AWS Marketplace のサブスクリプション承諾、グローバルサービス (IAM、AWS Organizations、STS) に必要です。SCP でこのリージョンを制限したままワークロードを別リージョンにデプロイすると、エンタイトルメントの共有が失敗します。 対象の ODB@AWS リージョン: Exadata インフラストラクチャ、ODB ネットワーク、VM クラスターをプロビジョニングするリージョンです。 重要: 組織レベルの AWS Service Control Policy (SCP) や権限境界はユーザーの権限を上書きし、オンボーディングの失敗につながることがあります。作業を進める前に AWS Organization の管理者に確認してください。 ステップ 4: OCI テナンシをリンクする Oracle Database@AWS はコントロールプレーンが分かれています。ネットワークや Exadata などのインフラストラクチャリソースは AWS 側で管理し、DB Home、PDB、パッチ適用といったデータベース管理は OCI 側が担います。そのため、インフラストラクチャには慣れた AWS のツールを使いながら、データベースのライフサイクル層は Oracle が管理します。OCI テナンシのリンクは、2 つのコントロールプレーンをつなぐクラウド間の接続を確立する作業です。 選択肢 使う場面 手順 OCI テナンシを新規作成する Oracle Cloud の利用実績がない場合 アクティベーション時に自動的に作成されます。オンボーディングを実施したユーザーがテナンシ管理者になります。 既存の OCI テナンシをリンクする Oracle のサポート契約を含む OCI アカウントをすでに持っている場合 アクティベーション時に接続します。対象の AWS リージョンとペアになる OCI リージョンにテナンシがサブスクライブされている必要があります。 OCI テナンシは、対象の AWS リージョンとペアになる OCI リージョンにサブスクライブされている必要があります。たとえば米国東部 (バージニア北部) は OCI の US East (Ashburn) と、アジアパシフィック (シドニー) は OCI の Australia East (Sydney) とペアになります。現在のペアリングの一覧は Supported Regions for Oracle Database@AWS を参照してください。 リンクしたテナンシでは、日々のデータベース運用を次のように行います。 データベースのコントロールプレーン: OCI コンソールまたは API から DB Home、CDB、PDB を作成・管理します。 Data Guard: 高可用性と DR のためにスタンバイデータベースを構成します。 バックアップ管理: OCI Object Storage または Amazon S3 への自動バックアップ。 パッチ適用: データベース、Grid Infrastructure、OS のパッチを自社のスケジュールで適用します。 モニタリング: OCI 側のパフォーマンスメトリクスと診断情報。 注: オンボーディング時にテナンシを新規作成した場合、オンボーディングを実施したユーザーが自動的に OCI テナンシの管理者になります。 ステップ 5: グループとロールを設定する ODB@AWS では、AWS 側と OCI 側の両方で IAM の権限設定が必要です。2 つのクラウドにまたがるガバナンスモデルでは、最小権限と職務の分離を保つために入念な計画が求められます。 AWS IAM の権限 ODB@AWS では、プロビジョニング権限を付与する出発点として AmazonODBFullAccess という AWS 管理ポリシーが用意されています。インフラストラクチャチームが使う IAM ロールまたは許可セットにアタッチしてください。このポリシーは、ODB ネットワークと VM クラスターの作成に必要な odb:* の主要アクションと EC2 ピアリング操作を含みます。 次の例は、ネットワーク、プレイスメントグループ、DNS に関して追加することが多い権限をまとめたものです。 { "Version": "2012-10-17", "Statement": [ { "Sid": "ODBFullAccess", "Effect": "Allow", "Action": ["odb:*"], "Resource": "*" }, { "Sid": "NetworkingForODB", "Effect": "Allow", "Action": [ "ec2:CreateVpc", "ec2:CreateSubnet", "ec2:CreatePlacementGroup", "ec2:DescribePlacementGroups", "ec2:CreateTags", "route53resolver:CreateResolverEndpoint", "route53resolver:CreateResolverRule" ], "Resource": "*" } ] } 重要: この例の odb:* は Oracle Database@AWS のすべての API アクションへのアクセスを許可するもので、初期セットアップや PoC デプロイの出発点として想定しています。本番環境では、odb:* をワークロードに必要なアクションだけ (たとえば odb:CreateOdbNetwork、odb:CreateCloudExadataInfrastructure、odb:CreateCloudVmCluster) に置き換え、Resource 要素も特定の ARN に絞り込んでください。アクションの全一覧は Actions, resources, and condition keys for Oracle Database@AWS を、最小権限のガイダンスは AWS managed policies for Oracle Database@AWS を参照してください。 管理ポリシーには、アーキテクチャの選択に依存する権限があえて含まれていません。次の権限はカスタマー管理ポリシーで追加します。 機能 追加するアクション 必要になる条件 Amazon VPC Lattice と VPC エンドポイント vpc-lattice:*、ec2:CreateVpcEndpoint、ec2:DeleteVpcEndpoints 常に必要: ODB ネットワークの作成に必須 (S3 バックアップ連携はデフォルトでプロビジョニングされます) プレイスメントグループの管理 ec2:CreatePlacementGroup、ec2:AttachResourcesToPlacementGroup、ec2:DeletePlacementGroup 常に必要: マネージドクラスタープレイスメントグループをサポートする AZ で必須 ODB ピアリングと DNS 向けの EC2 ネットワーキング ec2:CreateRoute、ec2:DeleteRoute、route53resolver:* 常に必要: VPC ルートテーブルの更新と DNS 転送に必須 リソース共有 (クロスアカウント) ram:CreateResourceShare、ram:AssociateResourceShare インフラストラクチャや ODB ネットワークをアカウント間で共有する場合のみ カスタマー管理の暗号化 kms:CreateKey、kms:CreateGrant、kms:GenerateDataKey* Autonomous Database でカスタマー管理の KMS キーを使う場合のみ 必要なアクションをすべて含む完全なポリシー JSON は、 AWS managed policies for Oracle Database@AWS を参照してください。 DNS 計画に関する注意 : プロビジョニング後、アプリケーション VPC から ODB ネットワーク内の Oracle データベースのホスト名 (SCAN リスナー) を解決できるようにする必要があります。そのためには、Amazon Route 53 のアウトバウンドエンドポイントと、ODB ネットワークの DNS リスナーを宛先とする転送ルールが必要です。IAM 権限 (route53resolver:*) とサブネットの配置は、この段階で計画しておきましょう。設定は ODB ネットワークを作成した後に行います。詳細は Configuring DNS for Oracle Database@AWS を参照してください。 OCI IAM の権限 OCI テナンシの管理者でないユーザーは、対象コンパートメントで次のポリシーステートメントを持つグループに所属する必要があります。 # Broad admin access (simplest) Allow group <group_name> to manage database-family in compartment <compartment_name> # Narrower least-privilege policies Allow group <group_name> to use cloud-vmclusters in compartment <compartment_name> Allow group <group_name> to manage db-homes in compartment <compartment_name> Allow group <group_name> to manage databases in compartment <compartment_name> Allow group <group_name> to manage db-backups in compartment <compartment_name> 職務の分離 各ロールに必要な範囲だけにアクセスを絞れるよう、ペルソナとクラウドごとの権限を対応付けます。 ペルソナ AWS の権限 OCI の権限 クラウド管理者 odb:* (本番では特定のアクションに絞る) とネットワーキング manage all-resources in tenancy ネットワーク管理者 VPC、サブネット、ピアリング向けの ec2:* manage virtual-network-family DBA odb:Get*、odb:List* manage database-family in compartment 読み取り専用 / 監査担当 odb:Get*、odb:List* read all-resources in compartment 注: 「Missing permissions: P[DB_HOME_CREATE], P[DATABASE_CREATE]」というエラーが出る場合、マッピングされたコンパートメントの OCI IAM ポリシーに「manage db-homes」と「manage databases」が不足しています。AWS 側ではなく OCI 側の権限の問題です。 AWS と OCI 間の ID フェデレーション ODB@AWS では運用の境界が明確です。VM クラスターまでのインフラストラクチャとネットワーク層は AWS が担い、その内側のデータベースライフサイクル層は OCI が担います。ID は両方のクラウドをまたいで使えるため、個別の認証情報は不要で、OCI 側で新しいユーザー、ロール、グループを作る必要もありません。 オンボーディング時に、OCI が必要な ID 構成を自動的に作成します。具体的には、テナンシのリンク、AWS アカウントと 1 対 1 で対応するコンパートメント、そしてマルチクラウドサービスがユーザーに代わって操作することを認可する IAM ポリシーとユーザーグループのセットです。ユーザーは引き続き IAM か、IAM Identity Center 経由で社内の ID プロバイダーで認証します。OCI 側の認可はクラウド間の信頼関係が透過的に処理します。 日々のインフラストラクチャ作業では、AWS コンソールから離れる必要はありません。CDB/PDB の作成、Data Guard の構成、パッチ適用といったデータベースのライフサイクル操作では、AWS コンソールの Manage in OCI ボタンから OCI コンソールを開きます。SAML フェデレーションを構成しておけば、別途ログインせずに認証済みの状態で OCI コンソールに移動できます。 操作 実施場所 インターフェイス ODB ネットワークの作成・管理 AWS コンソール、CLI、API、CloudFormation Exadata インフラストラクチャのプロビジョニング AWS コンソール、CLI、API、CloudFormation VM クラスターの作成 AWS コンソール、CLI、API、CloudFormation TGW、DNS、VPC ピアリングの構成 AWS コンソール、CLI、API VPC Lattice 連携と Zero-ETL の有効化 AWS コンソール、CLI、API CloudWatch によるモニタリング AWS コンソール、CLI、API AWS RAM によるリソース共有 AWS コンソール、CLI、API Autonomous Database Serverless の作成 AWS コンソール、CLI、API Exadata データベース (CDB/PDB) の作成 OCI コンソール、OCI CLI、OCI API、Terraform (OCI プロバイダー) 専用インフラストラクチャ上の Autonomous DB の作成 OCI コンソール、OCI CLI、OCI API、Terraform (OCI プロバイダー) Data Guard の構成 OCI コンソール、OCI CLI、OCI API データベースのパッチ適用と更新 OCI コンソール、OCI CLI、OCI API データベースの ECPU/OCPU のスケーリング OCI コンソール、OCI CLI、OCI API PDB の管理、クローン、リストア OCI コンソール、OCI CLI、OCI API OCI ネットワークセキュリティグループの構成 OCI コンソール、OCI CLI、OCI API、Terraform (OCI プロバイダー) 注: AWS 側の「コンソール」は AWS Management Console を指します。OCI 側の「コンソール」は、Manage in OCI ボタンからアクセスする Oracle Cloud Console を指します。SAML フェデレーションを構成していれば、OCI に別途ログインする必要はありません。 オプション: SAML フェデレーションを設定する データベース運用のために OCI コンソールへアクセスする必要があるチームでは、SAML フェデレーションを構成すれば既存の社内 ID プロバイダーでシングルサインオンできます。SAML フェデレーションの構成はオンボーディング後のオプション作業で、AWS 側・OCI 側の操作を妨げるものではありません。OCI 専用のユーザー認証情報を作成・管理する手間もなくなります。作業内容は、ID プロバイダー (IAM Identity Center、Okta、Azure AD、または SAML 2.0 対応の IdP) を OCI Identity Domains に登録し、グループをオンボーディング時に自動作成された OCI グループにマッピングすることです。手順の詳細は Federation for Oracle AI Database@AWS and Federating with SAML 2.0 Identity Providers を参照してください。 ID 管理の姿を整理すると、OCI のユーザー作成もグループ管理もロールの割り当てもパスワードのローテーションも不要です。自動作成されるポリシーとフェデレーションがすべてを引き受けます。セキュリティチームは 1 つの ID 基盤を維持すればよく、運用チームは主に AWS コンソールで作業し、OCI 側のデータベース操作は ID 管理の負担なく SSO でアクセスできます。 次のステップ 5 つのステップが完了すれば、環境のオンボーディングは終わり、プロビジョニングを始められます。次のような作業が可能です。 プレイスメントグループの自動プロビジョニングを伴う ODB ネットワークの作成。 ExaDB-D 向けの Oracle Exadata インフラストラクチャ (Quarter、Half、Full Rack) のデプロイ。 高可用性のための RAC 構成の Exadata VM クラスターの作成。 アプリケーション VPC と ODB ネットワークの間の ODB ピアリングの確立。 app-to-DB のレイテンシーを 200 マイクロ秒未満にするため、プレイスメントグループ内での EC2 インスタンスの起動。 プロビジョニングの手順は、AWS ドキュメントの Getting started with Oracle Database@AWS を参照してください。 まとめ 本記事では、Oracle Database@AWS のオンボーディングを一通り解説しました。パブリックオファーのサービス (ADB-S と ExaDB-XS) なら、AWS Marketplace のサブスクリプションとアカウントの前提条件を満たすだけで始められます。専用インフラストラクチャのサービス (ExaDB-D と ADB-D) では、オファーの調達、テナンシのリンク、2 つのクラウドにまたがる IAM 設定を 5 つのステップで進めます。サービスの選定、サイジング、購入者アカウントの方針、IAM を事前にしっかり計画しておくことが、プロビジョニングを滞りなく進める鍵になります。 オンボーディングが済んだら、次は ODB ネットワークの作成、Exadata インフラストラクチャのプロビジョニング、最初の VM クラスターのデプロイに進みます。次のリソースが役立ちます。 プロビジョニングのガイドと API リファレンスは Oracle Database@AWS のドキュメント 。 マルチアカウントのパターンは Best practices for cross-account sharing in Oracle Database@AWS 。 料金、リージョン、機能の概要は Oracle Database@AWS の製品ページ 。 まずは AWS Marketplace の Oracle Database@AWS にアクセスしてみてください。ADB-S と ExaDB-XS はパブリックオファーで直接サブスクライブできます。専用インフラストラクチャのサービスは、 AWS Management Console からプライベートオファーをリクエストしてください。 著者について Raghu Soma AWS のシニアパートナーソリューションアーキテクトです。お客様やパートナーと協力し、Oracle Database@AWS や Oracle Applications (COTS) を含む Oracle ワークロードを AWS 上で設計・デプロイしています。Oracle 環境全体でコストを抑え、耐障害性を高め、クラウドネイティブな機能を活用できるよう支援しています。 Simon Cunningham Simon は AWS のプリンシパルパートナーソリューションアーキテクトで、Oracle ワークロードの支援に 25 年以上携わってきました。お客様のエンタープライズ COTS アプリケーションを AWS と ODB@AWS へ移行・モダナイズし、耐障害性の向上、コスト削減、そして適切な場面でのクラウドネイティブサービスの活用を支援しています。 Manak Nanda Manak は Amazon Web Services (AWS) でパートナーソリューションアーキテクトのマネージャーを務めており、シアトルを拠点としています。彼のチームはビジネスアプリケーション領域を専門とする AWS テクノロジーパートナーを支援し、南北アメリカでの Build、Market、Co-Sell の実行を推進しています。技術リーダーシップ、クラウドアーキテクチャ、エージェント型 AI、パートナービジネスの成長が注力分野です。 この記事は Solutions Architect の 矢木 覚 がレビューしました。