はじめに
AWSを使い慣れたエンジニアがOCI（Oracle Cloud Infrastructure）を触り始めると、似て非なる概念に戸惑うことがよくあります。
本記事では、AWS経験者が特に混乱しやすいOCIの概念をピックアップし、AWSとの違いを交えながら解説します。
1. テナンシー（Tenancy）≒ AWSアカウント
| 観点 | OCI（Tenancy） | AWS（Account） |
|---|---|---|
| 位置づけ | 最上位の論理コンテナ | 最上位の分離単位 |
| 基本思想 | 1テナンシーで全体管理 | 複数アカウントで分割管理 |
| 利用単位 | 通常は企業ごとに1つ | 部門・環境ごとに複数 |
| 内部の分割 | コンパートメント | アカウント自体で分割 |
| IAM管理 | ポリシー（文章形式）でシンプル | JSONポリシーで柔軟だが複雑 |
| 権限スコープ | テナンシー内で階層的に制御 | アカウント単位で完全分離 |
| スケールの考え方 | 内部構造でスケール | アカウント追加でスケール |
| 代表的な落とし穴 | コンパートメント設計ミスが致命的 | アカウント乱立・複雑化 |
OCI では、クラウド環境全体のルートとなる単位を テナンシー と呼びます。
AWSの「アカウント」に相当しますが、テナンシーはサインアップ時に1つ作成され、その下にコンパートメントを階層的に作っていくイメージです。
※開発/検証環境などでテナンシ―を分割するケースも数多くあります
2. コンパートメント＝ AWSにない概念
OCI 最大のとまどいポイントがこれです。
コンパートメントについては以下の記事にまとめておりますのでより詳細に知りたい方は参照ください。
コンパートメントはリソースをグループ化・分離するための論理的な区画です。
AWSではアカウントやタグでリソースを分類しますが、OCIでは コンパートメント単位でIAMポリシーを適用 できます。
例えば、以下のケースのようなIAMポリシー管理が可能です
開発環境にしかアクセスできないユーザ（DevUser）
本番環境にしかアクセスできないユーザ（ProdUser）
全てにアクセスできるユーザ（ManageUser）
テナンシー（ルート）
├── コンパートメントA（開発環境）
│ ├── VCN
│ └── Compute
└── コンパートメントB（本番環境）
├── VCN
└── Compute
ポイント: リソース作成時に必ずコンパートメントを指定する必要があります。
最初はルートコンパートメントに作りがちですが、後から移動が難しいため最初に設計しましょう。
3. 可用性ドメイン（AD）とフォルトドメイン（FD）
| OCI | AWS |
|---|---|
| 可用性ドメイン（AD） | アベイラビリティゾーン（AZ） |
| フォルトドメイン（FD） | （相当概念なし） |
可用性ドメイン（AD） はAWSのAZに相当します。
ただしリージョンによってAD数が異なり、OCI東京/大阪リージョンは AD×1 です。AWSの場合はAZ×3なのでここは設計思想が大きく異なるポイントです。
フォルトドメイン（FD） はAWSにない概念で、1つのAD内をさらに3つの障害分離ゾーンに分けたものです。
これにより同一AD内でも問題なく冗長性を確保できます。
4. IAMポリシーの文法が独自形式
AWSのIAMはJSON形式ですが、OCIは独自の文章形式です。
# OCI IAMポリシーの書き方
Allow group <グループ名> to <動詞> <リソース> in <場所>
# 例
Allow group Developers to manage compute-instances in compartment Dev
Allow group ReadOnly to read all-resources in tenancy
動詞は inspect / read / use / manage の4段階で権限レベルを表します。
最初はとっつきにくいですが、慣れると非常に直感的に書けます。
ポリシー管理については以下の記事にまとめておりますのでより詳細に知りたい方は参照ください。
5. リージョンサブスクリプション（=使うリージョンを有効化する必要がある）
AWSでは多くのリージョンがデフォルトで利用可能（例外あり）ですが、OCIでは使用したいリージョンを事前にサブスクライブ（有効化）する必要があります。
リージョンはコンソールの「Region Management」から簡単に追加できます。
例えば東京/大阪リージョンの2つを利用する際はこの作業を実施する必要があります。
また、ホームリージョン（サインアップ時に選択）は変更不可であり、IAM管理や一部サービスの基準となるため、最初の選択が重要です。
6. セキュリティリスト & ネットワーク・セキュリティ・グループ（NSG）
| 種別 | 適用対象 | AWSでの対応 |
|---|---|---|
| セキュリティリスト | サブネット全体 | ネットワークACL（に近しい） |
| NSG（ネットワーク・セキュリティ・グループ） | 個別リソース | セキュリティグループ |
OCI にはこの2種類のファイアウォールがあります。
AWSのセキュリティグループに慣れている方は、NSGを使うのがおすすめです（よりきめ細かい制御が可能）。
7. シェイプ（Shape）＝ EC2インスタンスタイプ相当
Computeインスタンスのスペックを「シェイプ」と呼びます。
- 固定シェイプ: vCPU・メモリが固定（AWSのように予め決められたスペックから選択）
- フレキシブルシェイプ: vCPUとメモリを自由に組み合わせ可能（AWSにはない柔軟性）
フレキシブルシェイプはコスト最適化に非常に有効です。
8. 1OCPU＝ 2vCPU相当
OCI では 1 OCPU = 2 vCPU（ハイパースレッド） に相当します。
AWS のvCPUとは単位が異なるため、インスタンスサイズ比較時には注意が必要です。
| 項目 | OCI | AWS |
|---|---|---|
| CPU単位 | OCPU | vCPU |
| 関係 | 1 OCPU = 2 vCPU | 1 vCPU = 1スレッド |
9. ダイナミックグループ（Dynamic Group）＝ EC2インスタンスプロファイル相当
| OCI | AWS |
|---|---|
| ダイナミックグループ | IAMロール（インスタンスプロファイル） |
ComputeインスタンスからObject StorageやVaultなどのOCIサービスにアクセスするには、ダイナミックグループを使います。
AWSではEC2インスタンスにIAMロールをアタッチしますが、OCIでは以下の手順が必要です。
- ダイナミックグループを作成し、対象インスタンスをルールで定義する
- IAMポリシーでダイナミックグループに権限を付与する
# ダイナミックグループのルール例（コンパートメント内の全インスタンスを対象）
Any {instance.compartment.id = 'ocid1.compartment.oc1..xxxxx'}
# IAMポリシー例
Allow dynamic-group MyInstanceGroup to read secret-family in compartment Dev
ポイント: 名前から用途が想像しにくく、存在自体に気づかないまま詰まるケースが多い概念です。
10. 予約済みパブリックIP（Reserved Public IP）＝ Elastic IP相当
| 項目 | OCI（予約済みパブリックIP） | AWS（Elastic IP） |
|---|---|---|
| 種別 | 予約済みパブリックIP | Elastic IP（EIP） |
| 固定IP | 可能 | 可能 |
| インスタンスから切り離し | 可能 | 可能 |
| 未アタッチ時の課金 | なし（無料） | あり（課金） |
| アタッチ中の課金 | なし（無料） | 条件により課金あり |
| IP自体の料金 | 無料 | 基本有料（条件付き無料あり） |
インスタンスを削除・停止しても保持できる固定のパブリックIPです。
AWSと異なり、インスタンスにアタッチしていない状態でも無課金でOCIは****IPアドレス自体に対する課金が基本ないです。
11. Always Free（常時無料枠）の範囲が広い
厳密には「概念」ではありませんが、AWSのFree Tierと大きく異なる点として知っておくべきです。
AWSの場合はアカウント作成から12ヶ月間のみ利用可能です。
例. EC2（750時間/月）S3（5GB）RDS（750時間/月）
また、AWSにも少量の常時無料サービス（LambdaやDynamoDBなど）ありますが、OCIほど多くはありません。
OCIのAlways Free（期間制限なし） には以下が含まれます:
- Computeインスタンス
- Arm（Ampere）：合計最大 4 OCPU / 24GB
- AMD：小型インスタンス ×2
- オブジェクトストレージ 20GB
- ロードバランサー（帯域制限あり）1台
- Autonomous Database 2インスタンス（制限付き）
これらは無期限で利用可能ですが、以下の点に注意が必要です：
- リソースは空き状況に依存（作成できない場合あり）
- SLAや商用利用には制限あり
開発・検証用途であれば、かなりの範囲を無料で賄えます。
まとめ
| # | OCIの概念 | AWS対応 | ポイント |
|---|---|---|---|
| 1 | テナンシー | アカウント | ルートの組織単位 |
| 2 | コンパートメント | （なし） | リソース分離＋IAM適用単位 |
| 3 | 可用性ドメイン / フォルトドメイン | AZ / （なし） | FDはAD内の冗長化 |
| 4 | IAMポリシー | IAM JSON | 独自文章形式 |
| 5 | リージョンサブスクリプション | （自動） | 使う前に有効化が必要 |
| 6 | セキュリティリスト / NSG | NACL / SG | 2種類が併存 |
| 7 | シェイプ | インスタンスタイプ | フレキシブル指定が可能 |
| 8 | OCPU | 2vCPU | リソース比較時に注意 |
| 9 | ダイナミックグループ | インスタンスプロファイル | インスタンスへの権限付与 |
| 10 | 予約済みパブリックIP | Elastic IP | 未アタッチ時も課金 |
| 11 | Always Free | Free Tier（12ヶ月限定） | 期間制限なしの無料枠 |
AWSとOCIは思想が近い部分も多いですが、コンパートメントやIAMの独自性は最初の壁になりがちです。
本記事がOCI入門の一助になれば幸いです。