AWS（Amazon Web Service）からOCI（Oracle Cloud Infrastructure）への移行やハイブリッド化を検討する際、サービス数の多寡だけでは判断材料になりません。本記事では、AWS OCI 比較の実務的な観点として可用性設計・課金構造・ハイブリッド構成・段階的な移行ロードマップを体系的に解説します。

AWSとOCIの違いを正しく比較するための基礎知識

AWSとOCIは設計思想や用語体系に違いがあり、表面的な比較表では移行判断に直結しません。可用性・ネットワーク・課金単位という3つの土台を整理します。

リージョン・AZ・フォルト・ドメイン:可用性設計の単位が異なる

AWSではリージョンの下にアベイラビリティゾーン（AZ）が配置され、マルチAZ構成で冗長化を行うのが一般的です。各AZはリージョン内の独立したロケーションとして機能し、障害の影響範囲を分離します。

OCIではリージョンの下に可用性ドメイン（AD）があり、さらにAD内にフォルト・ドメインという障害分離の単位が3つ存在します。フォルト・ドメインのアンチアフィニティにより、同一AD内でもインスタンスを分散配置し、特定のハードウェア障害の影響を局所化できます。

AWSのAZにはこの「AD内3分割」に相当する概念がそのまま存在しないため、冗長化設計をどの粒度で組むかという前提が両者で異なります。なおOCIの東京リージョンはシングルAD構成との情報がありますが、AD構成は変動し得るため設計時にはOCI公式のリージョン情報を確認することが前提です。

VPC/VCN・サブネット・セキュリティ制御:ネットワーク設計の前提が異なる

AWSのVPC（Virtual Private Cloud）とOCIのVCN（Virtual Cloud Network）は、プライベートネットワークを構築する点では共通しています。しかしサブネットの扱いには大きな違いがあります。

AWSではサブネットが1つのAZ内に完全に存在し、AZを跨ぐことはできません。マルチAZ構成ではAZごとにサブネットを切り、ロードバランサ等でフェイルオーバーさせる設計が一般的です。対してOCIはリージョナル・サブネットを推奨しており、リージョン内の任意のADのリソースを含められる仕組みです。

セキュリティ制御もAWSのSG/NACLに対しOCIではNSG/セキュリティ・リストが対応します。制御がインスタンス単位中心かサブネット単位中心かという設計思想の差があり、移行時にはサブネット再設計やセキュリティ境界の再定義といった作業が発生します。この差は移行の工数とコストに直結する要素です。

vCPUとOCPU:課金単位を揃えないと見積もりがずれる

AWSではvCPU単位でインスタンスを比較するのが一般的ですが、OCIではOCPUという独自の単位を使用しています。OCI公式ドキュメントによるとOCPUは物理CPUコアを表し、x86プロセッサでは1 OCPUが2 vCPUに相当すると明記されています。

つまり「AWSの4vCPUインスタンス」と「OCIの4OCPUインスタンス」を単純に並べると、CPU容量が2倍異なる可能性があります。社内稟議や比較表を作成する際はCPU単位の換算を先に固定し、そのうえで性能ベンチマークと価格を照合する手順が欠かせません。

価格自体もリージョンや時期により変動するため、比較は「手順」として定型化し、最新の公式価格ページで都度確認するのが安全です。

AWSからOCIへの移行でコスト削減につながる4つのポイント

コスト削減の効果は単価比較ではなく「自社のどのコスト要因が支配的か」で判断が変わります。AWS→OCI移行で差が出やすい4つの領域を具体的に見ていきます。

アウトバウンドの無料枠はOCIが10TB、AWSは100GBと大きな差がある

OCIの公式価格ページでは、インバウンド無償に加えアウトバウンドも「リージョン・ゾーンまたは製品SKUごとに最初の10TB」が無償と明記されています。データ配信や拠点間複製、ハイブリッド構成でのデータ同期が多いシステムほどこの無料枠のインパクトは大きくなります。

AWSではインターネットへのデータ転送アウトが月100GBまで無償（全サービス・全リージョン合算、China/GovCloud除く）です。無料枠のサイズが異なるだけでなく、超過後の課金がサービスや地域により変わる点も見落とせません。

AWSは2024年3月にDTO免除プログラムを公開し、AWS外への移行時のデータ転送費用をクレジットで提供する方針を示しています。ただしこれは移行時の一時費用に効くものであり、移行後の定常コストは設計次第で変わるため「移行時」と「移行後」を分けて考えることが重要です。

NATゲートウェイなどの「見えにくい固定費」はOCIのほうが抑えやすい

AWSのNATゲートウェイは、プロビジョンして使用可能な時間ごとの課金と処理データ（GB）ごとの課金が発生します。マルチAZに配置するほど時間課金が増え、外形監視やパッチ取得、SaaS連携のような目立たない通信でもコストが積み上がる構造です。

OCI側はサイト間VPNが無償、ネットワーク・ロード・バランサも無料と公式価格ページに記載されています。NATゲートウェイの課金については一次資料で明示的な確認が取れない部分もあるため、設計時に個別確認が必要です。

ネットワーク周辺の「地味な固定費」は放置されやすく、棚卸しをしないまま移行すると削減効果を正しく測定できません。移行検討の初期段階でNATやゲートウェイ周りの課金を洗い出しておくことが、TCO比較の精度を上げるポイントになります。

閉域接続はFastConnectならデータ転送の追加課金が発生しない

ハイブリッドクラウドやマルチクラウドの中核となる閉域接続でも、課金構造に違いがあります。OCIのFastConnect（Private VC）は公式価格ページでインバウンド・アウトバウンドのデータ転送に別途料金がかからないと明記されており、主な課金対象はポート時間です。

AWS Direct Connectでは送信元リージョンや接続ロケーションに応じたDTO課金が発生します。帯域を太くしてデータを大量に動かす設計になるほど、DTOが支配的なコスト要因になり得ます。

どちらが安いかは一概に言えず、自社のトラフィックが回線内で完結するか、インターネット方向にどれだけ出るかで最適解が変わります。コスト比較では「回線そのもの（ポート時間）」「回線経由のデータ転送」「インターネット向けのデータ転送」の3層に分解して試算するのが実務的です。

OCIのUniversal Creditsは移行期のリソース変動にも柔軟に対応できる

AWSのSavings PlansやEC2リザーブドインスタンス（RI）は最大72%の割引が公式に記載されていますが、コミットメント（期間・使用量）が前提です。移行期には二重稼働やリソース変動が発生しやすく、割引モデルが十分に効かない局面が生じる可能性があります。

OCIのUniversal CreditsにはPAYG（従量課金）と年間コミットメントの2形態があり、どのOCIリージョンでも対象サービスに適用可能です。サービスやリージョンの変更にも対応できると公式ページに記載されています。

2025年10月にはMulticloud Universal Credits（クロスクラウド消費モデル）も発表され、AWS・Azure・Google Cloud・OCI間での柔軟な契約形態が登場しています。ただし適用範囲や適格条件は契約ごとの確認が前提となるため、導入前にOracle側への確認が必要です。

ハイブリッドクラウドの設計パターン:全面移行以外の現実的な選択肢

AWS→OCI移行は「全面移行か現状維持か」の二択ではありません。ワークロードごとに配置先を選ぶハイブリッド構成が、コストと運用のバランスを取る現実的なアプローチです。

選択肢①:AWSにアプリを残しOracle Database@AWSでDB基盤だけOCIに寄せる

Oracle Database@AWSは、AWSデータセンター内でOCI管理のOracle Exadata基盤によりDBサービスにアクセスできる仕組みです。2026年2月には東京リージョンでの提供開始も発表されており、オンプレのOracle ExadataやRACアプリケーションをlike-for-likeで移行できると説明されています。

アプリケーションはAWSのエコシステムを活かしつつ、Oracle系DBはOCIの強みに寄せるという分割配置により、全面移行を待たずに段階的な効果が見込めます。一方でクラウドが2つになることで監視・ID管理・鍵管理・変更管理などの運用境界が増えるデメリットもあります。AWSとの統合ポイント（KMSやCloudWatch連携）が用意されている点は確認されていますが、自社の運用体制で対応可能かの検討は欠かせません。

選択肢②:VMware資産をOCIへリフトし段階的にモダナイズする

基幹系システムやVMware基盤が残る企業では、まずVMをそのままクラウドへリフトし、その後にコンテナ化やマネージドDB化を進める段階移行が現実的です。OCIのOracle Cloud VMware Solution（OCVS）はVMwareに対するルート権限を提供し、アップグレードタイミングも任意に選択できると説明されています。

VMware Cloud on AWSでは完全な管理アクセス権が提供されない点と対比されることが多く、移行期に既存の運用手順を変えずにリフトできる場面で差が出やすいとされています。ただしルート権限を持つことは顧客側の管理範囲と運用責任が広がることも意味するため、リフト後の安定稼働を確認してからリプラットフォームやリファクタへ進むのが段階移行の基本的な流れです。

選択肢③:Dedicated RegionやCloud@Customerでオンプレ要件に対応する

データレジデンシーや低レイテンシ、規制対応などの理由でオンプレ要件が残る企業向けに、OCIはDedicated RegionやCloud@Customerを展開しています。Dedicated Regionはフルスタックの OCIを専用リージョンとして導入でき、150以上のOCIサービスが利用可能です。価格モデルもパブリックOCIと一貫している点が特徴になっています。Cloud@Customerはオンプレでのデータベース運用管理の複雑さを軽減し、自律機能を提供すると公式ページで説明されています。

AWS側もOutpostsでオンプレ拡張に対応していますが、サービス規約上Outposts利用時にはSLAが適用されない旨が明記されています。OCIは可用性に加えて管理性や性能までカバーするエンドツーエンドSLAを提供しているため、SLAの範囲をどう評価するかが選定の判断軸になります。

AWS→OCI移行を段階的に進めるロードマップ

移行を成功させるには一気に切り替えるのではなく、段階的にフェーズを踏んでリスクとコストの両方を管理する必要があります。ここでは全体像・ツール選定・DTO免除の活用を整理します。

企画から運用定着まで:5フェーズの全体像

移行ロードマップは5つのフェーズに分けて設計すると、進捗管理がしやすくなります。各フェーズの目的と主な成果物を以下に整理します。

各フェーズで「何ができたら次へ進むか」のゲート条件を設定し、成果物ベースで管理することが計画倒れを防ぐ鍵です。

AWS側とOCI側の移行ツールを対で選定する

AWS側ではMigration Hubが既存サーバの検出・移行計画・ステータス追跡を一元管理し、Application Migration Service（MGN）が移行の実行とモダナイゼーションを支援します。OCI側ではOracle Cloud MigrationsがVMware VMやAWS EC2インスタンスをOCIコンピュートへ移行するセルフサービス機能を提供しています。

Oracle DB移行で停止時間を最小化したい場合は、Zero Downtime Migration（ZDM）がOracle GoldenGateやData Pumpを活用したオンライン論理移行に対応しています。実務上の注意点として、OCI Cloud Migrationsでは複数モジュールが相互作用するためIAMポリシーの権限不足で移行が止まるケースがあります。ツール導入時にアクセス権限の確認をチェックポイントに入れておくことを推奨します。

AWSのDTO免除プログラムと90日ルールをロードマップに組み込む

AWSは2024年3月にDTO免除プログラムを発表し、AWS外への移行時のデータ転送費用をクレジットで提供しています。2025年9月のアップデートでは「利用者は90日で移行完了」「追加日数が必要なら速やかにサポートへ連絡」「従来あった100GB以上のDTO条件を削除」といった運用条件が追記されました。

このプログラムを活用する場合は、移行に必要なデータ量と90日という期間を前提にWave計画を組む必要があります。90日を超える見込みがあるなら、ロードマップのゲート条件に「申請・承認・期間管理」を含めておくとリスクを抑えられます。

DTO免除は移行時の一時費用に効くものであり、移行後の定常コスト最適化はOCIのアウトバウンド10TB無償枠やFastConnect Private VCの課金構造など設計上の工夫で対応する領域です。「引越しコスト」と「住んでからのコスト」を分けて計画に落とし込むことが、ロードマップの精度を高めます。

まとめ:AWS OCI比較のポイントと移行判断の進め方

本記事では、AWSとOCIの比較を可用性設計・ネットワーク課金・閉域接続・割引モデル・ハイブリッド構成・移行ロードマップの観点から整理しました。

• 可用性・ネットワーク・課金単位の前提が異なり、移行時にネットワーク再設計が必要
• vCPUとOCPUの換算（1 OCPU＝2 vCPU）を先に固定してから見積もりを行う
• アウトバウンド転送と閉域接続の費用構造がコスト削減の主な源泉
• ワークロード別の最適配置によるハイブリッド構成が現実的な選択肢
• DTO免除プログラム（90日ルール）を前提にWave方式でロードマップを設計する

AWS OCI 比較の本質は「どちらが優れているか」ではなく、自社のワークロードとコスト構造に対してどちらが合理的かを判断することにあります。本記事で整理した比較軸と移行の進め方を、自社の検討材料として活用してください。