OCI入門 Vol3 ネットワーキング入門 VCN・サブネット・ゲートウェイ・NSG

1. この記事について — OCIのネットワーキングへ踏み込む

1-1. 本記事の位置づけ — Vol1-2の続きとして

Vol1では、OCIのリソースを収める「器」であるテナンシとコンパートメント、そしてリージョン・アベイラビリティドメインという配置の単位を扱いました。

Vol2では、その器の中で「誰が何にアクセスできるか」を制御するIAM(Identity Domains・ポリシー・ダイナミックグループ)を扱いました。

本記事では視点を変え、器の中に配置したリソース同士を「どうつなぐか」を扱います。その舞台となるのがVCN(Virtual Cloud Network)です。

テナンシ・コンパートメント・ADの詳細はVol1、IAMの詳細はVol2をあわせてご参照ください。本記事ではこれらの基礎知識を前提とし、繰り返しの説明は行いません。

なお、本記事で扱うVCN・サブネット・ゲートウェイ・セキュリティリスト・NSGといった各リソースは、いずれもコンパートメント(Vol1)に所属する形で作成し、それらを操作する権限はIAMポリシー(Vol2)で制御する対象でもあります。ネットワーク構成を変更できる権限を誰に与えるかは、実務上IAM設計と切り離せない論点であり、その点でも本記事はVol1・Vol2の続きに位置づけられます。

Vol1で「器」、Vol2で「権限」を押さえたことで、OCI上にリソースを配置し、誰がそれを操作できるかまでは整理できました。残る問いは「配置したリソース同士がどう通信するか」であり、これが本記事のテーマです。

Vol1・Vol2で扱った「器」と「権限」は、AWSにおけるアカウント構造やIAMポリシーとの対応関係を比較的つけやすい領域でした。一方でネットワーキングは、通信経路という物理的な要素を扱うため、AWSでの設計経験をそのまま活かせる部分と、OCI固有の発想として新たに理解し直すべき部分が混在します。本記事では、この「AWSの知識をそのまま流用できる部分」と「OCI特有の考え方として覚え直す部分」を意識的に区別しながら解説を進めます。

1-2. AWS VPCとの発想の違い(本記事の軸)

AWSでネットワークを構築する際は、VPC・サブネット(アベイラビリティゾーン固有)・Internet Gateway・NAT Gateway・ルートテーブル・セキュリティグループ・ネットワークACLといった要素を組み合わせます。

OCIにも同じ役割を担う要素として、VCN・サブネット(リージョナルまたはAD固有)・4種のゲートウェイ(Internet Gateway・NAT Gateway・Service Gateway・Dynamic Routing Gateway)・セキュリティリスト・NSGが用意されています。

名前や役割は似ていても、区画の切り方や適用範囲には無視できない違いがあります。たとえばAWSのサブネットは常にAZ固有ですが、OCIのサブネットはリージョン全体に跨るリージョナルサブネットを選べます。また、OCIサービスへの経路には、AWSのVPCエンドポイントに相当するService Gatewayという専用の仕組みが用意されています。

セキュリティの考え方にも違いがあります。AWSではセキュリティグループ(ENI単位)とネットワークACL(サブネット単位)を組み合わせますが、OCIではNSG(VNIC単位)とセキュリティリスト(サブネット単位)という、似た役割を持つ2つの仕組みを組み合わせます。どちらを主軸にするかという設計思想の違いは、§5で詳しく取り上げます。

特に複数VPC・複数アカウントの運用に慣れたAWS実務者にとって、OCIのコンパートメントを跨いだネットワーク構成や、DRGを中心としたハブアンドスポーク型の接続構成は、名前は似ていても考え方の対応関係を掴むまでに戸惑いやすいポイントです。本記事では、こうした戸惑いが生じやすい箇所を意識的に取り上げます。

本記事では、この対応関係と相違点を軸に、§2でVCNの全体像、§3でサブネット、§4でゲートウェイ、§5でセキュリティ、§6で設計のベストプラクティスへと順に解説を進めます。

各章の冒頭では、対応するAWSの要素を先に挙げたうえでOCI側の要素を紹介する構成にしているため、AWSでの経験を手がかりにしながら読み進められます。

本記事を読み終えると、AWSでVPCを設計した経験のある方であれば、OCI上で新規にVCNを構築する際に「どの要素が既知の知識で対応でき、どの要素だけ新たに調べ直す必要があるか」を自分の言葉で切り分けられるようになることを目指します。特にService Gatewayやリージョナルサブネットのように、AWSに直接の1対1対応が存在しない要素は、本記事内で重点的に扱います。

なお、OCIではFree Tierでも最大2つまでVCNを作成でき、東京リージョン(ap-tokyo-1)を含む全リージョンで一貫して利用できます。学習目的でVCNを試す際に、追加コストを気にせず構成を確認できる点も、実務でOCIを触り始める際に押さえておくとよいポイントです。

本記事の各章は独立して参照できる構成にしていますが、初めてOCIネットワーキングに触れる方は、§2から順に読み進めることで、VCNという全体像を先に押さえたうえで各要素の詳細に入っていけます。

← 前巻: OCI入門 Vol2 IAM入門(Identity Domains・ポリシー・ダイナミックグループ)

2. VCNの全体像 — OCIの仮想ネットワーク

2-1. VCNとは — リージョナルな仮想ネットワーク

VCN(Virtual Cloud Network)は、OCI上でリソース同士を接続するための仮想ネットワークです。

VCNは単一のOCIリージョン内に存在し、1つ以上のCIDRブロック(IPv4・IPv6対応時はIPv6も含む)によって定義されます。

Vol1で扱ったとおり、1つのリージョンには複数のアベイラビリティドメイン(AD)が存在します。VCNはこのAD単位に閉じるのではなく、リージョン内の複数のADを跨いで構築できる点が特徴です。

つまり、テナンシ・コンパートメントという「器」の中に、リージョンという地理的な単位で1つのVCNを配置し、その内部でAD横断的にリソースをつなぐ、というのがOCIネットワーキングの基本構造です。

ADそのものの定義や役割はVol1で扱った内容と同じですので、詳細はそちらをご参照ください。本記事では、このVCNという1枚のキャンバスの上に、サブネット・ゲートウェイ・セキュリティルールをどう配置していくかを見ていきます。

たとえば「10.0.0.0/16」のようなCIDRブロックを1つ指定してVCNを作成し、その中を複数のサブネットに分割していく、という流れが基本形です。VCN作成後にCIDRブロックを追加でき、最初に決めた範囲だけに縛られるわけではありません。

なお、1つのコンパートメントには複数のVCNを作成でき、用途や環境(開発・検証・本番など)ごとにVCNを分けて管理することも一般的な構成です。異なるVCN同士を接続したい場合は、§4で扱うDynamic Routing Gatewayを介したピアリングという方法があります。

異なるVCN同士を接続する具体的なケースとしては、大きく2通りあります。1つは、同一テナンシ・同一リージョン内で、開発環境用VCNと検証環境用VCNのように用途ごとに分けたVCN同士を、必要な通信だけ許可してつなぐケースです。もう1つは、複数リージョンにまたがるマルチリージョン構成で、異なるリージョンのVCN同士の通信経路を確保するケースです。

いずれのケースも、VCNに取り付けたDRG(Dynamic Routing Gateway)を経由して実現でき、DRGにピアリング用の接続コンポーネントを追加し、両側のルートテーブルに互いのCIDRブロックへ向かう経路を設定する、という流れが基本形です。DRGを使ったVCN間接続の具体的な設定手順や、経路設計時に注意すべきルートテーブルの考え方は、§4のDynamic Routing Gatewayの節でオンプレミス接続とあわせて詳しく取り上げます。

2-2. CIDRブロック設計の考え方

VCNを作成する際は、まずVCN全体のCIDRブロックを決定します。OCIでは/16から/30までの範囲でCIDRブロックを指定でき、新規VCNの初期値としてよく使われるのが10.0.0.0/16のようなRFC1918準拠のプライベートアドレス帯です。

CIDR設計で最初に検討すべきは、将来のサブネット追加やリソース増加を見込んだ余裕の確保です。VCN作成後にCIDRブロックを追加すること自体は可能ですが、最初から余裕を持たせておいたほうが、後からのアドレス設計の見直しを避けられます。あわせて、オンプレミス環境や他のVCNとの接続を将来予定している場合は、それらのネットワークとCIDR範囲が重複しないよう調整しておく必要があります。169.254.0.0/16のようなリンクローカルアドレス帯はOCI内部でも使用されているため、VCNのCIDRブロックとしては避けるべき範囲です。

VCN全体のCIDRブロックを決めたら、これを複数のサブネットに分割します。各サブネットに同じサイズのCIDRを均等に割り当てる必要はなく、Webサーバー用のpublicサブネットは小さめ、データベースやアプリケーションサーバーを多数配置するprivateサブネットは大きめ、というようにワークロードの規模に応じてサブネットごとに異なるCIDRサイズを割り当てるのが実務上一般的です。

たとえば10.0.0.0/16というCIDRブロックでVCNを作成した場合、10.0.0.0/24をpublicサブネットに、10.0.1.0/24をprivateサブネットに割り当て、残りの範囲は将来のサブネット追加用に確保しておく、といった配分がCIDR設計の一例です。均等に分割するのではなく、用途ごとに必要な範囲だけを割り当て、残りを温存しておく考え方がポイントです。

なお、OCIは1つのサブネットにつき3つのIPアドレス(先頭2つと末尾1つ)を内部的な用途のために予約します。サブネットで実際に利用できるホスト数を見積もる際は、この予約分を差し引いて計算する必要があります。

最初に確保したCIDRブロックが不足してきた場合は、VCNに追加のIPv4 CIDRブロックを後から割り当てることもできます(1つのVCNにつき最大16個まで)。ただし追加するCIDRブロックは、同一VCN内の既存の範囲やピアリング済みの他VCNの範囲と重複させることはできません。設計段階では、こうした追加余地があることを踏まえつつも、最初のCIDRブロック選定の時点である程度余裕を持たせておくほうが、後々の管理はシンプルになります。

2-3. AWS VPCとOCI VCNの概念対応マップ

AWSとOCIのネットワーキング要素は、役割ごとに次のように対応します。

この表は厳密な1対1の対応ではなく、あくまで役割が近い要素同士を並べたものです。実際の仕様はそれぞれ異なるため、本記事の各章で詳細を確認していきます。

たとえばAWSのサブネットは常にAZ(アベイラビリティゾーン)固有であるのに対し、OCIのサブネットはリージョナル(AD跨り)とAD固有のいずれかを選べるなど、名前は似ていても、仕組みの異なる箇所が随所にあります。

また、OCIサービス(Object Storageなど)への経路として、AWSのVPCエンドポイントに相当するService Gatewayが用意されている点も、OCI独自の発想といえます。AWSではVPCエンドポイントをサービスごとに個別作成しますが、OCIのService Gatewayはリージョナルな1つのゲートウェイとして構成し、対応する複数のOCIサービスへの経路をまとめて提供します。

具体例として、AWSでprivateサブネットのEC2インスタンスからS3へアクセスする際は、VPCエンドポイント(Gateway型またはInterface型)をVPCごとに作成し、ルートテーブルまたはセキュリティグループでエンドポイントへの経路を設定します。OCIで同等の構成を組む場合は、VCNにService Gatewayを1つ作成し、対象のOCIサービス(Object StorageやAutonomous Databaseなど)への経路をまとめてルートテーブルに設定するだけで、privateサブネットからプライベート経路でアクセスできるようになります。エンドポイントをサービスごとに個別管理するAWSと、ゲートウェイをリージョナルに1つ用意しまとめて経路を通すOCI、という運用上の違いも押さえておくとよいポイントです。

セキュリティ面では、AWSのセキュリティグループ(ENI単位・ステートフル)とネットワークACL(サブネット単位・ステートレス)という組み合わせに対し、OCIのNSG(VNIC単位)とセキュリティリスト(サブネット単位)は、既定でどちらもステートフルという前提が異なります。この点は§5で詳しく扱います。

この違いは§3以降で1つずつ確認していきます。なお、テナンシ・コンパートメント・AD自体の対応関係はVol1で扱っているため、本記事では扱いません。

2-4. VCNの構成要素

1つのVCNは、次のような要素の組み合わせで成り立っています。

VCNを作成すると、これらのうちデフォルトのルートテーブル・デフォルトセキュリティリスト・デフォルトDHCPオプションが自動的に用意されます。いずれも中身は空、または最小限のルールのみを持った状態で作成されます。

デフォルトの構成要素そのものを削除できませんが、内容の変更や、用途に応じたカスタム版を新たに作成できます。

実務では、デフォルトのセキュリティリストをそのまま使い続けるのではなく、要件に応じたカスタムセキュリティリストやNSGを追加していくケースが一般的です。この使い分けの考え方は§5で詳しく取り上げます。

ルートテーブルは、サブネットに割り当てたVCN外向けの通信を、どのゲートウェイへ振り分けるかを定義する経路のルールセットです。1つのサブネットには1つのルートテーブルのみを関連付けられ、ルールは宛先CIDRブロックと、その宛先に対応するターゲットの組み合わせで構成されます。ルートテーブル自体はVCN内部同士の通信には使われず、あくまで宛先がVCNのCIDRブロック外にある場合にのみ参照される点に注意が必要です。

ルートルールに指定できる主なターゲットは次のとおりです。

1つのVCNには複数のルートテーブルを作成でき、サブネットごとに異なるルートテーブルを割り当てることで、同じVCN内でもサブネットごとに異なる経路ポリシーを適用できます。たとえばpublicサブネットのルートテーブルにはInternet Gatewayへの経路のみを、privateサブネットのルートテーブルにはNAT GatewayとService Gatewayへの経路を設定する、という使い分けが一般的です。

DHCPオプションは、サブネット内のインスタンスが起動時に受け取るネットワーク設定をまとめたリソースです。DNSの解決方法は既定でInternet and VCN Resolver(OCIが提供するリゾルバー経由でインターネットとVCN内部の両方を解決)になっており、必要に応じて最大3台までの任意のDNSサーバーを指定するCustom Resolverに切り替えられます。

また、検索ドメイン(Search Domain)を1つだけ指定でき、VCNにDNSラベルを設定している場合は既定で「VCNのDNSラベル.oraclevcn.com」が使われます。1つのサブネットに関連付けられるDHCPオプションは1セットのみで、指定しない場合はVCN既定のセットが使われます。

VNICは1つのインスタンスに複数アタッチでき(上限はシェイプによって異なります)、1つのVNICには複数のプライベートIPアドレス(プライマリ1つとセカンダリ複数)を割り当てられます。用途に応じて、1つのインスタンスに複数のサブネットをまたぐ通信経路を持たせたり、1つのVNICに複数のプライベートIPを割り当てて構成したりできます。

2-5. 本章以降の道筋

ここからは、VCNを構成する各要素を1つずつ掘り下げていきます。

§3では、サブネットのpublic/privateという区分と、リージョナル/AD固有という区分を取り上げます。

§4では、Internet Gateway・NAT Gateway・Service Gateway・Dynamic Routing Gatewayという4種のゲートウェイの役割を整理します。

§5では、セキュリティリストとNSGという2つのファイアウォールの仕組みと使い分けを確認します。

§6では、これらを組み合わせた実践的なVCN設計のベストプラクティスを取り上げます。

なお、本節(§2-2)で確認したCIDR設計の考え方は、§3以降で扱うサブネットの区分やゲートウェイの経路設計の前提となる基礎知識です。個々の要素の役割を追う前に、まずVCN全体でどれだけのアドレス空間を確保し、どう配分するかを押さえておくことで、以降の各章がつながりやすくなります。

Vol1(器)・Vol2(権限)に続き、本記事でネットワークという土台を理解することで、次巻Vol4で扱うコンピュートとストレージの配置がより具体的にイメージできるようになるはずです。

3. サブネット — public/private とルーティング

3-1. サブネットの基本 — VCNを区切る

VCNに割り当てたCIDRブロックを、さらに小さな単位に区切るのがサブネットです。1つのVCN内には複数のサブネットを作成でき、それぞれに独立したCIDR範囲を割り当てます。

サブネットを作成する際は、ルートテーブルとセキュリティリストを関連付けます。ルートテーブルはそのサブネットからの通信がどの経路(ゲートウェイ)へ向かうかを決め、セキュリティリストはサブネット内の通信可否を制御します。ルートテーブルとセキュリティリストはサブネットごとに異なるものを指定できるため、後述するpublic/privateの使い分けもこの組み合わせで実現します。

3-2. public サブネットと private サブネット

OCIのサブネットは、作成時にpublicかprivateかを選択します。

privateサブネットは、VCNにInternet Gatewayが設置されていて、かつセキュリティリストやNSGの通信ルールが許可されていたとしても、パブリックIPを持てない設計そのものによってインターネットからの到達を遮断します。この「サブネットの型で防ぐ」という発想は、ルールの許可設定だけに依存しないため、Webサーバーなど外部公開が必要なリソースはpublicサブネットに、データベースやアプリケーションサーバーなど外部公開が不要なリソースはprivateサブネットに配置する、という設計判断の土台になります。

3-3. リージョナルサブネットとAD固有サブネット

AWSのサブネットは必ず特定のAZ(アベイラビリティゾーン)に固定される点が前提になっていますが、OCIのサブネットは「リージョナル」と「AD固有」のいずれかを選んで作成できます。

リージョナルサブネットが推奨される理由は、単一のサブネットにAD跨りでリソースを配置できるため、特定のADで障害が発生してもサブネットの構成自体を分割し直す必要がなく、可用性設計がシンプルになるためです。AWSのサブネット(AZ固有が前提)とは異なり、OCIでは「サブネットをAD単位で分ける」か「サブネットを跨いでADに分散させる」かを設計時に選べる点が大きな違いです。

4. ゲートウェイ — VCNの出入り口

VCNは既定では外部と隔離されたネットワークです。外部との通信経路を作るには、目的に応じたゲートウェイをVCNに追加し、ルートテーブルで経路を指定する必要があります。OCIには次の4種類のゲートウェイがあります。

4-1. Internet Gateway(IGW) — インターネット双方向経路

Internet Gatewayは、インターネットとVCNを結ぶ双方向の経路です。publicサブネットに配置したWebサーバーのように、インターネットから直接アクセスされるリソースや、インターネットへ自ら通信を開始するリソースに使います。publicサブネットのインスタンスであっても、Internet Gatewayを設置してルートテーブルに経路を設定しない限りインターネットに接続できません。役割としてはAWSのInternet Gatewayとほぼ同じ位置づけです。

4-2. NAT Gateway — アウトバウンド専用

NAT Gatewayは、パブリックIPを持たないリソースに対して、インターネットへのアウトバウンド通信のみを提供するゲートウェイです。インターネット側からのインバウンド接続は遮断されるため、privateサブネットに配置したインスタンスがOSアップデートや外部APIの呼び出しなど、自発的に通信する際に利用します。挙動はAWSのNAT Gatewayと同義です。

4-3. Service Gateway — OCIサービスへのプライベート経路

Service Gatewayは、privateサブネットからObject StorageなどのOracle Cloud Infrastructureのサービスへ、インターネットを経由せずリージョン内のプライベート経路で通信するためのゲートウェイです。たとえばprivateサブネットに置いたDBシステムが、パブリックIPも持たずインターネットアクセスも持たないままObject Storageへバックアップを取る、といった構成が可能になります。AWSのVPCエンドポイントに相当する役割です。

4-4. Dynamic Routing Gateway(DRG) — オンプレ/他網接続

Dynamic Routing Gateway(DRG)は、オンプレミス環境や他のVCN・他リージョンとの接続を1つの入口に集約する仮想ルーターです。VPN(Site-to-Site VPN)やFastConnectによるオンプレミス接続、同一リージョン内の他VCNとのローカルピアリング、他リージョンのVCNとのリモートピアリングを、いずれもDRGを介して実現します。ハイブリッド構成やマルチVCN構成を組む際の中心的な存在で、AWSのVirtual Private Gateway(VGW)やTransit Gatewayに相当する役割を担います。

5. セキュリティ — セキュリティリストとNSG

5-1. セキュリティリスト — サブネット単位のルール

セキュリティリストは、サブネット内の全VNICに一律で適用されるファイアウォールルールです。1つのサブネットには最大5つのセキュリティリストを関連付けられます。ルールごとにステートフルまたはステートレスを選択でき、既定はステートフルです。

AWSのネットワークACL(NACL)もサブネット単位で適用される点は共通していますが、AWSのNACLは既定でステートレス(往路・復路それぞれにルールが必要)であるのに対し、OCIのセキュリティリストは既定でステートフル(戻りの通信は自動的に許可)という違いがあります。この既定値の違いは、AWSからの移行時に見落としやすいポイントです。

5-2. NSG(Network Security Group) — VNIC単位のルール

NSGは、サブネット全体ではなく選択したVNICのグループ(ロードバランサーやデータベースなど親リソース単位での指定も可能)に適用するファイアウォールルールです。1つのVNICは最大5つのNSGに所属できます。

この考え方はAWSのセキュリティグループ(ENI単位で適用)に近く、対応関係として理解しやすい部分です。加えてOCIのNSGは、ルールの送信元・送信先にCIDRだけでなくNSG自体を直接指定できるため、「Webサーバー層のNSGからアプリ層のNSGへの通信のみ許可する」といったリソース単位のきめ細かい制御(マイクロセグメンテーション)がしやすくなっています。

5-3. 使い分けと併用 — Oracle推奨はNSG

セキュリティリストとNSGは併用可能です。あるVNICには「所属サブネットのセキュリティリスト」と「所属している全NSG」のルールが両方適用され、いずれか一方のルールで許可されていれば通信が通過する、和集合の関係になります。

Oracle公式ドキュメントでは、VCNのサブネット構成とアプリケーションのセキュリティ要件を分離できる点から、NSGの利用が推奨されています。サブネットの構成自体には手を加えずに、アプリケーション側のセキュリティ要件だけを柔軟に見直せることが利点です。

実務では、セキュリティリストをサブネット共通の最小限のベースラインとし、アプリケーション層ごとの詳細な制御はNSGに任せます。この設計は、Oracleが推奨する分離の考え方に沿った構成です。

6. 実践 — VCN設計のベストプラクティス

6-1. 最小構成 — public/privateサブネットの分離

ここまでの内容を踏まえ、実践的なVCN設計の最小構成を確認します。基本となるのは、公開が必要なリソースを置くpublicサブネットと、非公開のリソースを置くprivateサブネットに分ける2層構成です。

publicサブネットにはロードバランサーや踏み台サーバーを配置し、Internet Gatewayを経由してインターネットと直接やり取りします。privateサブネットにはアプリケーションサーバーやデータベースを配置し、外部から直接アクセスされないようにしたうえで、必要なアウトバウンド通信はNAT Gateway経由で行います。この「public=IGW、private=NAT Gateway」という組み合わせは、AWS VPCで踏み台+アプリ+DBを分離する定番構成と同じ発想であり、AWSでの設計経験をそのまま応用できます。

6-2. Service Gatewayでインターネットを経由しない

privateサブネットに置いたリソースがObject StorageなどのOCIサービスにアクセスする場合、NAT Gateway経由でインターネットを経由させることも技術的には可能ですが、Service Gatewayを使ってリージョン内のプライベート経路で直接つなぐ設計のほうが望ましい構成です。

インターネットを経由しない分、通信経路が短く、パブリックエンドポイントへの到達性に依存しないため経路上のリスクを減らせます。加えて、NAT Gateway経由の通信には帯域に応じたデータ処理料金が発生しますが、Service Gateway経由の場合はこの料金がかからないという利点もあります。privateサブネットからOCIサービスへの通信が発生する設計では、ルートテーブルでService Gatewayへの経路を優先的に検討します。

6-3. NSGでマイクロセグメンテーション

セキュリティ設計では、§5-3で確認したOracleの推奨に沿って、セキュリティリストとNSGの役割を分担します。セキュリティリストはサブネット単位の最小限のベースライン(たとえば既定で不要な通信を遮断する程度)にとどめ、Webサーバー層・アプリケーション層・データベース層といったアプリケーションの階層ごとの通信制御はNSGで行います。

たとえば「Web層のNSGからのみアプリ層のNSGへの通信を許可する」「アプリ層のNSGからのみDB層のNSGへの通信を許可する」というように、NSG同士を送信元・送信先に指定して階層間の通信を絞り込むことで、仮にいずれかの層が侵害されても被害の範囲をその層の周辺に留めやすくなります。これがNSGによるマイクロセグメンテーションの考え方です。

6-4. VCN設計チェックリスト

VCNを設計する際に確認しておきたい基本項目は、次のとおりです。

• CIDRブロックのサイズは、将来のサブネット追加やリソース増加を見込んで余裕を持たせているか
• public(公開が必要なリソース)とprivate(非公開のリソース)でサブネットを分離しているか
• 通信要件に応じて、Internet Gateway・NAT Gateway・Service Gateway・Dynamic Routing Gatewayのうち必要なゲートウェイを過不足なく選定しているか
• セキュリティリストは最小限のベースラインにとどめ、アプリ層ごとの詳細な制御はNSG中心で設計しているか
• 可用性を高めるため、AD固有ではなくリージョナルサブネットを活用しているか

これらを起点に、実際のワークロードの要件に応じて構成を調整していくことで、AWSでの設計経験を活かしながらOCIらしいネットワーク設計を組み立てられます。

7. まとめ — OCIネットワーキングの基礎と次のステップ

7-1. 本記事の振り返り

本記事では、OCIのネットワーキングを4つの柱に沿って解説してきました。

まず、VCN(Virtual Cloud Network)は単一のOCIリージョン内に存在し、複数のアベイラビリティドメイン(AD)を跨いで構築できる仮想ネットワークです。AWSのVPCがアベイラビリティゾーン単位でサブネットを分割するのに対し、OCIはリージョナルサブネットを既定として推奨しており、AD障害への耐性という観点で発想の違いがあります。

次に、サブネットにはpublic(パブリックIPを付与しインターネットに直接アクセス可能)とprivate(NAT Gateway経由でアウトバウンドのみ)の区別があり、用途に応じて使い分けます。

ゲートウェイについては、インターネットとの双方向経路を担うInternet Gateway、アウトバウンド専用のNAT Gateway、OCIサービスへのプライベート経路を提供するService Gateway、オンプレミスや他VCNとの接続を担うDynamic Routing Gateway(DRG)の4種類を確認しました。それぞれAWSのIGW・NAT Gateway・VPCエンドポイント・VGW/Transit Gatewayに相当しますが、1対1の対応ではない点に注意が必要です。

最後にセキュリティでは、サブネット内の全VNICに一律適用されるセキュリティリストと、選択したVNICグループに適用できるNSG(Network Security Group)の2つの仕組みを比較し、Oracleが推奨するNSG中心の設計思想を確認しました。

これらはいずれも、AWS VPCで培った知識を土台にしながらOCI独自の発想を理解することで、両クラウドの設計思想の違いをより明確に捉えられるようになったかと思います。

7-2. 次のステップ — コンピュートとストレージへ

OCI入門シリーズでは、Vol1でテナンシ・コンパートメント・リージョン・ADといった「器」を、Vol2でIAM・Identity Domains・ポリシー・ダイナミックグループといった「権限」を、そして本記事Vol3でVCN・サブネット・ゲートウェイ・セキュリティといった「ネットワーク」を扱ってきました。

次巻のVol4では、このネットワークの上に実際にリソースを載せる段階として、コンピュート(インスタンス)とストレージを取り上げる予定です。ネットワークという土台が整ったことで、次はいよいよOCI上でワークロードを動かす具体的な構成に踏み込んでいきます。

← 前巻: OCI入門 Vol2 IAM入門

→ 次巻: OCI入門 Vol4 コンピュート入門