3
2

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年版】

Posted at

1.はじめに

AWSでの開発や運用経験はあるけれどOCIはどんな感じなんだろう?と思っている方も多いのではないでしょうか。

私は最近になってOCIに触れる機会があり、はじめはAWSと似ているようで違う部分に戸惑いながらもOCIならではの良さを発見することができました。
最初は「Oracleのクラウドでしょ?DBだけ強いんでしょ?」と思っていましたが、触ってみたら意外と使いやすくてAWSとは違う設計思想が面白いと感じました。

この記事ではAWS経験者の視点からOCIの特徴や思想の違いをざっくりと整理して、
「ここが違う」「ここが新鮮」というポイントを中心に解説します。

2.AWSとOCIの全体的な思想とアーキテクチャの違い

AWSは2006年にクラウドサービスを開始しており豊富なユースケースへの対応力を武器に300以上のサービスを展開しています。
ビルディングブロック型の思想は柔軟性が高く、その高いシェア率からもクラウドの代表格と言える存在です。

一方でOCIは2016年に登場した後発のクラウドサービスですが、エンタープライズ分野のクラウドサービスに早くから取り組んでいました。
OCIは「DB界の巨人」と呼ばれるOracleが、DB分野の強みとエンタープライズのノウハウを活かし、エンタープライズ向け統合プラットフォームの思想が色濃く反映されています。
高いパフォーマンスとセキュリティ、シンプルな料金形態を重視した構成が特徴で、特にOracle製品との親和性は強みです。

「10年遅れではなく、10年分のニーズと課題を研究し尽くして登場したのがOCI」
という視点で見ることで、AWSとは異なるベクトルでの信頼性と価値が見えてきます。

サービス名とUIの比較

OCIを触っていて一番最初に感じたのは、サービス名とUIの分かりやすさです。
それぞれの実際のサービス名を照らし合わせてご紹介します。

代表的なサービス名

機能 AWS OCI
仮想マシン EC2 Compute
オブジェクトストレージ S3 Object Storage
仮想ネットワーク VPC Virtual Cloud Network
ロードバランサー ELB/ALB/NLB Load Balancer

OCIのサービス名は機能がそのまま名前になっているため、何をするサービスなのかが直感的にすぐに分かります。 ここは初学者の方にとっては大きなプラス要素だと感じました。

UIの階層構造

前述した思想の違いはコンソールでもわかりやすく可視化されています。
それぞれを見てみましょう。

↺AWS AWSマネジメントコンソールではサービスがカテゴリごとに整理されています。
そのカテゴリがより多岐にわたるため、主要なカテゴリに絞って整理してみます。

AWSコンソール
メニュー
├── コンピュート
│   ├── EC2(インスタンス、イメージ、ボリューム)
│   ├── Elastic Beanstalk(デプロイ簡素化)
│   ├── Lambda(サーバーレス関数)
│   └── Lightsail(必要機能をパッケージ化)
├── ストレージ
│   ├── S3(オブジェクトストレージ)
│   ├── EBS(ブロックストレージ)
│   ├── EFS(ファイルストレージ)
│   └── FSx(マネージドファイルシステム)
├── ネットワーキング & コンテンツ配信
│   ├── VPC(仮想プライベートクラウド)
│   ├── Elastic Load Balancer(ELB)
│   ├── Route 53(DNS管理)
│   ├── CloudFront(CDN / キャッシュ)
│   └── Direct Connect(専用回線接続)
├── データベース
│   ├── Amazon RDS(リレーショナルデータベース)
│   ├── DynamoDB(NoSQLデータベース)
│   ├── ElastiCache(インメモリデータベース)
│   ├── Redshift(データウェアハウス)
│   └── Aurora(高性能RDBサービス)
└── セキュリティ & アイデンティティ
    ├── IAM(ユーザーとアクセス管理)
    ├── AWS Organizations(マルチアカウント管理)
    ├── Certificate Manager(証明書管理)
    └── Key Management Service(KMS / 暗号鍵管理)

❍OCI OCIも同様にそのサービスをカテゴリ別にまとめたフレームワークを持っています。
サービス名がそのままになっているものが多いため、迷うことなく目的のページに行くことができます。

OCIコンソール
メニュー
├── コンピュート
│   ├── Compute(インスタンス管理)
│   ├── Custom Images(カスタムイメージ管理)
│   ├── Boot Volumes(ブート・ボリューム)
│   └── Container Instances(サーバーレスコンテナ)
├── ストレージ
│   ├── Block Volumes(ブロックストレージ)
│   ├── Object Storage(オブジェクトストレージ)
│   ├── File Storage(ファイルストレージ)
│   └── Archive Storage(コールドストレージ)
├── ネットワーキング
│   ├── Virtual Cloud Network(VCN / 仮想クラウドネットワーク)
│   ├── Load Balancers(ロード・バランサ)
│   ├── DNS Zone Management(DNS管理)
│   └── FastConnect(専用回線接続)
├── データベース
│   ├── Oracle Autonomous Database(自律型データベース)
│   ├── Exadata Database(高速データベース)
│   ├── MySQL Database Service(マネージドMySQL)
│   └── NoSQL Database(NoSQLデータベースサービス)
└── セキュリティ & 管理
    ├── IAM(アイデンティティとアクセス管理)
    ├── Bastion(セキュアな管理アクセス)
    ├── Vault(暗号鍵管理)
    └── Cloud Guard(セキュリティ監査 & 修正)

AWSはサービス数が豊富で細かなカスタマイズが可能です。
しかしその分、UIが少し複雑になることもあります。
一方でOCIはOracleデータベースの強力なサービスを中心に設計されており、わかりやすく整理されているUIのシンプルさが際立っており魅力的です。

3.OCIを使ってから私がオススメしたくなった機能3つ

実際に触ってみると良い意味で「思っていたのと違うな」と感じた機能がいくつかありました。
ここではOCIを使って、これはオススメしたいと感じた機能を3つピックアップしてご紹介します。

①分かりやすくて強力なコンパートメントという概念

直訳すると「仕切った区画」という意味で、リソースを管理するハコと考えればわかりやすいと思います。
1つのアカウントの中にハコを作ってそれぞれを管理していくイメージです。

# AWSのアカウント/組織構造
Root Account
├── AWS Organizations(組織)
├── アカウントA(開発)
│   └── IAMポリシー + タグ
├── アカウントB(本番)
│   └── IAMポリシー + タグ
└── Shared Services アカウント

# OCIのコンパートメント構造
テナンシ (≒ AWSアカウント)
└── ルート・コンパートメント
    ├── コンパートメントA(開発)
    │   ├── ネットワーク-1
    │   ├── 仮想マシン-1
    │   └── データベース-1
    └── コンパートメントB(本番)
        ├── ネットワーク-2
        └── 仮想マシン-2

リソースの権限を階層的(ネスト)に管理でき、アクセス制御や予算管理の単位として機能します。
AWSでは、同様の管理を「Organizations」「Resource Groups」「タグ」などを組み合わせて実現する必要がありますが、OCIではコンパートメント1つで階層構造、権限管理、コスト管理が統合的に行えるため、大規模な組織でもシンプルに管理できる点が特徴です。

1つのテナンシ内で論理的に分離していく管理方法が基本となります。
ただし大規模な組織やコンプライアンス要件によっては、複数テナンシでの管理が必要な場合もあります。
例えば子会社ごとに完全に分離したい場合や、地理的な規制要件がある場合などです。
多くの中小規模のプロジェクトでは、コンパートメントによる分離で十分な管理が可能です。

②セキュリティに対する基本的なアプローチの違い

AWSとOCIでは、インスタンス作成時のセキュリティ設定に違いがあります。
それぞれのデフォルト設定の違いを簡単にまとめて特色を挙げてみます。

↺AWS 利便性と自由度が高い

  • デフォルトセキュリティグループ(SG)→SSH許可
  • パブリックIP→自動割り当て可能
  • IMDS→v1が有効(v2も選べるが手動対応)

❍OCI ガードが堅く安全性重視

  • デフォルトセキュリティリスト(SL)→SSH不可(自分で設定が必要)
  • パブリックIP→明示的に指定が必要
  • IMDS→v2が有効(v1は手動設定が必要)

AWSは即時利用の利便性が非常に高い設計になっており、柔軟な分だけ意図せぬ公開設定になっていることもあるため最初の構築時に注意が必要です。
一方でOCIは初期状態のセキュリティが厳格なため、構成時に多少の手間がかかるもののリスクを未然に防ぐ設計となっています。
最初は設定の手間が少しあると感じますが、不用意な公開状態を防げるためセキュリティ重視の環境では安心です。

③課金方式から見えるクラウド運用のコスト設計の考え方

クラウドの料金体系は運用設計に大きな影響を与える要素です。
最適な選択ができればコストを大幅に抑えられますが、複雑さに悩まされる場面も多く感じます。
「コスト部分に関しては最後までわからない」という経験があるのは私だけではないと思います。
ここでは課金方式の軸という観点からコスト設計の違いにスポットライトを当ててみます。

↺ AWS 最適化を極めれば安くなる「パズル型」

  • オンデマンド(使った分だけ)
  • リザーブドインスタンス(1年/3年の長期契約)
  • Savings Plans(使用量コミット型割引)
  • スポットインスタンス(余剰リソースの格安利用)

まるでパズルのピースをはめていくかのように、自身で居心地の良いところを探せる多彩な選択肢があります。
多種多様な選択肢があるため組み合わせによってコスト削減をし最適化できる反面で、それぞれの条件や制約を理解するには手間がかかります。
Cost Explorerなどのツールも用意されていますが、実際の請求額を正確に予測するのは難しいのが現状です。

❍ OCI 分かりやすさを重視した「定食型」

  • Pay As You Go(使った分だけ)
  • Monthly Flex(月額コミット)
  • Annual Flex(年額コミット)
  • プリエンプティブル・インスタンス(余剰リソースの格安利用)

OCIはわかりやすさを重視し選択肢を絞られているので視認性が高く、シンプルな設計のため悩む余地がありません。
特に伝えたいのは他の記事でも書かれているデータ転送料金の安さです。
OCIのリージョン間転送コストはAWSのおよそ1/10に抑えられており、高頻度で大容量のデータを扱うシステムにおいては驚くほど料金差が出ることもあります。

4.実際に数か月使ってみた感想

私が実際に使ってみて感じた良かった点と、少し気になった点をそれぞれ分けてまとめてみます。

良かった点

・コンソールがシンプルで分かりやすい
設計思想とアーキテクチャの部分でも記載しましたが、サービス名と機能がお互いに寄り合っているので初見でも迷う時間が少なかったように感じます。
特にネットワーク周りは視覚的にも整理されているため、設定をする際の導線がハッキリしています。
必要な機能に対して素早くアクセスできるということがストレスなく、かつ触っていて楽しいと思えることに繋がると実感しました。

・Always Freeは懐が広い
インスタンス性能などに制限はありますが永久無償で使用できるのは本当にすごいと思います。
初学者の方や個人開発、PoCなどには十分に使える内容になっています。
※「登録してから30日間」もしくは「$300まで使用可能」なFree Tierというサービスもあります。

・全体的に見てコストが割安
月に10TBまでのアウトバンド通信が無料となっており、外部転送コストの他にストレージ関連も比較的安価になっている印象です。
課金方式がわかりやすいことも触っていて安心感に繋がります。

少し気になった点

・エコシステムが物足りない
主要なサービスはAWSと同等ですが、人によっては一部の選択肢が少ないと感じられるかもしれません。
しかし基本的にはREST APIなどは整備されているのでどうにかなるというレベルです。
またOCIではTerraformによるIaC対応も充実しており、AWSに比べるとやや手間に感じてしまうかもしれませんが管理も問題なく可能です。

・日本のコミュニティがまだ成長段階
国内のOCIコミュニティは成長段階にあり、AWSと比較すると技術ブログや事例記事の数は少ない傾向にあります。
ただし、Oracleが提供する日本語ドキュメントは充実しており、公式のチュートリアルやベストプラクティスガイドも整備されています。
また、Oracle主催のハンズオンセミナーや、パートナー企業による技術支援も活発に行われています。

これは不便に感じる反面、視点を変えるとアーリーアダプターとしての先行者優位にもなり得ます。
OCIを扱えるエンジニアの数はまだ多くなく、今から専門性を築いておくことで、エンジニアとしての希少価値を高めることができます。

まとめ

どんな時にOCIを選ぶべきか?

OCIは、クラウドとしての完成度も想像以上に高く、Oracle製品との親和性が高いというのが実際に使ってみた正直な感想です。
AWSと比較した際の特徴や利点を整理すると、以下のようなケースではOCIを積極的に検討する価値があります。

・エンタープライズ向けの堅牢なシステムを構築したい
セキュリティファーストの設計思想とコンパートメントによる階層管理は、大規模な組織での運用に適しています。
特に金融や医療など、高いセキュリティ要件が求められる分野では初期設定から安全性が担保されているOCIの設計は魅力的です。

・Oracle Databaseを使用している、または使用予定がある
Autonomous Databaseをはじめとする高性能なデータベースサービスは、OCIの最大の強みです。
既存のOracle環境からの移行も、他のクラウドに比べてスムーズに実施できます。

・コストの予測可能性を重視したい
シンプルな料金体系と、特にデータ転送料金の安さは長期的な運用コストの削減に貢献します。
複雑な料金計算に悩まされることなく、予算管理がしやすいのは大きなメリットです。

・新しい技術にチャレンジしたい
OCIはまだ発展途上の部分もありますが、それは同時にチャンスでもあります。
今からOCIのスキルを身につけることで、将来的に希少価値の高いエンジニアになれる可能性があります。

最後に

AWSとOCIはそれぞれ異なる強みを持つクラウドサービスです。
AWSの豊富なサービスと柔軟性は多くのケースで最適解となりますし、OCIのシンプルさとエンタープライズ向けの堅牢性は特定の要件において大きな価値を発揮します。

重要なのは「どちらが優れているか」ではなく、「自分たちの要件にどちらが適しているか」という視点ではないでしょうか。
両方のクラウドを理解し、適材適所で使い分けられるエンジニアこそが、真のクラウドエキスパートだと思います。

この記事が、AWSに慣れ親しんだエンジニアの皆さんがOCIという新しい選択肢を知るきっかけになれば幸いです。 まずはAlways Freeで実際に触ってみて、OCIの世界を体験してみてはいかがでしょうか。

きっと新しい発見があるはずです。

参考リンク


3
2
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
3
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?