Cloudflare@OCI が来たぞ！（詳細編）

Last updated at 2026-06-14Posted at 2026-06-14

概要編はこちらです。

Cloudflare@OCI が来たぞ！（概要編）

サマリ

Cloudflare@OCIの詳細編です。概要編では「前段に置く」話をしました。この記事では、その先で出てくるDNS/TLS、キャッシュ、ログあたりの論点を整理します
基本は End User -> Cloudflare Edge -> OCI Origin です。CloudflareはOCIの中に入るのではなく、OCI公開Web/APIの前段で通信を受けます
見ておきたい軸は、オリジン、DNS/TLS、WAF/API/Bot、キャッシュ、ログ、プランごとの占有量です

出典: Cloudflare on OCI for Secure, High-Performance Cloud Delivery | Oracle

はじめに

概要編では、Cloudflare@OCIを「OCI公開Web/APIの前段にCloudflare Edgeを置く選択肢」として紹介しました。

この記事はその詳細編です。概要編で触れきれなかったところを、もう少し具体的に見ていきます。

想定読者は、OCIは分かるけれど、CDNやCloudflareの細かい機能はこれから、という人です。
なので、Cloudflareの各機能を網羅するより、「OCI公開Web/APIの前段にCloudflareを置くと、どんな論点が増えるのか」に絞ります。

また、Cloudflare@OCIの利用可能機能や数量はバンドルによって変わります。
この記事では、公式情報から分かる範囲と、OCI側から見たときに論点になりやすい場所を分けて書きます。
Cloudflareの細かい設定値や、個別案件での推奨構成を決め打ちする記事ではありません。

Cloudflare@OCIは、名前だけ見ると「OCIの中にCloudflareが生えるのかな？」と思ってしまうかもしれません。
実際にはそうではなく、Cloudflare Edgeがインターネット側で通信を受け、その後ろにOCIのLoad Balancer、Compute、OKE、Object Storageなどのオリジンを置く構成です。

この前提を置くと、DNS、証明書、ログ、キャッシュの話を「Cloudflare側で見るもの」と「OCI側で見るもの」に分けて考えやすくなります。

全体アーキテクチャ

まずは全体像です。

考え方のポイントは、Cloudflare Edgeで全部を完結させるのではなく、Cloudflareで「入口」を受け、OCIで「アプリケーション本体」を動かすことです。

注意: 以下の機能は、すべてのプランで同じように使えるという意味ではありません。Cloudflare@OCIの含有機能や数量はプランによって変わります。ここでは、理解するときの観点として並べています。

Cloudflare側で見るもの:

DNS / プロキシ設定
TLS / 証明書
WAF / DDoS対策
Bot対策
API保護
CDN / Cache
Security Events / Logpushなど

OCI側で見るもの:

Load Balancer
Compute / OKE / Container Instances
Object Storage
VCN / Security List / NSG
Database
OCI Logging / Monitoring

Cloudflareを前段に置くと、インターネット側の入口をCloudflareで受けることになります。そのため、障害調査やログ確認では、Cloudflare側で起きていることと、OCI側で起きていることを分けて見る観点が増えます。

よくある置き方1: OCI Load Balancerの前段に置く

よく見る形の1つが、OCI Load Balancerの前段にCloudflareを置く構成です。

この構成では、Cloudflare Edgeがインターネット側の入口になります。そこでWAF、DDoS対策、Bot対策、CDNキャッシュ、Rate Limitingなどを扱い、OCI Load Balancerへ通信を流す形です。

見るポイントは以下です。

観点	Cloudflare側	OCI側
DNS	ドメイン、レコード、プロキシ有効化	Load Balancerの公開名/IP
TLS	Edge証明書、オリジン接続方式	HTTPSの入口、証明書
セキュリティ	WAF、DDoS、Bot、Rate Limiting	NSG、Security List、OCI WAF利用有無
可用性	Cloudflare Load Balancing利用有無	Backend Set、Health Check
ログ	Security Events、Logpushなど	LB Access Log、App Log

Cloudflareを置いたからOCI側で見るものがなくなるわけではありません。Load BalancerのHealth Check、Backend Set、証明書、アプリケーションログは引き続き見ます。

よくある置き方2: OCI Object Storageをオリジンにする

OCI Object Storageをオリジンにして、Cloudflareで静的コンテンツを配信する構成も考えられます。

画像、PDF、動画サムネイル、ダウンロードファイルなどは、アプリケーションサーバーを通さずに配信できる場合があります。

このパターンでは、主に3つの観点を見ます。

1つ目は「公開URL」です。利用者に見せるURLをCloudflare側の独自ドメインに寄せるか、Object StorageのURLやPARのURLを見せるかを決めます。たとえば https://static.example.com/downloads/... のような入口をCloudflare側に作ると、Object Storage側のURL体系を利用者から隠せます。

2つ目は「Object Storageへの直接アクセス」です。ここは要件で変わります。

公開してよい画像やPDFなら、Object Storageを公開し、Cloudflareでキャッシュする構成が候補になります
期限付きで配りたいファイルなら、PAR（事前認証リクエスト）を使う選択肢があります。ただしPARのURL自体が権限を持つので、長期間・広範囲に配る用途では慎重に扱います
Object Storageへの直接アクセスを避けたい場合は、Cloudflareから見える公開入口を別に作り、アプリケーションやLoad Balancer側で認可してからObject Storageへ取りに行く構成もあります。構成は増えますが、アクセス制御の責任範囲は説明できます

3つ目は「キャッシュと更新」です。静的コンテンツ配信では、どのファイルをキャッシュ対象にするか、更新時にどう反映するかが論点になります。

たとえば、更新頻度が低い画像やPDFと、ログイン後ページやユーザー固有APIでは、キャッシュの扱いが変わります。この記事では具体的なルール値には踏み込まず、「何をキャッシュ候補にするか」「更新時にどう反映するか」を見る、くらいに留めます。

キャッシュは速さに関わる機能ですが、同時に「更新をどう反映するか」にも関わります。詳しくは後段の「キャッシュで見るところ」で整理します。

よくある置き方3: 公開APIの前段に置く

APIはWebページよりも、前段にCloudflareを置いたときの論点が見えやすいです。

APIで見るポイントは、通常のWebサイトとは少し違います。

ここでいう「API保護」は、API Shieldという特定機能だけを指しているわけではありません。WAF、Rate Limiting、Bot対策、API Shieldなどを、対象APIとバンドルに応じて組み合わせる話です。API Shieldなどの高度なAPI保護機能を使う場合は、対象バンドルに含まれるかを確認します。

観点	見ること
レート制御	IP単位、トークン単位、パス単位で制御したいか
Bot判定	人間のブラウザ、正規クライアント、Botをどう分けるか
認証前の保護	ログイン前API、検索API、公開APIをどう守るか
エラー時の見え方	制限時や遮断時に利用者・運用者からどう見えるか
ログ	攻撃検知だけでなく、どのAPIが叩かれているか

APIでは、アプリケーション側の認可・認証とは別に、前段で見られる通信の特徴があります。大量アクセス、Botと見なされる挙動、特定パスへの集中などをCloudflare側の機能でどこまで扱うかが確認点になります。

DNSとTLSの考え方

Cloudflareを前段に置く場合、DNSとTLSが論点になります。

最初に分けるのは、利用者からCloudflareまでのTLSと、CloudflareからOCIオリジンまでのTLSです。

ここで押さえたいのは、TLSが2区間に分かれることです。利用者からCloudflareまでのTLSと、CloudflareからOCI Load BalancerまでのTLSは別物です。

Cloudflareの暗号化モードには、Flexible、Full、Full (Strict)などがあります。この記事ではどれを選ぶかには踏み込みませんが、「CloudflareでHTTPSを受ける区間」と「CloudflareからOCIへ接続する区間」は別の論点として見ます。

OCI Load BalancerをHTTPSのオリジンにする場合、OCI Load Balancer側にも証明書が関係します。公開CA証明書を使うのか、Cloudflare Origin CAのようなオリジン向け証明書を使うのか、あるいは別の構成にするのかは、案件ごとの要件で変わります。

DNSも同じです。Cloudflareでプロキシするレコードと、DNS onlyのレコードがあります。Web/APIの入口をCloudflare経由にするのか、メールや検証用レコードはどう扱うのか。このあたりは、OCI側だけ見ていると出てこない論点です。

WAF / DDoS / Bot / API保護の見方

Cloudflareのセキュリティ機能はたくさんあります。

ここでは、守りたい対象ごとに見方を分けます。

対象	主に見る機能	確認したいこと
Webサイト	WAF、DDoS、Bot対策	どのURLを公開し、どの攻撃を止めたいか
API	Rate Limiting、API保護、Bot対策	どのAPIが悪用されやすいか
静的配信	CDN、Cache、DDoS	どのファイルをキャッシュし、どれをオリジンへ通すか
管理画面	WAF、アクセス制御、ログ	管理画面をそもそも公開してよいか

「WAFを入れる」という言葉だけでは、確認点が少し粗くなります。

どのパスを守るか、誤検知した時に誰が見るか、検知ログをどこで見るか。Cloudflareを前段に置くと、こういう確認点が増えます。

OCI WAFとは競合するのか

OCI WAFをすでに使っている場合、「Cloudflare WAFと競合するのでは？」という話が出ます。

これは、競合というより役割分担として見ると理解しやすいです。

レイヤー	役割
Cloudflare	インターネットエッジで広く受ける。DDoS、Bot、CDN、グローバルな入口保護
OCI	OCI側のLoad Balancer、アプリ、ネットワーク、ログ、既存セキュリティ

すべての構成で両方が必要、という話ではありません。すでにOCI WAFを使っている環境では、Cloudflare側で見る範囲と、OCI側で見る範囲を整理することになります。

たとえば、WAFのログをどちらで見るのか、ルール変更をどちらで管理するのか、既存のOCI WAF運用を残すのか。ここは構成によって変わるため、この記事では「役割が重なる場所がある」という論点として扱います。

キャッシュで見るところ

Cloudflareを使う場合、キャッシュは確認しておきたい論点の1つです。

まず、キャッシュ候補になるものと、キャッシュ対象から外したいものをURLで分けて見ます。たとえば /assets/、/downloads/、/public/ のような静的ファイルと、/api/、/login/、/me/ のようなユーザーごとのレスポンスでは、扱いが変わります。

具体例として、静的ファイルは次のように分けられます。

/assets/logo.png        -> キャッシュ候補
/assets/app.abc123.js   -> キャッシュ候補
/downloads/manual.pdf   -> 更新頻度に応じて検討
/api/orders             -> 対象外候補
/login                  -> 対象外候補

ここで言いたいのは、具体的なTTLやCache Ruleの値ではありません。静的ファイル、API、ログイン後ページ、ダウンロードファイルを同じ扱いにせず、更新頻度や利用者ごとの違いを見ておく、という話です。

ログと運用で見るところ

Cloudflareを前段に置くと、確認するログの場所が増えます。ここもCloudflare運用の完全な手順ではなく、OCI側の運用者が全体像を掴むための見方として考えます。

たとえば「利用者から遅いと言われた」ときは、次のような観点で見ます。

Cloudflare側でキャッシュヒットしているか、WAFやRate Limitingで止めていないか
Cloudflareからオリジンへの通信でエラーやタイムアウトが出ていないか
OCI Load BalancerのBackend Healthとアクセスログで、オリジンに届いているか
アプリケーションログで処理時間やエラーを確認する
必要に応じてDBや外部連携先を見る

1〜2あたりは、CloudflareのSecurity Analyticsで「Cloudflareで緩和したのか、オリジンまで届いたのか」を切り分けられます。

※ 画面はCloudflareの通常ダッシュボード（Free）で撮影。Cloudflare@OCIでの表示や利用可能機能は、バンドルや環境に応じて確認してください。

セキュリティイベントを見る画面、HTTPログを出す先、OCI Load Balancerログ、アプリケーションログの保存先がバラバラだと、障害時に人間が迷います。Cloudflare@OCIでは、Cloudflare側で止まったのか、Cloudflareから返したのか、OCIオリジンまで届いたのか、という見方が増えると捉えると分かりやすいです。

プランごとの数字も見ておく

ここまで機能面の話をしてきましたが、Cloudflare@OCIはバンドルごとに含まれる数量が決まっています。

Universal Credits Service DescriptionsのCloudflare@OCI欄を見ると、Business / Enterprise Entry / Enterprise Essentials / Enterprise Advanced の4段階で、月間リクエスト数、転送量、ドメイン数、証明書、Load Balancing Endpointsなどが分かれています。

この表は、Oracleの PaaS and IaaS Universal Credits Service Descriptions にある CLOUDFLARE@OCI SERVICE OFFERINGS の記載をもとにしています。

まず確認する数字を並べるとこうです。

バンドル	リクエスト/月	転送量	Root Domain	証明書/ACM	Load Balancing Endpoints	主な含有機能
Business	25M	1TB	1	-	-	CDN、DDoS Basic、WAF、Basic Rate Limiting、Super Bot Fight Mode
Enterprise Entry	250M	5TB	1	各1	1	Super Bot Fight Mode、Logpush、CDN、ACM、DDoS Basic、WAF
Enterprise Essentials	500M	10TB	1	各1	2	Argo Smart Routing、Logpush、ACM、CDN、DDoS Advanced、Foundation DNS、Load Balancing、Advanced/Enterprise Rate Limiting、Turnstile Managed Challenge、WAF
Enterprise Advanced	500M	10TB	1	各1	5	API Shield、Bot Management、WAF Advanced、Page Shield、Payload Inspection、Content Scanning、Turnstile Client-Side Deployment など

Businessには、Page Rules/Edge Rulesが50 Rules含まれる記載もあります。一方で、Root Domain、Page Rules/Edge Rules、Load Balancing Endpointsなどは、表の注記上「超過利用不可」とされているものがあります。つまり、リクエスト数や転送量のように超過利用を前提に見られる項目と、含有数を超えられない項目が混ざっています。

Workersは、Enterprise系の表に項目は出ていますが、included quantityは0です。機能名が表に出ている場合でも、included quantityや注記まで見ます。

要件	見ること
基本的なWeb保護	WAF、DDoS、CDN
ログや証明書運用	Logpush、証明書管理
経路制御や可用性	Load Balancing、Smart Routing
APIやBot対策	Rate Limiting、Bot対策、API保護
静的配信	CDN、Cache、Object Storageオリジン

ここで言いたいのは、「Cloudflareで何ができるか」だけでなく、「Cloudflare@OCIの対象バンドルに何が含まれるか」を見る、ということです。

たとえば、WAF、DDoS、CDN、Bot対策、API保護といった機能名だけを見ると、どの構成でも同じように見えてしまいます。一方で、実際には月間リクエスト数、転送量、対象ドメイン、証明書数、Load Balancing Endpointsなどの数量も効いてきます。

なので、Cloudflare@OCIを見るときは、一般的なCloudflareのプラン表ではなく、Oracleのサービス記述にあるCloudflare@OCIのバンドル表を起点にします。

導入前に見ておきたいこと

最後に、導入前に見ておきたい項目をまとめます。

項目	確認すること
対象	Webサイト、API、静的コンテンツ、管理画面
ドメイン	root domain、subdomain、API用ドメイン
証明書	Edge側、Origin側、更新担当
通信量	月間リクエスト数、月間転送量、ピーク
オリジン	Load Balancer、Compute、OKE、Object Storage
セキュリティ	WAF、DDoS、Bot、API保護
キャッシュ	対象パス、TTL、パージ方法
ログ	Cloudflare、OCI、アプリのどこを見るか
運用	Cloudflare Consoleを誰が操作するか
変更管理	DNS切替、ルール変更、リリース時の扱い

さいごに

Cloudflare@OCIは、難しいことをしているように見えて、基本の構図はかなりシンプルです。

OCI公開Web/APIの前段にCloudflare Edgeを置く。そこで、入口の防御、キャッシュ、ルーティング、ログを扱う。その後ろでOCIのアプリケーションやObject Storageを動かす。

Cloudflareを置くと、どこで受けて、どこで守って、どこで見るのか、という論点が増えます。この記事では、その入口になる見方を整理しました。

参考リンク

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up