サマリ
- Cloudflare@OCIが出ました。OCIユーザーはCloudflare@OCIをOCIコンソールからリクエストできるようになりました
- 構成はシンプル。OCI公開Web/APIの前段にCloudflare Edgeを置きます
- 去年からCloudflare x OCIを追ってきた身としては、「ついに公式に来たか」という感覚です
出典: Cloudflare on OCI for Secure, High-Performance Cloud Delivery | Oracle
詳細編はこちらです。
はじめに
去年、CloudflareとOCIを組み合わせてPDF配信の構成を試しました。
その後、2026年5月のOracle Developer Dayでも、OCI Object StorageとCloudflareを組み合わせた配信の話をしました。
そこに来て、Cloudflare@OCIです。正直「ついに公式に来たか」という感じです。
この記事では、概要編としてCloudflare@OCIの見方を短めにまとめます。細かい設計は次の記事に回します。
Cloudflare@OCIとは
Cloudflare@OCIは、OCIを利用するお客様がCloudflareのセキュリティ、パフォーマンス、ネットワーキング機能をOCI Consoleから申し込み、OCIの公開サービスと組み合わせて使うためのサービスです。
単なるMarketplaceではなく正式サービスとしてリリースされました。
OCI Consoleからプロビジョニングをリクエストする、という位置づけです。
本記事執筆時点では、手元のOCI Consoleで東京リージョン（Japan East / Tokyo）と大阪リージョン（Japan Central / Osaka）の両方にCloudflare@OCIが表示されることを確認しています。
画面上は「アイデンティティとセキュリティ」→「パートナー・オファリング」配下にあります。
通信の流れはこうです。
ユーザーからの通信をCloudflare Edgeで受け、WAF、DDoS対策、Bot対策、CDN、キャッシュ、ルーティング最適化などを適用します。その後、OCI Load Balancer、Compute、OKE、Object Storageなどのオリジンへ通信を届けます。
ここは大事で、CloudflareがOCIの中にデプロイされるわけではありません。OCI公開サービスの前段にCloudflareのエッジレイヤーを置く、という話です。
何がうれしいのか
| 観点 | Cloudflare Edgeでやること | 代表的な機能 |
|---|---|---|
| 守る | 怪しいHTTPリクエスト、Bot、大量アクセスをオリジン到達前に止める | WAF、DDoS対策、Bot対策、API保護、Rate Limiting |
| 速くする | 静的コンテンツをエッジから返し、OCIオリジンへのアクセスを減らす | CDN、Cache、Smart Routing |
| まとめる | DNS、証明書、ログ、ロードバランシングをCloudflare Console側で運用する | DNS、証明書管理、Load Balancing、Logpush |
この中で個人的に待望していたのは「速くする」です。Object Storageに置いた画像やPDFを毎回オリジンまで取りに行かず、Cloudflareのキャッシュから返せると、ブラウザで触ったときの待ち時間も、OCI側で受けるアクセスも明らかに変わります。
数字をこの記事では出しませんが、Cloudflare x OCIを試したときに一番腹落ちしたのはここでした。アプリケーションサーバーを太らせる前に、エッジで返せるものはエッジで返す。かなり地味ですが、効きます。
ユースケース
OCI公開Webサイトの保護
OCI Load Balancer、Compute、OKEなどで公開しているWebサイトの前段にCloudflareを置きます。
WAF、DDoS対策、Bot対策、Rate Limitingで、オリジンに届く前の通信をさばきます。攻撃を受けてからOCI側で頑張るより、入口で落とす発想です。
OCI公開APIの保護
APIは普通のWebサイトより、過剰リクエストやBot、認証前の悪用が目立ちます。
Cloudflare@OCIでは、WAF、Rate Limiting、Bot対策、API保護を組み合わせて、APIの前段を守れます。API GatewayやOKE、Load Balancer配下のAPIをどう守るかは、設計編で掘ります。
OCI Object Storageの静的コンテンツ配信
画像、PDF、動画サムネイル、ダウンロードファイルをObject Storageに置き、Cloudflare経由で配信する構成です。
これは個人的にも一番好きな領域です。アプリケーションサーバーを通さず、Object StorageとCloudflareで配信を作ると構成がかなりシンプルになります。キャッシュ設計がうまくはまると、オリジンアクセスを減らせます。
導入前に見るところ
Cloudflare@OCIは前段にエッジを置く構成なので、対象システムだけでなく、運用面も最初に見ておくと話が早いです。
最初の棚卸しはこのあたりです。
| 項目 | 確認すること |
|---|---|
| 対象 | Webサイト、API、静的コンテンツ、管理画面など |
| ドメイン | root domain、subdomain、証明書数 |
| 通信量 | 月間リクエスト数、月間転送量、ピークトラフィック |
| オリジン | OCI Load Balancer、Compute、OKE、Object Storageなど |
| セキュリティ | WAF、DDoS、Bot、API保護、Rate Limiting |
| 配信 | キャッシュ対象、TTL、パージ運用 |
| ログ | Security Events、HTTPログ、SIEM連携、保存先 |
| 運用 | Cloudflare Consoleを誰が操作するか |
まとめ
Cloudflare@OCIは、OCI公開Web/APIの前段にCloudflare Edgeを置くための公式な選択肢です。
インターネットとの境界にWAF、DDoS、CDN、Bot対策、API保護、ログ、証明書、ロードバランシングを、公開面の設計としてまとめて考えられます。
参考リンク
- Cloudflare on OCI for Secure, High-Performance Cloud Delivery | Oracle
- Cloudflare Integrates Services with Oracle Cloud Infrastructure to Help Customers Supercharge Applications and AI Workloads | Cloudflare
- Oracle PaaS and IaaS Universal Credits Service Descriptions
- Cloudflare x OCI はいいぞ！
- [T1-3] OCIとCloudflareで繋ぐ！ アウトバウンド転送量0の超高速配信の世界