4
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

【保存版】AWS・OCI使い分けガイド2025|料金比較表とクラウド選定6つのポイント

Last updated at Posted at 2025-07-23

目次

1.マルチクラウド時代の到来
2.料金モデルの整理
3.負荷パターンで優位が逆転
4.転送量100GBが分水嶺
5.マネージドDB&API基盤
6.ミニケーススタディ
7.失敗しないクラウド選定のポイント6選
8.まとめ

1:マルチクラウド時代の到来

2025年、クラウドの需要はますます高まっています。
「そろそろクラウドを導入してみようかな」と考えている方も多いのではないでしょうか。

でも、そんなときに一度はこんな疑問を持ったことがありませんか?

「結局、どのクラウドを選べばいいの?」

この悩み、実はとてもよくあるものです。

なぜなら、現代のクラウドは「とりあえずこれを選べばOK!」という時代ではなくなってきているからです。

以前ならAWSを選んでおけば間違いがないといった選び方もありましたが、今は目的に応じて選ぶのが正解です。

クラウドごとに得意・不得意があるからこそ、しっかり特徴を理解して使い分けることが大切になってきています。

今回は、その比較として「AWS」と「OCI」という、少し意外に思えるかもしれない組み合わせを選びました。

なぜAzureやGCPではなく、あえてこの2つを選んだのか?

まずAWS(Amazon Web Services)は、クラウドの世界で圧倒的なシェアと実績を持つ王道の存在です。200以上のサービスを持ち、どんな用途にも柔軟に対応できる万能なクラウドサービスです。

一方、OCI(Oracle Cloud Infrastructure)は、知名度こそAWSほどではありませんが、最近注目を集めています。特に、ネットワーク転送コストの安さやシンプルで予測しやすい料金体系が支持されており、「コストを抑えたい」「料金の見通しを立てたい」という企業や開発チームに選ばれ始めています。

今回の比較は「豊富な機能と安心感」のAWSと「高コスパで注目度上昇中」のOCIをあえて並べて比べてみることで、ちょうどいい選び方が見えてくる…
そんな狙いがあります。

実際にこの2つをうまく組み合わせれば、クラウド利用コストを30〜50%も削減できる可能性もあります。

そこで本稿では、2025年1月時点の東京リージョン(AWS: ap-northeast-1/OCI: ap-tokyo-1)を対象に、オンデマンド価格と主要な割引プログラムを踏まえながら、次の3つの分野に焦点を当てて比較・検証していきます。

コンピュート(仮想マシンなど、クラウドの「頭脳」にあたる部分)
ストレージ+ネットワーク(データの保存とやりとりに関するコスト)
マネージドサービス(DB・API・監視など、日々の運用を支えてくれる仕組み)

⚪︎こんな人におすすめ

・クラウド導入を検討しているけれど、どれを選べばいいか迷っている人
・効率的なクラウド活用に関心のある人
・クラウドに詳しくはないけど、ちゃんと判断したい

2.料金モデルの整理

クラウドの料金は、ぱっと見では分かりづらいですよね・・・

私自身も初めてクラウドを触ったとき、「結局いくらかかるの?」と頭を抱えた覚えがあります。

でも、実は使い方次第で大きく変わるのがクラウド料金の特徴です。

ここでは、AWSとOCIの代表的な料金プランを比較してみましょう。

①AWSの料金モデルは選択肢は豊富。でも迷子になりやすい

AWSはとにかく柔軟。ですがその分、「選び方が分かりづらい」と感じる人も多いと思います。

オンデマンドは使った分だけ払う一番シンプルな仕組み。まずはここから。

Savings Plansを1年または3年の利用をコミットすることで、オンデマンド料金から大幅な割引が適用されます。3年契約の場合、最大で72%OFFになることもあります。

Reserved Instancesは特定の仮想マシンを長期間予約して大きくコストを下げる。

Spotは空いてるリソースを使えば超格安だけど、いつ落とされるか分からない不安定さあり。

無料枠も提供されており、サインアップ後12ヶ月間有効なものに加え、LambdaやDynamoDBなど一部のサービスには、期間無制限で利用できる「常に無料」の枠もあります。 これらを活用すれば、小規模な本番運用でもコストを抑えることが可能です。

②OCIの料金モデル:シンプルで見通しが立てやすい

一方のOCIは、料金体系がとてもスッキリしています。

「ややこしくて面倒!」という方にはこちらがフィットすることが多いです。

オンデマンド:AWS同様、使った分だけ支払い

Committed Use(1〜3年)は使う予定の分だけ事前にコミットしておくと、大幅な割引が受けられます

Flexible Universal Creditsはまとめて購入したクレジットを好きなサービスに使える、ちょっとユニークな仕組みです

無料枠もかなり豪華で、30日間の300ドル(約45,000円)分のお試しクレジットに加えて、VMやAutonomous DBのAlways Free(永久無料)枠もあるので、「とりあえず触ってみたい」人にはうってつけです。

⚪︎オンデマンド単価だけで比べると、判断を誤る

数字だけを見て「AWSは高い、OCIは安い」と決めるのはちょっと危険かもしれません。

実際には、長期契約やスポット活用で30〜70%もコストを圧縮できる余地があるからです。

なので、最初はオンデマンドで軽く試して、感触が良ければ割引プランに移行するという流れがおすすめです。

焦っていきなり長期契約に飛び込むより、まずは小さく始めて学びながら判断しましょう。

最初から完璧を求めなくてOKです。

3.コンピューティング(負荷パターンで優位が逆転)

クラウドを選ぶとき、多くの人が気にするのが仮想マシン(=コンピュート)の料金だと思います。

でも実はこれ、「どのクラウドが安いか?」ではなく「どんな使い方をするか?」で運用が変わります。

ここでは、よくある3つの利用パターンをベースに、AWSとOCIの“どちらが得か”を比較してみます。

①可変負荷・短時間ジョブ → AWSが有利


開発環境/バッチ処理の検証/週末だけ動くツール系

こうした「一日中フル稼働しない」「ピーク時間だけ使う」ようなケースには、AWSが得意とする柔軟なスケーリングと割引オプションが効いてきます。

t4g.medium(2vCPU / 4GB)で月額約3,360円

CPUクレジットが枯渇しにくく、ちょっとしたライトワークロードには最適

さらにSavings Plans(1年・前払い)を適用すると、34%以上の割引も可能に

リズムのある使い方はAWSに向いているという実感がある印象です。

②常時稼働・安定負荷 → OCIが圧倒的に安い

比較例
AWS m6i.large(2vCPU / 8GB)……約12,300円/月
OCI VM.Standard.E4.Flex(1 OCPU / 8GB)……約4,200円/月
※注:OCIの1 OCPUは2vCPUに相当するため、CPUリソースを揃えて比較しています。

この差は、実に65%以上。Savings PlansやRIを適用していないオンデマンド料金で比較すると、OCIのコスト優位性が際立ちます。

③HPC/Arm系のワークロード → ネットワーク次第


機械学習/レンダリング/高並列なシミュレーション処理

AWSのGraviton3(c7g)とOCIのAmpere(A1)は、どちらもArmアーキテクチャベースの高効率CPU。性能・価格ともにかなり拮抗しています。

ただし、HPC領域ではネットワークがボトルネックになることが多く、ここで差が出ます。

AWSはEFA(Elastic Fabric Adapter)、OCIは標準的なRDMA over Converged Ethernet (RoCE v2) を通じて、それぞれHPC向けの高性能クラスタネットワークを提供します。どちらもノード間通信のレイテンシを劇的に削減するRDMA技術を利用しており、AWSは独自プロトコル(SRD)、OCIは業界標準プロトコルを採用しています。アプリケーションの要件や既存ライブラリとの互換性に応じて選択することが重要です。

⚪︎サーバは“何を動かすか”で選ぼう

平日昼間だけの開発用途 → AWSの方が割安で柔軟

24h稼働の本番環境でRI未契約 → OCIの方が明らかに低コスト

高性能演算やスパコン級の計算 → ネットワーク要件で選ぶのが正解

どちらが正しいかではなく、どちらが自分のワークロードに合っているかがクラウド選定の軸となります。

まずは現状のCPU利用率と稼働パターンを確認するところから始め、これが分かると、コストも設計も一気にクリアになってきます。

4.ストレージ&ネットワーク(転送量100GBが分水嶺)

クラウドを使い始めてしばらく経つと、ふと気づくことがあります。

「あれ?サーバ代はそんなに使ってないのに、なんでこんなに請求が高いの?」

実は、ストレージと転送料金がじわじわ効いてくるんです。

最初はあまり意識されにくいのですが、運用が軌道に乗った後にじわじわ財布を圧迫する“隠れコスト”の代表格です。

ブロックストレージ(汎用 SSD)
・AWS gp3…………………14 円/GB・月
・OCI Balanced…………… 6 円/GB・月

一見すると小さな差に見えるかもれませんが、これが数百GB、数TBともなるとかなり効いてきます。OCIのストレージは価格が明快で、とりあえず大きめに取っておこうという使い方でも安心感があります。

オブジェクトストレージ(標準ティア)
・S3 Standard………………3.8 円/GB・月
・OCI Object Storage………1.8 円/GB・月

画像、動画、ログファイル、バックアップなど、日々の運用で溜まり続けるデータたち。

これらを置くオブジェクトストレージの価格も、長期運用になればなるほど差が広がっていきます。

「とりあえずバックアップはS3に放り込んでおくか」と思っていたら、半年後に予想外の出費に驚いたというのも、よくある話です。

インターネット・アウトバウンド(東京リージョンからの転送)
・最初の100GB/月まで: AWS 0円 / OCI 0円(10TBまで無料)
・100GBを超え10TB/月まで: AWS 約13.5円/GB($0.09/GB) / OCI 0円(10TBまで無料)
・1TB(1024GB)/月 利用した場合: AWS 約12,474円((1024-100)GB × 約13.5円) / OCI 0円

OCIの月10TBまで無料というのは正直破格です。

AWSだと100GBを超えたあたりから、転送するたびに「これお金かかってるなぁ…」という感覚になります。

事例として、動画配信系の案件で、AWSの転送コストが、OCIへの一部移行だけで40%近く削減できたという声もあります。

参考資料
https://blogs.oracle.com/oracle4engineer/post/customer-reference-clinks

5.マネージドDB&API基盤

(前提:2 vCPU/16 GB、ストレージ 200 GB)

クラウドを本番運用で使うときに避けて通れないのが、データベースとAPIの設計です。

しかも、この分野は「選び方ひとつでチームの運用負荷がガラッと変わる」ので、私は常に慎重に比較するようにしています。

「DBくらい自前で構築すればいいんじゃない?」という声もあります。

でも、実際にやってみるとバックアップ・監視・障害対応・スケーリングの見極めなど、地味だけど厄介なタスクが山のように出てきます。

そこで鍵になるのが、マネージドサービス。
料金は多少上がっても、「面倒な部分はクラウドに任せる」という選択は、結果的にチーム全体の負担をぐっと減らしてくれます。

MySQL 系(前提:高可用性構成、2vCPU/16GBメモリ相当、200GBストレージ)
・AWS RDS for MySQL (Multi-AZ, db.m6i.large, 200GB gp3): 約 45,000 円/月
・AWS Aurora MySQL (1リーダー/1ライター, db.r6g.large, I/O料金は別途): 約 38,000 円/月~
・OCI MySQL Database Service (HA構成, MySQL.VM.Standard.E4.2.16GB, 200GBストレージ): 約 35,000 円/月
※上記は東京リージョン、2025年1月時点のオンデマンド料金に基づく概算です。特にAuroraはI/O利用量で料金が大きく変動するため、あくまで参考値です。このように、DBの料金は構成によって大きく変動するため、必ず自身の要件で試算することが不可欠です。

Oracle Database 系
・既存ライセンスを BYOL する場合、OCI の方がライセンス管理がシンプル。AWS 上の Oracle ではライセンス条件に注意。

API Gateway(100 万リクエストあたりの従量課金)
・AWS HTTP API(Regional)……約155円 ※最初の100万リクエスト/月は無料
・AWS REST API(Regional)……約540円 ※無料利用枠なし
・OCI API Gateway………………約 47 円

⚪︎コストと柔軟性、どちらに軸足を置くか?

DBやAPIは、使い方のクセが出やすい領域です。

機能だけでなく、どれだけ運用から自由になれるかを考えると、答えは意外とシンプルに見えてきます。

6.ミニケーススタディ

どれだけ性能がよくても、どれだけ安くても、自分のサービスやシステムに合ってなければ意味がありません。

ここでは、私が実際のプロジェクトで見聞きした構成や、よくあるユースケースをベースに、AWSとOCIどちらがフィットしやすいか?を比較してみます。
「うちのサービス、これに近いな」という視点で見てもらえると、きっと選定のヒントになります。

ケースA

イベントドリブンSaaS(API 300万回/月、転送 80GB)
構成例:Lambda/DynamoDB/EventBridgeなどのサーバレス構成

このような構成は、AWSの独壇場といっても過言ではありません。

Lambda、DynamoDB、EventBridgeの連携はスムーズだし、無料枠やスケーラビリティの強さがそのままコスト効率に直結します。

転送量も月80GBならAWSの無料枠に収まるので、ネットワークコストもほぼゼロ。

▶︎ 総合的に見て、AWSの方が15〜25%程度安くなるケースが多いです。

開発スピード、機能の充実、拡張性の3拍子が揃ってるので、「時間とお金、両方を節約したい」スタートアップに特におすすめです。

ケースB

動画配信バックエンド(転送 5TB/月、VM常時稼働)
構成例:常時稼働VM×4台+オブジェクトストレージ+CDN

このように「データをガンガン外に出す」「サーバもずっと動かしっぱなし」という構成だと、ネットワークコストが肝になります。

AWSでは5TBのアウトバウンド転送でざっくり6〜7万円程度の通信料が発生することも。
一方OCIは10TBまで無料なので、同じ使い方でも通信費がゼロ。

VM自体のコストもOCIの方が安く、Savings Plans未契約ならOCIが約40%コスト安という結果になることが多いです。

▶︎ ただし、CDNをうまく使って転送を1TB以下に抑えれば、AWSでもそれなりに戦えます。

「最初はAWSで始めたけど、CDN活用にも限界があってOCIに乗り換えたら一気に請求が軽くなった」というケースもありました。

ケースC:基幹系Oracle DB+BI(オンプレ連携あり)
構成例:Oracle Enterpriseライセンス/オンプレとクラウドの専用線接続(DXやFastConnect)

このケースでは、迷わずOCIを推します。理由は明快です。

OracleライセンスのBYOL(持ち込み)が分かりやすく柔軟

Autonomous DBの導入で、運用・バックアップ・スケーリングが自動化

FastConnectを使えば、オンプレとの安定した低レイテンシ接続が確保できる

AWS上でもOracleは動きますが、ライセンス制約や構成の煩雑さがネックになりがちです。OCIは“Oracleの本家クラウド”だけあって、最適化のレベルが違います。

▶︎ BYOL減免+自動化で運用コストを大幅に削減できるのがOCIの強みです。

⚪︎「どのクラウドがいい?」ではなく「自分に合ってるのはどっち?」

このケーススタディから見えてくるのは、クラウド選定には絶対解はなく、ユースケースごとの最適解があります。

開発スピード&サーバレス重視 → AWS
転送量・常時稼働・低コスト運用 → OCI
Oracle資産の活用&BI基盤構築 → 断然OCI

「うちの使い方って、どのパターンに近いかな?」と自問してみること。
それが、クラウド選定の第一歩です。

7.失敗しないクラウド選定のポイント6選

ここまで読んで、なるほど、AWSにもOCIにもそれぞれ良さがあるのはわかったけど、結局うちの場合はどっちを選べばいいの?という悩みが、きっと出てくると思います。

正直、それこそがクラウド選定の一番むずかしいところです。

ここでは、私が実際のプロジェクトで使っている選定チェックリストを元に、AWSとOCIの判断材料を6つの視点で整理してみます。

①年間データ転送量(100GBを超えるか)

データ転送料金はクラウドコストの隠れた落とし穴です。特に100GBを超える場合、AWS と OCI で大きな差が生じます。

AWS の場合
最初の100GB/月まで約$0.09/GB、それ以降は段階的に安くなるものの、大量転送時のコストは無視できません。

OCI の場合
毎月10TBまで無料、これは年間120TBに相当し、多くの企業にとって十分な容量です

判断基準
動画配信、大規模なログ収集、バックアップデータの外部転送などがある場合は、OCI が圧倒的に有利です。

②コンピュート稼働パターン(変動か常時か)

ワークロードの特性によって、最適な料金体系が異なります。

変動が大きい場合
AWS のオートスケーリングとスポットインスタンスの組み合わせが威力を発揮

常時稼働の場合
OCI の Compute インスタンスは同等スペックで AWS より20-30%安価

判断基準
ECサイトのセール期間、バッチ処理、開発環境など、利用パターンを明確にすることが重要です。

③Savings Plans/Committed Use を既に適用しているか

既存の割引契約は移行判断に大きく影響します。

AWS Savings Plans:1年または3年契約で最大72%割引
OCI Universal Credits:年間コミットメントで大幅割引

判断基準
契約期間が残っている場合、早期移行はかえってコスト増になる可能性があります。契約更新のタイミングで再評価するのが賢明です。

④Lambda/DynamoDB/Kinesis など AWS 固有サービスの依存度

これらのマネージドサービスは AWS のエコシステムに深く統合されており、移行には再設計が必要です。

高依存度の場合
アーキテクチャ変更のコストとリスクを考慮すると、AWS に留まるのが現実的

低依存度の場合
OCI への移行や、マルチクラウド構成の選択肢が広がります

判断基準
サーバーレスアーキテクチャやイベントドリブン設計を多用している場合は、AWS の優位性が高いです。

⑤Oracle DB/Analytics Cloud など OCI 固有サービスの依存度

なぜ重要か?
Oracle 製品を使用している場合、OCI での運用には明確なメリットがあります。

Oracle Database:OCI では自動チューニング、高可用性構成が標準装備
ライセンスの移行:既存の Oracle ライセンスを OCI で有効活用可能(BYOL)

判断基準
Oracle 製品への投資が大きい企業は、OCI への集約でライセンスコストとパフォーマンスの最適化が期待できます。

⑥オンプレ接続と多リージョン要件

ネットワーク構成はクラウド選定の重要な要素です。

オンプレ接続
AWS:Direct Connect は接続ポイントが豊富
OCI:FastConnect は料金が比較的安価

多リージョン展開
AWS
30以上の地理的リージョンを持ち、各リージョンで提供されるサービスの網羅性と成熟度に強みがあります。

OCI
リージョン数は45以上とAWSを上回る勢いでグローバル展開を進めていますが、新しいリージョンでは利用できるサービスが限定的な場合があるため、要件とするサービスが提供されているかの確認が必要です。

8.まとめ

ここまで、AWSとOCIの料金体系・性能・ユースケースを比較しながら、どちらがどんな場面に強いのかを見てきました。

クラウド選定は、「どっちがいいか」ではなく、「どう使えば、自分たちにとってベストか?」を考えることが重要です。

⚪︎判断を“感覚”から“確信”に変えるための3ステップ

① AWS Pricing Calculator/OCI Cost Estimatorに実際の構成を入力

「使いそうなインスタンス」「保存データ量」「転送量」などを入れて、リアルな見積もりを作るだけで世界が変わります。

→ 目安で語るより、自分たちの構成で“数字”を見ることが何より説得力があります。

② 割引適用後の金額も含めて比較する

オンデマンドだけで比べるのではなく、Savings PlansやCommitted Useを適用したときの金額も出してみましょう。

→ 割引を前提に設計している人ほど、AWSの方が安くなるかもしれないという逆転パターンに気づきます。

③ 小さなPoC(概念実証)で実際に動かしてみる

どんなに資料を読み込んでも、触ってみないとわからないことは必ずあります。

ネットワークのレイテンシやAPIの反応速度、管理画面の使いやすさ、監視のしやすさなど「技術と運用の相性」こそ、現場の納得感に繋がってきます。

クラウド選びに万能な正解はありません。
でも、用途に応じて最適な選択をすることは、誰にでもできます。

「うちはAWSでいいや」「コストが厳しいからOCIにしよう」など、どちらか一方に決めてしまう前に、様々なクラウドの特徴を知ったうえで、どう組み合わせるかを考えることが、これからのクラウド活用の近道です。

その選択が、きっとチームの余白と未来の柔軟性につながっていきます。

今回の記事がクラウド選びの参考になると幸いです。

ご覧いただきありがとうございました。

4
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
4
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?