本稿は、2026 年 10 月 2 日に公開された “ Architect highly available Oracle Database on Amazon EVS and FSx for ONTAP ” を翻訳したものです。 VMware Cloud Foundation (VCF) への既存投資がある企業は、アプリケーションの再設計や運用チームの再教育を行うことなく、Oracle データベースを AWS に移行したいと考えています。 Amazon Elastic VMware Service (Amazon EVS) 上の Oracle は、既存の VMware 運用ワークフローを維持しながら、サブミリ秒のストレージレイテンシー、スナップショットベースのバックアップ、クロスリージョンディザスタリカバリ (DR)、および独立したストレージスケーリングを活用できます。 この記事では、 Amazon FSx for NetApp ONTAP を使用して Amazon EVS 上に Oracle Database 環境を設計する方法を紹介します。使い慣れた VMware 運用ツールを維持しながら、ストレージ、コンピューティング、ネットワーキング、ディザスタリカバリの各レイヤーがどのように連携して高可用性、クロスリージョン DR、サブミリ秒のストレージレイテンシーを実現するかを学びます。 この記事では、以下の方法を学びます。 VMware Cloud Foundation 9.1 が稼働する Amazon EVS 上の Oracle Database アーキテクチャの設計 Oracle ワークロードに最適な EC2 ベアメタルインスタンスタイプと VM サイジングの選択 Oracle のデータボリュームおよびログボリューム用の NFS データストアとして FSx for ONTAP を使用したストレージの設計 クロスリージョン DR のための SnapMirror レプリケーション計画 既存の Oracle ワークロードをオンプレミスの VMware から Amazon EVS に移行するための移行オプションの評価 Amazon EVS は、 Amazon Virtual Private Cloud (Amazon VPC) 内の Amazon Elastic Compute Cloud (Amazon EC2) ベアメタルインスタンス上で VMware Cloud Foundation (VCF) 環境を直接実行します。VCF 9.x では、Amazon EVS がベアメタルインフラストラクチャと VLAN サブネットをプロビジョニングし、その後 Broadcom の VCF Installer を使用して VCF をデプロイします (セルフデプロイモデル)。VCF 9.x は評価モードもサポートしているため、ライセンスキーを適用する前に設計を検証でき、Solutions for Amazon EVS GitHub リポジトリでは段階的な VCF 9 デプロイメントを自動化する AWS CloudFormation および Terraform テンプレートが提供されています。FSx for ONTAP は、NFS、SMB、iSCSI、および NVMe over TCP アクセスを備えたマネージド ONTAP ストレージを提供します。FSx for ONTAP は、サブミリ秒の応答時間、数 GBps のスループット、およびファイルシステムあたり最大 80,000 IOPS を実現できます ( FSx for ONTAP のパフォーマンス を参照)。 詳細については、 FSx for ONTAP の機能 を参照してください。 プロビジョニング、ストレージ設定、Oracle のインストール、SnapMirror のセットアップを含むデプロイメント手順については、関連記事「 Amazon EVS と FSx for ONTAP における Oracle Database のデプロイステップ 」を参照してください。 ソリューションアーキテクチャ このセクションでは、2 つの AWS リージョンにまたがる Amazon FSx for ONTAP ストレージを使用した、Amazon EVS 上の高可用性 Oracle Database デプロイメントについて説明します。図 1 は、オンプレミスからハイブリッド接続を経由して本番 Amazon EVS 環境およびクロスリージョン DR に至るデータフローを示しています。 図 1: FSx for ONTAP とクロスリージョン SnapMirror DR を使用した Amazon EVS 上の Oracle Database このアーキテクチャは 8 つの機能コンポーネントで構成されており、次のセクションで説明します。 アーキテクチャコンポーネント 以下の項目は、図に示されたデータフローに対応しています。 ハイブリッドリンク — オンプレミスデータセンターは、 AWS Direct Connect を通じて AWS に接続し、低レイテンシーの専用帯域幅を確保します。 トランジットルーティング — AWS Transit Gateway が本番 VPC、DR リージョン、オンプレミスネットワーク間のトラフィックをルーティングします。 ワークロードランディング — トラフィックは、VCF 9.1 を搭載した i7i.metal-24xl Amazon EC2 ベアメタルインスタンス上で稼働する EVS データベースクラスターに到達します。 ライブマイグレーション — VMware HCX (Hybrid Cloud Extension) が、Replication Assisted vMotion または Bulk Migration を使用して、オンプレミスの VMware から Amazon EVS へ Oracle VM をほぼゼロダウンタイムで移行します。 NFS データパス — 各 ESXi ホストは FSx for ONTAP を NFS データストアとしてマウントします。Oracle VM は、データベースボリュームにブロックデバイス (NFS データストア上の VMDK) としてアクセスし、サブミリ秒のレイテンシーと最大 80,000 IOPS を実現します。各ホストは FSx for ONTAP への独立した NFS パスを持ち、クラスター全体で帯域幅を分散します。 クロスリージョン DR — SnapMirror が FSx for ONTAP ボリューム (データ、ログ、バイナリ) を、設定可能な目標復旧時点 (RPO) で DR リージョンに非同期でレプリケートします。 ダイナミックルーティング — NSX Tier-0 ゲートウェイが BGP を介して Amazon VPC Route Server とピアリングします。これは一方向の BGP です。Route Server は NSX によってアドバタイズされたルートをリッスンして VPC ルートテーブルに書き込みますが、VPC ルートを NSX に戻してアドバタイズすることはありません。 DR フェイルオーバー — フェイルオーバー時、Transit Gateway は DR リージョンにルーティングし、そこで事前にプロビジョニングされたスタンバイ Oracle VM が SnapMirror レプリカボリュームをマウントします。 Amazon EVS 上の Oracle Database デプロイメントで考慮すべき要素 デプロイメントを開始する前に、利用可能なインフラストラクチャオプションに対して Oracle ワークロードの要件を評価してください。インスタンスタイプ、VM サイジング、ストレージアーキテクチャについて行う決定は、データベースのパフォーマンス、コスト、運用の複雑さに直接影響します。 Oracle ライセンスに関する考慮事項: インスタンスタイプの選択は Oracle のライセンスコストに影響するため、考慮すべき重要な要素です。さらなるガイドラインについては、 AWS Optimization and Licensing Assessment (AWS OLA) のリクエストをお勧めします。 ESXi ホスト向けの EC2 インスタンスタイプの選択 Amazon EVS は現在、ESXi ホスト向けに 3 つのベアメタルインスタンスタイプをサポートしています。選択は、コアあたりのコンピューティング速度 (i7i) を優先するか、ホストあたりのメモリとストレージ密度 (i4i) を優先するか、また単一ホストを垂直方向にどの程度スケールしたいかによって異なります。ほとんどの新規 Oracle デプロイメントでは、Oracle のクエリパフォーマンスが CPU の命令スループットとストレージ IO レイテンシーに敏感であるため、i7i がより良い選択です。 i7i.metal-24xl (推奨デフォルト): 96 vCPU (48 コア)、768 GiB RAM。第 5 世代 Intel Xeon は改善されたコンピューティングパフォーマンスを提供します。第 3 世代 AWS Nitro SSD は、vSAN 向けに、強化されたリアルタイムストレージパフォーマンスと低い IO レイテンシーを提供します。 i7i.metal-48xl: 24xl と同じ第 5 世代 Intel Xeon ですが、ホストあたりの容量は 2 倍 (192 vCPU、96 コア、1,536 GiB RAM、最大 100 Gbps のネットワークおよび 60 Gbps の Amazon Elastic Block Store (Amazon EBS) 帯域幅)。大規模な SGA、高いコア数、または VMware のホストあたりライセンスを削減するためのより少なく高密度なホストなど、単一の Oracle ホストを垂直方向にスケールしたい場合に選択します。24xl と同じコアあたりのパフォーマンスプロファイルを維持します。 i4i.metal: より高いホストあたり密度 (128 vCPU、1,024 GiB RAM、30 TB NVMe) で、より少なく大きなホストを必要とする環境に適しています。 VCF 互換性: 3 つのインスタンスタイプすべてが ESXi 9.1 (ビルド 9.1.0.0100.25433460) を備えた VCF 9.1 をサポートします。VCF 5.2.2 (ESXi 8.0U3g) は引き続き利用可能ですが、サポート終了に向かっているため、新規デプロイメントはデフォルトで 9.x を使用すべきです。Amazon EVS 環境はクラスターあたり 4〜32 ホストをサポートします。同じ SDDC 内のクラスター間でインスタンスタイプを混在させることができます。 Oracle Database ゲスト向けの VM サイジング 以下のワークロード特性に基づいて Oracle Database VM をサイジングします。 Oracle の CPU_COUNT パラメーターに一致する vCPU 数を割り当てます。 SGA + PGA + OS オーバーヘッド向けにメモリをサイジングします (通常、割り当てられた VM メモリの 75〜85% を SGA に)。 VM スワップを vSAN データストア上に設定します (NFS ではない)。vSAN は 1 桁ミリ秒のレイテンシーを持つローカル NVMe を使用します。 単一ソケットのコア数を超える VM には NUMA 対応の VM 配置を使用します。 追加コストなしで 1 桁ミリ秒のレイテンシーを得るために、OS スワップと Oracle の一時表領域を vSAN データストア上に配置します。 ストレージアーキテクチャ: vSAN + FSx for ONTAP 推奨される設計では、ストレージの役割を 2 つの階層に分割します。 vSAN (各 ESXi ホスト上のローカル NVMe ドライブで構成) は、低レイテンシーで非レプリケーションのワークロードを処理します。 ( VM ブートディスク、OS スワップ、Oracle 一時表領域) FSx for ONTAP は、スナップショットベースのバックアップとクロスリージョンレプリケーションを必要とする Oracle データファイルと REDO ログを処理します。ESXi ホストは FSx for ONTAP ボリュームを NFS データストアとしてマウントし、Oracle VM はそれらのデータストア上の標準 VMDK にアクセスします。 この分離により、一時的な IO にはローカル NVMe の速度を提供しつつ、永続的なデータベースファイルにはスナップショット、クローン、SnapMirror の機能を追加できます。 なぜゲスト内 NFS (dNFS) ではなく NFS データストア (ホストレベル) なのか？ ゲスト内 NFS では、すべての Oracle NFS トラフィックが FSx for ONTAP に到達する前に NSX オーバーレイと NSX Edge ノードを経由します。これにより単一の Edge ボトルネックが生じます。NFS データストアでは、各 ESXi ホストが自身のネットワーク帯域幅を使用して FSx for ONTAP と直接 NFS で通信します。Edge ボトルネックも余分なレイテンシーホップもありません。 FSx for ONTAP のサイジングに関する考慮事項 重要: Oracle には 100% SSD を使用します。 Oracle データベースボリュームにはキャパシティプールの階層化を使用しないことをお勧めします。すべての Oracle ボリュームで階層化ポリシーを none に設定したままにしてください。 重要: SSD の容量を計画します。 SSD 階層が容量いっぱいになると、FSx for ONTAP は書き込みをブロックします。SSD 使用率を監視し、余裕 (最低 20% の空き) を確保してください。 重要: 読み取り/書き込みスループットは非対称です。 6 GB/s のファイルシステムでは、読み取りスループットは 6 GB/s に達することができますが、書き込みスループットは約 1 GB/s に制限されます。Oracle の書き込みワークロード要件に基づいてスループット容量をサイジングしてください。この書き込み上限は高可用性 (HA) ペアごとに適用されます。単一の HA ペアを超えて書き込みスループットをスケールするには、複数の HA ペアを持つファイルシステムをデプロイし、追加のアグリゲート全体に Oracle ボリュームを分散させて、書き込みがペア間で分散されるようにします。この配置は自動ではないため、書き込みの多いデータセットのバランスを保つために、事前にレイアウトを計画してください。 ネットワークアーキテクチャ Amazon EVS は、トラフィックをセグメント化するために VLAN サブネット (環境作成時に定義され、後から変更不可) を使用します。 VPC Route Server は、VPC 内の静的ルートを置き換えます。NSX Tier-0 ゲートウェイは BGP を介して Route Server エンドポイントとピアリングします。これは一方向の BGP です: Route Server は NSX からのルートをリッスンして VPC ルートテーブルに書き込みますが、VPC ルートを NSX に戻してアドバタイズすることはありません。VPC の外側では、Transit Gateway のルートは静的なままです。 Oracle 向けの NSX-T セグメンテーション 本番データベースセグメント (DB サブネット) 専用の Tier-1 ゲートウェイ。 アプリケーション層 (App サブネット) とペリメーターネットワーク用に別の Tier-1。 分散ファイアウォールルールが、Oracle リスナーアクセス (TCP 1521) を認可されたアプリケーションセグメントのみに制限。 Oracle インスタンス間のマイクロセグメンテーションが、ラテラルムーブメントを防止。 重要: セキュリティグループルールは VLAN サブネットインターフェイスでは適用されません。トラフィック制御にはネットワーク ACL と NSX 分散ファイアウォールを使用してください。 高可用性とディザスタリカバリ SnapMirror レプリケーションの頻度が RPO を決定します。ビジネス要件に基づいて設定します。 目標復旧時間 (RTO) を短縮するために、DR クラスターにスタンバイ Oracle VM を事前にプロビジョニングします。 復旧中に Oracle のインストールが不要になるように、バイナリボリュームをレプリケートします。 ヒューマンエラーを減らすために、Ansible/SnapCenter でフェイルオーバーを自動化します。 DR に関する Oracle ライセンスの考慮事項: DR レプリケーションの実装方法に基づいてライセンスへの影響があります。ライセンスに関する質問がある場合は、 AWS Optimization and Licensing Assessment (AWS OLA) のリクエストをお勧めします。 Oracle のライセンス規則に準拠するための代替案として、NetApp SnapMirror を通じて Oracle VM を本番環境から DR にレプリケートする方法があります。Oracle の二重ライセンスを回避するため、フェイルオーバーイベントが宣言されるまで、DR のレプリケートされたボリュームを DR ホスト上で NFS データストアとしてマウントせず、データ保護 (DP) ボリュームとして保持してください。フェイルオーバーイベントが宣言された時点ではじめて、SnapMirror を解除し、DR ホスト上で NFS データストアをマウントし、VM の電源を入れます。VM の電源が入っていなくても SnapMirror ボリュームをデータストアとして事前にマウントすることは、それらのホスト上で Oracle バイナリにアクセス可能になることを意味し、Oracle はこれを DR クラスター全体でライセンスを必要とする「インストール」とみなす可能性があります。 オンプレミス VMware から Amazon EVS へのデータベース移行 以下の表は、オンプレミス VMware から Amazon EVS への移行オプションを比較しています。 オプション 方法 最適な用途 ダウンタイム 1 VMware HCX ライブマイグレーション 既存のオンプレミス VMware ほぼゼロ (vMotion) または計画的な一括移行 2 SnapMirror ONTAP-to-ONTAP NetApp ONTAP 上のオンプレミス Oracle 数分 (最終同期の切り替え) 3 Oracle PDB リロケーション PDB/CDB マルチテナントモデル 短時間 (最終切り替えのみ) 4 RMAN バックアップ/リストア 非 ONTAP のオンプレミス (汎用) 数時間 (バックアップ + リストア + 適用) 各移行オプションの詳細な手順については、関連記事「 Oracle Database Deployment on Amazon EVS and FSx for ONTAP: Best Practices 」を参照してください。 セキュリティ Amazon EVS 上の Oracle のセキュリティは、ネットワーク分離からデータベースレベルの暗号化まで、複数のレイヤーにまたがります。以下の表は、各レイヤーのセキュリティコントロールをまとめたものです。 レイヤー コントロール ネットワークセグメンテーション NSX-T Tier-1 ゲートウェイが DB/App/ペリメーターのネットワークセグメントを分離 East-West トラフィック NSX 分散ファイアウォール : TCP 1521 を認可されたアプリケーションセグメントに制限 North-South トラフィック ingress/egress フィルタリング用の FortiGate または同等のインスペクション VPC 保管時の暗号化 AWS Key Management Service (AWS KMS) で暗号化された FSx for ONTAP ボリューム 転送時の暗号化 NFS トラフィック用の VPC 暗号化、および SnapMirror クロスリージョン用の IPsec データベース暗号化 追加の保護のための Oracle TDE (Transparent Data Encryption) 管理アクセス VMware 管理コンソール向けのゼロトラストアクセス (例: Banyan または Zscaler) VLAN サブネットセキュリティ ネットワーク ACL (VLAN インターフェイスではセキュリティグループは適用されない) コスト最適化 Amazon EVS 上の Oracle のコスト最適化は、インフラストラクチャ容量をワークロード需要に合わせることと、AWS の料金モデルを使用することに重点を置いています。以下の表は、コンピューティング、ストレージ、ネットワーキング、Oracle ライセンスにわたる主要な戦略をまとめたものです。さらなるガイドラインについては、 AWS Optimization and Licensing Assessment (AWS OLA) のリクエストをお勧めします。 コンポーネント 戦略 EC2 ベアメタルホスト Compute Savings Plans または リザーブドインスタンス (最大 54% の節約) インスタンスタイプの選択 i7i.metal-24xl は i4i.metal に対して価格性能が約 10% 向上 FSx for ONTAP のスループット 書き込みワークロードに合わせて適正なサイジングを行い、臨機応変に調整 FSx for ONTAP のストレージ Oracle には 100% SSD、非本番環境にはストレージ効率化 データ転送 FSx for ONTAP を EVS クラスターと同じ AZ に配置 SnapMirror レプリケーション RPO に基づいて頻度をスケジュール (頻度が低い = 低コスト) Oracle DR ライセンス NetApp SnapMirror を通じて Oracle VM を本番環境から DR にレプリケートし、Oracle の二重ライセンスを回避するため、フェイルオーバーイベントが宣言されるまで DR のレプリケートされたボリュームを DR ホスト上で NFS データストアとしてマウントせずデータ保護 (DP) ボリュームとして保持。フェイルオーバーイベントが宣言された時点で、SnapMirror を解除し、DR ホスト上で NFS データストアをマウントし、VM の電源を入れる。さらなるガイドラインについては AWS Optimization and Licensing Assessment (AWS OLA) のリクエストを推奨。 非本番環境 より少ないホストを使用し、開発/テストデータに階層化を適用 まとめ FSx for ONTAP を使用した Amazon EVS 上での Oracle データベースのデプロイメントは、VMware の運用一貫性と AWS クラウドの経済性を組み合わせながら、高可用性、クロスリージョン DR、サブミリ秒のストレージレイテンシーを提供します。 パフォーマンス: i7i.metal-24xl は最大 23% 優れたコンピューティングと 50% 低い IO レイテンシーを提供。FSx for ONTAP は最大 80,000 IOPS でサブミリ秒のレイテンシーを提供。詳細は AWS GovCloud (US) リージョンの Amazon EC2 i7i インスタンス を参照。 可用性: vSphere HA、SnapMirror クロスリージョンレプリケーション、およびオプションの Oracle Data Guard。 管理性: データベースサイズに関係なく数秒でバックアップ、クローン、復旧を行う SnapCenter。 移行の柔軟性: HCX (ライブ)、SnapMirror ( ONTAP-to-ONTAP )、PDB リロケーション (マルチテナント)、RMAN (汎用)。 セキュリティ: NSX マイクロセグメンテーション、AWS KMS 暗号化、ゼロトラストアクセス。 コスト効率: i7i による価格性能の向上、臨機応変なスループット調整、AWS Savings Plans。 このアーキテクチャは、使い慣れた VMware の運用ツールと手順を維持しながら、Oracle RAC や Data Guard の機能に類似した高可用性、クロスリージョン DR、ストレージベースのバックアップとクローンを提供します。 次のステップ このデプロイメントを始めるには: 対象リージョンに Amazon EVS 環境をプロビジョニングします。セットアップ手順については Amazon EVS ユーザーガイド を参照します。 EVS クラスターと同じ VPC およびアベイラビリティーゾーンに FSx for ONTAP ファイルシステムをデプロイします。 NFS データストアのマウント、Oracle VMDK の作成、SnapMirror DR の設定については、関連記事のステップバイステップ手順に従います。 まず非本番環境でテストし、その後本番の Oracle ワークロードを移行します。 その他のリソース Amazon EVS ユーザーガイド Amazon EVS がサポートする VCF バージョンとインスタンスタイプ Amazon EVS を使用した FSx for ONTAP Amazon EVS の料金 AWS News Blog での Amazon EVS の紹介 Amazon EVS と FSx for ONTAP における Oracle Database のデプロイステップ (関連記事) 著者について Satish Bhoi Satish Bhoi は AWS Enterprise Support のテクニカルアカウントマネージャーであり、お客様のクラウドソリューションの設計と最適化を支援しています。20 年以上の業界経験を持ち、クラウドアーキテクチャを専門とし、クラウドコンピューティングのアプリケーションを探求することに情熱を注いでいます。仕事以外では、Satish はリーグクリケットをプレイし、若い選手を指導し、旅行と冒険を楽しんでいます。 Ben Lipman Ben Lipman は、あらゆる規模の企業の仮想化、ストレージ、ネットワークを管理してきた 25 年にわたる IT インフラストラクチャエンジニアリングのバックグラウンドを持っています。過去 10 年間 AWS に在籍し、現在はワールドワイドの VMware テクニカルリーダーを務めています。 Sudhir Balasubramanian Sudhir Balasubramanian は AWS のシニア SA データベーススペシャリストであり、Oracle ACE、VMware vExpert、Nutanix NCP、スピーカー、ブロガー、著者、テクノロジスト、エバンジェリスト、パートナー＆カスタマーアドボケイトです。Sudhir は個人ウェブサイト vracdba.com で頻繁にブログを書いています。Sudhir は、お客様やパートナーと協力して、複雑な問題を解決しカスタマーエクスペリエンスを向上させる創造的なソリューションを構築することが大好きです。仕事以外では、Sudhir はハイキング、ウォーキング、料理、そしてクラシックロックとメタルを聴くことが好きです。 翻訳はソリューションアーキテクト 齋藤が担当しました。原文は こちら です。

本稿は、2026 年 10 月 2 日に公開された “ Deploy Oracle Database step by step on Amazon EVS with FSx for ONTAP ” を翻訳したものです。 この記事では、NFS データストアストレージとして Amazon FSx for NetApp ONTAP を使用して、 Amazon Elastic VMware Service (Amazon EVS) 上に Oracle Database をデプロイするためのステップバイステップの手順を紹介します。ストレージボリュームのプロビジョニング、NFS データストアのマウント、Oracle のインストール、そしてクロスリージョンディザスタリカバリのための SnapMirror レプリケーションの設定を行います。 VMware 上で Oracle データベースを稼働させている企業は、再設計や再教育を行うことなく既存の運用ワークフローを維持できる AWS への移行パスを求めています。関連記事「 Amazon EVS と FSx for ONTAP 上で高可用性の Oracle Database を設計する 」では、 Amazon Elastic Compute Cloud (Amazon EC2) ベアメタルインスタンスの選択、VM のサイジング、vSAN と FSx for ONTAP 間でのストレージの分割、クロスリージョン DR のための SnapMirror レプリケーションの計画など、環境を設計する方法を説明しました。 この記事は、アーキテクチャ編の続きです。Oracle VM のプロビジョニングと FSx for ONTAP ボリュームの作成から、NFS データストアのマウント、Oracle 19c のインストール、SnapMirror と SnapCenter の設定まで、スタック全体をデプロイするためのステップバイステップの手順を紹介します。また、既存のオンプレミス Oracle ワークロードを Amazon EVS に移行するための 4 つの移行パスと、スナップショットバックアップ、ポイントインタイムリカバリ、データベースクローニングを含む Day 2 運用についても説明します。 アーキテクチャの決定、インスタンスタイプの選択、ストレージ設計の根拠、高可用性の計画については、関連記事「 Amazon EVS と FSx for ONTAP 上で高可用性の Oracle Database を設計する 」を参照してください。 ステップバイステップのデプロイメント手順 このセクションでは、Oracle VM のプロビジョニング、FSx for ONTAP ストレージボリュームの作成、vSphere での NFS データストアのマウント、Oracle 19c のインストール、クロスリージョン DR のための SnapMirror の設定まで、エンドツーエンドのデプロイメントワークフローを説明します。まず前提条件を完了してから、ステップ 1 から 8 を順番に実行してください。 前提条件 Amazon EVS 環境がデプロイ済み (VCF 9.1、ESXi 9.1。VCF 9.x では、Amazon EVS がベアメタルインフラストラクチャと VLAN をプロビジョニングし、お客様が Broadcom の VCF Installer を使用して VCF をデプロイします)。 クラスターあたり最低 4 ホスト。Oracle には専用の DB クラスターを推奨。 Amazon VPC Route Server エンドポイント、 AWS Transit Gateway 、 AWS Direct Connect が設定された Amazon Virtual Private Cloud (Amazon VPC) 。 FSx for ONTAP プロビジョニングのための AWS Identity and Access Management (IAM) 権限。 VCF ライセンスエンタイトルメント (Broadcom からの BYOL)。 ステップ 1: Amazon EVS 上に Oracle VM をデプロイする Amazon EVS の vCenter に接続された vSphere Client にログインします。 本番 DB クラスターに新しい仮想マシンを作成します。 ゲスト OS: Red Hat Enterprise Linux 8 (64 ビット) または Oracle Linux 8 vCPU: Oracle ワークロードに応じてサイジング (一般的に 8〜32 vCPU) メモリ: SGA/PGA 要件に基づいて 32〜256 GiB ディスク: vSAN データストア上に 100 GiB (OS + Oracle Home + スワップ + 一時表領域) ネットワーク: prod-trusted Tier-1 ゲートウェイ上の DB セグメントに接続 VM の電源を入れ、ゲスト OS を設定します。 # ホスト名を設定 hostnamectl set-hostname ora-db1 # vSAN データストア上のディスクにスワップを作成 (ローカル NVMe、1 桁ミリ秒のレイテンシー) # vSAN データストアは VM のプライマリディスクとして既に利用可能 # スワップ用に専用のパーティションまたは LV を割り当て lvcreate -L 16G -n swap vgos mkswap /dev/vgos/swap swapon /dev/vgos/swap echo "/dev/vgos/swap swap swap defaults 0 0" >> /etc/fstab # Oracle の前提条件をインストール sudo yum install -y oracle-database-preinstall-19c python3 HA/DR については、DR クラスターに別途ライセンスを取得したインスタンスを維持するのではなく、Oracle VM 全体をレプリケートすることを検討してください (関連記事「 Amazon EVS と FSx for ONTAP 上で高可用性の Oracle Database を設計する 」の「DR に関する Oracle ライセンスの考慮事項」を参照)。 Oracle ライセンスに関する考慮事項: インスタンスタイプの選択は Oracle のライセンスコストに影響します。これは考慮すべき重要な要素です。さらなるガイドラインについては、 AWS Optimization and Licensing Assessment (AWS OLA) のリクエストをお勧めします。 ステップ 2: FSx for ONTAP をプロビジョニングする Amazon FSx コンソールを開き、 [ファイルシステムの作成] を選択し、 [Amazon FSx for NetApp ONTAP] を選択します。 [標準作成] を選択して設定します。 設定 値 デプロイメントタイプ シングルアベイラビリティーゾーン (AZ)。Amazon EVS では必須 SSD ストレージ容量 Oracle データ + ログ + 20% の余裕に合わせたサイズ スループット容量 512〜2,048 MB/s (書き込みワークロードに合わせたサイズ。非対称性の注記を参照) IOPS 自動 (3/GiB) またはユーザープロビジョニング (最大 80,000) VPC Amazon EVS 環境と同じ VPC サブネット Amazon EVS サービスアクセスサブネット、DB クラスターと同じ AZ セキュリティグループ Amazon EVS マネジメント VLAN からの NFS (TCP 2049、111、635) を許可 fsxadmin パスワードを設定します (ONTAP CLI 自動化に必須)。 vsadmin パスワードで SVM (Storage Virtual Machine) を作成します。 自動日次バックアップを無効にします。代わりに Oracle 対応のスケジューリングには SnapCenter を使用します。 作成後、[SVM] を選択し、[エンドポイント] を選択して、NFS DNS 名をコピーします。 ステップ 3: Oracle データベースボリュームを作成する SSH ( ssh fsxadmin@management-endpoint ) を使用して FSx for ONTAP クラスターに接続し、ボリュームを作成します。 # Oracle バイナリボリューム vol create -volume oradb1bin -aggregate aggr1 -size 50G \ -state online -policy default -tiering-policy none \ -junction-path /oradb1bin # Oracle データボリューム vol create -volume oradb1data -aggregate aggr1 -size 500G \ -state online -policy default -tiering-policy none \ -junction-path /oradb1data # Oracle ログボリューム (REDO + アーカイブ) vol create -volume oradb1log -aggregate aggr1 -size 250G \ -state online -policy default -tiering-policy none \ -junction-path /oradb1log すべてのデータを SSD 階層に固定するために -tiering-policy none を設定します。ログボリュームは 24 時間分のアーカイブログに合わせてサイジングします。 ステップ 4: vSphere で FSx for ONTAP を NFS データストアとしてマウントする vSphere Client で、[DB クラスター] を選択し、[設定] > [ストレージ] > [新しいデータストア] を選択します。 [NFS] を選択し、[NFS 3] を選択します。 以下を入力します。 サーバー: svm-id.fs-id.fsx.region.amazonaws.com フォルダー: /oradb1data データストア名: fsx-ora-db1-data バイナリ ( /oradb1bin ) およびログ ( /oradb1log ) ボリュームについても繰り返します。 3 つすべてのデータストアがクラスターストレージビューで正しい容量を表示していることを確認します。 ステップ 5: FSx for ONTAP データストア上に Oracle VMDK を作成する NFS データストアを ESXi ホストレベルでマウントした状態で (ステップ 4)、これらのデータストア上に Oracle 用の仮想ディスクを作成します。 vSphere Client で、Oracle VM を選択し、[設定の編集] を選択してから、[新しいデバイスを追加] > [ハードディスク] を選択します。 以下の VMDK を作成します。 VMDK データストア サイズ ゲストマウント 用途 Hard Disk 2 fsx-ora-db1-data 500 GiB /u02 Oracle データファイル Hard Disk 3 fsx-ora-db1-log 250 GiB /u03 Oracle REDO + アーカイブログ Hard Disk 4 fsx-ora-db1-bin 50 GiB /u01 Oracle Home バイナリ データおよびログ VMDK には Thick Provision, Eager Zeroed を選択します (Oracle でベストなパフォーマンスを得るため)。 Oracle Database は Oracle ASM またはファイルシステム (ローカル/NFS) 上に作成できます。この手順では、ローカル XFS ファイルシステム上に Oracle データベースを作成します。 Oracle VM ゲスト OS 内で、新しいディスクをパーティション分割してマウントします。 # 新しいディスクを識別 lsblk # 各ディスクにファイルシステムを作成 (例: データ用に /dev/sdb) mkfs.xfs /dev/sdb mkfs.xfs /dev/sdc mkfs.xfs /dev/sdd # マウントポイントを作成 mkdir -p /u01 /u02 /u03 # マウント mount /dev/sdd /u01 # Oracle Home (バイナリ) mount /dev/sdb /u02 # Oracle データファイル mount /dev/sdc /u03 # Oracle REDO + アーカイブログ # /etc/fstab に永続化 cat >> /etc/fstab <<EOF /dev/sdb /u02 xfs defaults,noatime 0 0 /dev/sdc /u03 xfs defaults,noatime 0 0 /dev/sdd /u01 xfs defaults,noatime 0 0 EOF # 所有権を設定 chown -R oracle:oinstall /u01 /u02 /u03 重要なポイント: Oracle VM は /u02 と /u03 にローカル XFS ブロックデバイスとしてアクセスします。基盤となるストレージが FSx for ONTAP 上の NFS データストアであることを認識していません。すべての NFS 通信は ESXi ホストレベルで行われ、各ホストは FSx for ONTAP へ個別のネットワークパスを使用します。 ステップ 6: Oracle 19c をインストールして設定する # oracle ユーザーとして export ORACLE_HOME=/u01/app/oracle/product/19.0.0/dbhome_1 cd $ORACLE_HOME ./runInstaller -silent -responseFile /path/to/db_install.rsp データを /u02 に、ログを /u03 に配置してデータベースを作成します。 CREATE DATABASE orcl DATAFILE '/u02/oradata/orcl/system01.dbf' SIZE 1G LOGFILE GROUP 1 '/u03/oralogs/orcl/redo01.log' SIZE 512M, GROUP 2 '/u03/oralogs/orcl/redo02.log' SIZE 512M, GROUP 3 '/u03/oralogs/orcl/redo03.log' SIZE 512M; Oracle は /u02 と /u03 にローカル XFS ファイルシステムとしてアクセスします。標準の Oracle ASM またはファイルシステムベースのストレージ管理が適用されます。NFS レイヤーは ESXi ハイパーバイザーによって抽象化されているため、NFS 固有の Oracle 設定は必要ありません。 ステップ 7: クロスリージョン DR のために SnapMirror をセットアップする クラスターをピアリングします (本番 → DR)。 cluster peer create -peer-addrs <dr-cluster-intercluster-ip> \ -username fsxadmin -initial-allowed-vserver-peers * SVM をピアリングします。 vserver peer create -vserver svm-prod -peer-vserver svm-dr \ -peer-cluster FSxDR -applications snapmirror DR 側の FSx for ONTAP 上に DP ボリュームを作成します。 vol create -volume oradb1bin -aggregate aggr1 -size 50G -state online -type DP vol create -volume oradb1data -aggregate aggr1 -size 500G -state online -type DP vol create -volume oradb1log -aggregate aggr1 -size 250G -state online -type DP SnapMirror を作成して初期化します。 snapmirror create -source-path svm-prod:oradb1data \ -destination-path svm-dr:oradb1data -throttle unlimited \ -policy MirrorAllSnapshots -type DP snapmirror create -source-path svm-prod:oradb1log \ -destination-path svm-dr:oradb1log -throttle unlimited \ -policy MirrorAllSnapshots -type DP snapmirror create -source-path svm-prod:oradb1bin \ -destination-path svm-dr:oradb1bin -throttle unlimited \ -policy MirrorAllSnapshots -type DP # 初期化 snapmirror initialize -destination-path svm-dr:oradb1data snapmirror initialize -destination-path svm-dr:oradb1log snapmirror initialize -destination-path svm-dr:oradb1bin 重要: DR 戦略を計画する際は、Oracle のライセンス要件を考慮してください。代替案として、NetApp SnapMirror を通じて Oracle VM を本番環境から DR にレプリケートする方法があります。Oracle の二重ライセンスを回避するため、フェイルオーバーイベントが宣言されるまで、DR のレプリケートされたボリュームを DR ホスト上で NFS データストアとしてマウントせず、データ保護 (DP) ボリュームとして保持してください。その時点ではじめて、SnapMirror を解除し、DR ホスト上で NFS データストアをマウントし、VM の電源を入れます。SnapMirror ボリュームを (VM の電源が入っていなくても) データストアとして事前にマウントすることは、それらのホスト上で Oracle バイナリがアクセス可能になることを意味し、Oracle はこれを DR クラスター全体でライセンスを必要とする「インストール」とみなす可能性があります。さらなるガイドラインについては、 AWS Optimization and Licensing Assessment (AWS OLA) のリクエストをお勧めします。 ステップ 8: SnapCenter バックアップを設定する SnapCenter Server をデプロイします (または SnapCenter SaaS を使用)。 クラスター管理 IP を使用して FSx for ONTAP ストレージシステムを追加します。 各 Oracle VM に SnapCenter Plugin for Oracle をインストールします。 バックアップポリシーを作成します。 ポリシー スコープ 頻度 SnapMirror 更新 フル DB バックアップ データ + 制御ファイル + アーカイブログ 4〜6 時間ごと はい アーカイブログ アーカイブログのみ 10〜15 分ごと はい リソースグループを作成し、ポリシーを割り当て、スケジュールを設定します。 オンプレミス VMware から Amazon EVS へのデータベース移行 オプション 1: VMware HCX ライブマイグレーション 既存のオンプレミス VMware を持つ企業向け: オンプレミスに HCX Connector を、Amazon EVS に HCX Cloud Manager をデプロイします。 サイトペアリングとネットワーク拡張 (L2 ストレッチ) を作成します。 HCX vMotion (ゼロダウンタイム) または Bulk Migration を使用して Oracle VM を移行します。 移行後: スナップショット/レプリケーション機能のために、Oracle VMDK を vSAN から FSx for ONTAP NFS データストアへストレージ vMotion します。 オプション 2: SnapMirror ONTAP-to-ONTAP オンプレミスの Oracle が既に NetApp ONTAP ストレージを使用している場合: オンプレミス ONTAP と FSx for ONTAP 間で SnapMirror を確立します。 切り替えまで増分でレプリケートします。 切り替え時: Oracle を休止し、アーカイブログをフラッシュし、最終 SnapMirror 同期を行い、ミラーを解除します。 Amazon EVS 上の Oracle VM に FSx for ONTAP ボリュームをマウントし、データベースをリカバリし、サービスを開始します。 オプション 3: Oracle PDB リロケーション (マルチテナント) Oracle データベースが既に PDB/CDB マルチテナントモデルにある場合: FSx for ONTAP ストレージを使用して Amazon EVS 上にターゲット CDB を作成します。 PDB ホットクローンを使用して、オンプレミス CDB から AWS 上の CDB へ PDB をリロケートします。 サービス中断は最小限です。最終切り替えのみ短時間の停止が必要です。 オプション 4: RMAN バックアップ/リストア (非 ONTAP オンプレミス) Oracle がオンプレミスで非 ONTAP ストレージ上で稼働している場合: RMAN バックアップを作成し、 AWS DataSync または AWS Direct Connect を使用して Amazon Simple Storage Service (Amazon S3) に一時保管します。 Amazon EVS 上に Oracle VM をプロビジョニングし、FSx for ONTAP ボリュームをマウントします。 RMAN バックアップからリストアし、アーカイブログを適用します。 データベースを開始し、アプリケーションをリダイレクトします。 Day 2 運用 スナップショットバックアップ SnapCenter は、フルデータベーススナップショットをストレージレイヤーの操作として管理し、効率的なバックアップ機能を提供します。 ポイントインタイムリカバリ SnapCenter で、SCN またはタイムスタンプを選択し、ログスナップショットをマウントし、データスナップショットをリストアし、アーカイブログを適用し、RESETLOGS で開きます。 データベースクローニング SnapCenter FlexClone は、スペース効率の良いデータベースコピーを作成します。クローンは変更されていないブロックをソースと共有し、差分に対してのみストレージを消費します。開発/テスト、パッチ検証、レポーティングに使用します。 HA フェイルオーバー手順 DR ボリューム上の SnapMirror を解除します。 SnapMirror ボリュームを DR ESXi ホスト上に NFS データストアとしてマウントし、Oracle VM の電源を入れます。 利用可能な最後のアーカイブログまでリカバリします。 データベースを開きます。DNS/接続先を更新します。 クリーンアップ このデプロイメントのテスト後に料金が発生しないようにするには、以下のリソースをこの順序で削除します。 Oracle VM — Oracle データベース VM を停止し、vSphere インベントリから削除します。 NFS データストア — vSphere で ESXi ホストから FSx for ONTAP データストアをアンマウントします。 SnapMirror 関係 — DR 側の FSx for ONTAP ファイルシステム上の SnapMirror 関係と DP ボリュームを削除します。 FSx for ONTAP ファイルシステム — Amazon FSx コンソールから本番および DR の両方のファイルシステムを削除します。この操作により、それらのファイルシステム上のすべてのボリュームとデータが削除されます。 Amazon EVS 環境 — Amazon EVS コンソールから Amazon EVS 環境を削除します。これにより、基盤となる EC2 ベアメタルインスタンスが終了します。 ネットワーキング — このデプロイメントのためだけに作成された場合は、Transit Gateway アタッチメント、VPC Route Server 設定、Direct Connect 接続を削除します。 重要: FSx for ONTAP ファイルシステムを削除すると、すべてのデータが完全に削除されます。続行する前に、必要なデータをバックアップ済みであることを確認してください。 まとめ この記事では、NFS データストアストレージとして FSx for ONTAP を使用して、Amazon Elastic VMware Service (Amazon EVS) 上に Oracle Database をデプロイする手順を説明しました。Oracle VM をプロビジョニングし、FSx for ONTAP ボリュームを作成し、vSphere で NFS データストアをマウントし、Oracle 19c をインストールし、クロスリージョンディザスタリカバリのための SnapMirror と Oracle 対応バックアップのための SnapCenter を設定しました。また、既存のオンプレミス Oracle ワークロードのための 4 つの移行パスと、バックアップ、ポイントインタイムリカバリ、クローニングのための Day 2 運用についても説明しました。 始めるには、 Amazon EVS ユーザーガイド と「 FSx for ONTAP で Amazon Elastic VMware Service を使用します 」を確認してから、Amazon EVS 上に最初の Oracle VM をデプロイしてください。このデプロイメントの背後にあるアーキテクチャの決定については、関連記事「 Amazon EVS と FSx for ONTAP 上で高可用性の Oracle Database を設計する 」を参照してください。フィードバックやご質問はコメント欄でお寄せください。 その他のリソース Amazon EVS ユーザーガイド Amazon EVS がサポートする VCF バージョンとインスタンスタイプ FSx for ONTAP で Amazon Elastic VMware Service を使用します Amazon EVS の料金 Amazon EVS の紹介 — AWS Blog 著者について Satish Bhoi Satish Bhoi は AWS Enterprise Support のテクニカルアカウントマネージャーであり、お客様のクラウドソリューションの設計と最適化を支援しています。20 年以上の業界経験を持ち、クラウドアーキテクチャを専門とし、クラウドコンピューティングのアプリケーションを探求することに情熱を注いでいます。仕事以外では、Satish はリーグクリケットをプレイし、若い選手を指導し、旅行と冒険を楽しんでいます。 Ben Lipman Ben Lipman は、あらゆる規模の企業の仮想化、ストレージ、ネットワークを管理してきた 25 年にわたる IT インフラストラクチャエンジニアリングのバックグラウンドを持っています。過去 10 年間 AWS に在籍し、現在はワールドワイドの VMware テクニカルリーダーを務めています。 Sudhir Balasubramanian Sudhir Balasubramanian は AWS のシニア SA データベーススペシャリストであり、Oracle ACE、VMware vExpert、Nutanix NCP、スピーカー、ブロガー、著者、テクノロジスト、エバンジェリスト、パートナー＆カスタマーアドボケイトです。Sudhir は個人ウェブサイト vracdba.com で頻繁にブログを書いています。Sudhir は、お客様やパートナーと協力して、複雑な問題を解決しカスタマーエクスペリエンスを向上させる創造的なソリューションを構築することが大好きです。仕事以外では、Sudhir はハイキング、ウォーキング、料理、そしてクラシックロックとメタルを聴くことが好きです。 翻訳はソリューションアーキテクト 齋藤が担当しました。原文は こちら です。

2026 年 10 月 23 日と 30 日の 2 回、「［臨時開催］FY2026 AWS セキュリティセミナー ― フロンティア AI 時代のサイバー攻撃に備える ―」をオンラインで開催しました。フロンティア AI の登場で変わりつつある脆弱性対応について、AWS が基盤側で行っている対策と、お客様の側で取り組める対策を整理してお伝えしました。本記事では 2 回の内容をまとめてご報告します。11 月からは、ここで紹介したサービスを実際に操作するオンラインハンズオンを週次で開催しています。 セミナーの概要 日時 第 1 回: 2026 年 10 月 23 日（金）11:00 – 12:30（ イベントページ ） 第 2 回: 2026 年 10 月 30 日（金）16:00 – 17:30（ イベントページ ） 形式 オンライン（座学） 対象 業界を問わず、AWS をご利用中またはご検討中のユーザー企業・団体の方 講師 中島 章博（シニア セキュリティ ソリューションアーキテクト） 関連サービス AWS WAF, Amazon Inspector, AWS Security Agent (now part of AWS Continuum), Amazon Bedrock, Amazon GuardDuty, AWS Security Incident Response, AWS Backup AWS Japan パブリックセクター技術統括本部では、2026 年 4 月からセキュリティワークショップを月 1 回開催してきました。今回は、脆弱性対応への関心が高まっている状況を受けて、業界を問わずご参加いただける臨時のセミナーとして企画しました。想定を大きく上回るお申し込みをいただいたため、同じ内容で第 2 回を追加で開催しています。 フロンティア AI で脆弱性対応はどう変わるか セミナーの前半では、最近の状況を整理しました。 AI の進化により、ソフトウェアの脆弱性を見つける作業は大きく速くなっています。守る側にとっては、これまで見つけられなかった脆弱性を先に見つけて直せるようになったということです。一方で、脆弱性の公表から修正までにかけられる時間は短くなっています。講演では、PHP の脆弱性が公表される前から悪用の試みを AWS で観測していた例や、公開から間もない脆弱性への攻撃が年々増えている傾向を紹介しました。 こうした状況では、修正パッチを定期メンテナンスの日にまとめて当てるのではなく、日常の業務として当てていく必要があります。また、入り口だけで守るのではなく、突破された場合にもすぐ気づいて被害を小さくできる構成にしておくことが大切です。 図 1: AI を使う攻撃者に備える 3 つの防御の柱 AWS が基盤側で行っていること 責任共有モデルでは、AWS は仮想化のレイヤーまでのセキュリティに責任を持ちます。講演では、その中から 3 つの取り組みを紹介しました。 AWS Nitro System : Amazon EC2 の基盤です。AWS の運用者が使えるのは運用に必要な限られた API だけで、お客様のメモリーやディスクにアクセスする機能はそもそも実装されていません。対話型のログインもできません。この仕組みは第三者機関による評価を受けており、AWS のサービス条件にも明記しています 脅威インテリジェンス : AWS のネットワークに置いたハニーポットで攻撃の通信を観測し、不正なドメインや IP アドレスへの通信をクラウド側で遮断しています。お客様が何も設定しなくても、オンプレミスにサーバーを置いた場合より多くの攻撃通信が、届く前に止まっています AI の活用 : AWS 自身も、ログの分析や脆弱性への対応に AI を使っています。基盤の脆弱性に対しては、お客様のワークロードを止めずに修正を適用できるよう設計しています 図 2: AWS Nitro System お客様の側で取り組めること 後半では、お客様の責任範囲で取り組める対策を紹介しました。脆弱性への対応は、OS、ミドルウェア、自社のアプリケーションのどのレイヤーかによって、やり方も担当者も変わります。講演ではこの違いを整理したうえで、公開 Web システムを例に、次の 4 つの対策をおすすめしました。短期的には 1〜3 を並行して進め、中期的には AWS への移行やマネージドサービスの活用で、自分たちで守る範囲を減らしていきます。 図 3: 公開 Web システムで優先する 4 つの対策 AWS WAF で入り口を守る : 修正パッチを当てるまでの間、攻撃を緩和する手段になります。AWS の脅威インテリジェンスを使ったマネージドルールも利用できます Amazon Inspector で OS とミドルウェアの脆弱性を把握する : 新しい脆弱性が公表されると、環境をスキャンし直さなくても該当するかどうかがほぼすぐに分かります。ネットワーク上の位置や攻撃コードの有無をもとに、優先して対応すべきものを示します フロンティア AI でアプリケーションの脆弱性を先に見つける : 自社のアプリケーションの脆弱性は、お客様自身で見つけて直す必要があります。方法は 2 つあります。1 つは Amazon Bedrock でフロンティアモデルを直接使い、コーディングエージェントなどのハーネスと組み合わせて調べる方法です。もう 1 つは AWS Security Agent (now part of AWS Continuum) を使う方法です。設計書、ソースコード、API の仕様を読んだうえでペネトレーションテストを行い、見つけた脆弱性が実際に悪用できるかを検証し、再現手順と修正方法までレポートします。AWS 以外の環境にも使えます マネージドサービスで管理する範囲を減らす : OS やミドルウェアのパッチ適用を AWS に任せることで、脆弱性対応にかけていた人手を、アプリケーションの開発や運用に回せます あわせて、インシデントに備えた運用とバックアップも紹介しました。 Amazon GuardDuty による検知、AWS のセキュリティの専門家が監視から復旧までを支援する AWS Security Incident Response 、本番環境から隔離して保存でき、マルウェアのスキャンもできる AWS Backup です。 まとめとして講演で強調したのは、どの対策も単独では完全ではなく、重ねることで効果が出るという点です。どこから手を付けるかを決めるために、AWS では無料のセキュリティアセスメントもご提供しています。 図 4: 公開 Web システムを守る AWS の多層防御の例 参加者からの声 アンケートでは、「タイムリーな開催だった」「自分たちが何をすればよいかが分かりやすかった」といった声を多くいただきました。一方で、「サービスの紹介にとどまらず、具体的な使い方や設定まで知りたい」「ハンズオンをオンラインでも開催してほしい」というご要望もいただいています。 このご要望を受けて、11 月からは、紹介したサービスを実際に操作するオンラインハンズオンを週次で開催しています。 次のステップ：週次のオンラインハンズオン ハンズオンでは、AWS Security Agent (now part of AWS Continuum)、Claude/GPT などのフロンティアモデルを活用したソースコードの脆弱性対策、AWS WAF、Amazon Inspector などを題材に、座学とハンズオンの 2 部構成で、ご自身の組織で試すための最初の一歩までをお伝えします。開催日程と申込ページは、次の案内ページで随時更新しています。 AWS セキュリティハンズオン連続開催のご案内 セミナーの内容を振り返りたい方や、ご自身の環境での進め方を相談したい方は、担当の AWS アカウントチームまでお問い合わせください。 著者 梅田 昌太 (Shota Umeda) アマゾン ウェブ サービス ジャパン合同会社 パブリックセクター技術統括本部 シニアソリューションアーキテクト パブリックセクターのお客様の技術支援を担当。本セミナーの企画・運営と、2026 年 4 月からのセキュリティワークショップシリーズに携わっています。