CloudFront VPCオリジンとは？ALB・EC2をプライベートのまま公開する設定と制約

VPCオリジン（VPC origins）は、プライベートサブネットに置いたApplication Load Balancer（ALB）・Network Load Balancer（NLB）・EC2インスタンスを、パブリックIPを持たせないままAmazon CloudFrontのオリジンにできる機能です。2024年11月に提供が始まり、CloudFrontを単一の入口（single point of entry）に据える構成が公式に位置づけられました。仕組みと前提条件、コンソール・AWS CLI・CloudFormationでの作成手順、公式ドキュメントに明記された制約、コスト効果を、AWSの一次情報から整理します。

まとめ：VPCオリジン導入の判断ポイント

• 対象は3種類のみ：オリジンにできるのはALB・NLB・EC2インスタンスです。ARNで指定するため、オンプレミスや他社クラウドのサーバーは対象外です。
• プライベートサブネットでもインターネットゲートウェイは必要：VPCにインターネットゲートウェイをアタッチする要件があります。ルーティングには使われないため、ルートテーブルの変更は不要です。
• ネットワークACLは効かない：VPCオリジン宛のトラフィックにはサブネットレベルの許可・拒否ルールが評価されません。アクセス制御はセキュリティグループで行います。
• 使えない機能がある：gRPCトラフィック、Lambda@Edgeのオリジンリクエスト／オリジンレスポンストリガー、Gateway Load Balancer、TLSリスナーを使うNLBは非対応です。
• コスト効果はパブリックIPv4の削減分：パブリックIPv4アドレスは使用中・アイドルを問わず1時間あたり0.005 USDです。2つのアベイラビリティーゾーンで動くインターネット向けALBを内部向けに変えると、月あたり7.3 USD以上が不要になります。
• 定額プランではBusiness以上が必要：従量課金なら追加料金なしで使えますが、2025年11月開始の定額プランではVPCオリジンがBusiness（月200 USD）とPremiumのみの機能です。
• 反映には時間がかかる：VPCオリジンのステータスが「デプロイ済み」になるまで最大15分かかります。稼働中のディストリビューションへ後付けする場合は、継続的デプロイのステージング環境での検証が推奨されます。

VPCオリジンの通信経路と従来構成との違い

サービス管理ENIを経由する到達経路

VPCオリジンを定義すると、CloudFrontがそのサブネット内にサービス管理のElastic Network Interface（ENI）を作成します。リクエストはエッジロケーションで受け取られ、このENIを通ってプライベートサブネット内のオリジンへ到達するため、オリジン側にパブリックIPアドレスは不要です。開発者ガイドはこの経路を「プライベートで安全な接続」と説明しています。

ENIを作る都合上、対象のプライベートサブネットには利用可能なIPv4アドレスが最低1つ必要です。プライベートアドレスで構わず追加費用も発生しませんが、CIDRを絞り込みすぎてIPが枯渇しているとVPCオリジンの作成自体が失敗します。

パブリックALB＋マネージドプレフィックスリスト方式との差分

VPCオリジン以前は、インターネット向けALBをそのまま公開し、CloudFrontのマネージドプレフィックスリストをセキュリティグループのインバウンドに設定して「CloudFront以外を弾く」構成が一般的でした。この方式ではオリジンが露出したままで、プレフィックスリストの範囲内であれば他のAWSアカウントのディストリビューションからも到達できるため、カスタムヘッダーによる照合で補強する運用が必要でした。

VPCオリジンでは、CloudFrontが作成するサービス管理セキュリティグループ CloudFront-VPCOrigins-Service-SG からの通信だけを許可する設定が選べます。開発者ガイドはこの方式について、自分のCloudFrontディストリビューションだけにトラフィックを限定するため、より制限的であると記載しています。S3オリジンに対するCloudFrontでOrigin Access Control (OAC)を利用したアクセス制御の概要と利点と同じ発想を、ALB・EC2などのカスタムオリジンへ広げた仕組みと言えます。

どちらのロードバランサーを内部向けに置くかは、HTTPヘッダーベースのルーティングが必要かどうかで決まります。ALBとNLBの機能差はALBとELBの違いとは？AWSロードバランサーの種類・使い分け・リスナールール設定を解説、CloudFront自体の課金体系やエッジ機能の全体像はAmazon CloudFrontとは？仕組み・料金プランとエッジ機能・採用判断を実装者目線で解説で扱っています。

VPCオリジン作成前に満たすべき前提条件

インターネットゲートウェイが必要な理由

オリジンをプライベートサブネットに置くにもかかわらず、開発者ガイドはVPCオリジンのリソースを収容するVPCにインターネットゲートウェイを追加する必要があると明記しています。理由も併記されており、インターネットゲートウェイは「そのVPCがインターネットからトラフィックを受け取れることを示すため」に必要で、サブネット内のオリジンへのルーティングには使われず、ルーティングポリシーの更新も不要とされています。

したがって、アタッチしてもプライベートサブネットのルートテーブルに 0.0.0.0/0 を足す必要はなく、ルートテーブルを変更しない限りサブネットはプライベートのままです。「IGWを付けたらプライベートではなくなる」という懸念で止まる必要はありません。既存VPCにIGWが無い場合はこの1点だけで作成が通らないため、最初に確認してください。

セキュリティグループの2通りの許可方式

オリジンとなるALB・NLB・EC2インスタンスには、セキュリティグループがアタッチされている必要があります。NLBは既定でセキュリティグループを持たず、既存NLBへ後から追加することもできないため、作成時点で割り当てておくかどうかが分かれ目になります。インバウンド許可の方法は次の2つです。

セキュリティ要件が厳しい環境ではサービス管理セキュリティグループを選びます。ただしこれはVPCオリジン作成後に自動生成されるため、作成前に許可設定を済ませたい場合はマネージドプレフィックスリスト方式を先に入れ、後から切り替える段取りになります。なお CloudFront-VPCOrigins-Service-SG で始まる名前はAWSの予約パターンで、同じ接頭辞のセキュリティグループを自作してはいけないと明記されています。AWSが完全に管理するため、編集しないこととされています。

対象リソースのステータス条件

開発者ガイドは、オリジンにするリソースについて「完全にデプロイされActive状態（fully deployed and in Active status）でなければVPCオリジンとして使えない」と記載しています。作成途中のALBや起動直後のEC2インスタンスをARNで指定しても受け付けられません。CloudFormationで一括構築する場合は、ロードバランサーの作成完了とVPCオリジン作成の依存関係を明示しておくと、この待ち合わせで失敗しにくくなります。

VPCオリジンの作成手順（コンソール・CLI・CloudFormation）

コンソールで新規ディストリビューションに割り当てる流れ

コンソールでは、ディストリビューションを作る前にVPCオリジンを先に作ります。CloudFrontコンソールで「VPC オリジン」から「VPC オリジンを作成」を選び、オリジンARNにALB・NLB・EC2インスタンスのARNを指定します。ドロップダウンにARNが出てこない場合は、対象リソースのARNを直接貼り付ける運用が案内されています。

作成後、ステータスが「デプロイ済み」に変わるまで最大15分かかります。この待ち時間を挟んでから「ディストリビューションを作成」に進み、オリジンドメインのドロップダウンで作成済みのVPCオリジンを選びます。

AWS CLIでのcreate-vpc-origin実行例

CLIでは aws cloudfront create-vpc-origin を使い、--vpc-origin-endpoint-config に設定を渡します。APIリファレンスでは Name、Arn、HTTPPort、HTTPSPort、OriginProtocolPolicy が Required: Yes、OriginSslProtocols のみ Required: No です。入れ子構造があるためJSONファイルで渡すのが確実です。

cat > vpc-origin.json <<'JSON'
{
  "VpcOriginEndpointConfig": {
    "Name": "internal-alb-origin",
    "Arn": "arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:loadbalancer/app/internal-alb/0123456789abcdef",
    "HTTPPort": 80,
    "HTTPSPort": 443,
    "OriginProtocolPolicy": "http-only",
    "OriginSslProtocols": {
      "Quantity": 1,
      "Items": ["TLSv1.2"]
    }
  }
}
JSON

aws cloudfront create-vpc-origin --cli-input-json file://vpc-origin.json

レスポンスには VpcOrigin 構造体（Id、Arn、AccountId、Status、CreatedTime、LastModifiedTime、VpcOriginEndpointConfig）と Location、ETag が返ります。この Id をディストリビューションのオリジン設定から参照します。

CloudFormationのAWS::CloudFront::VpcOrigin定義

CloudFormationのリソースタイプは AWS::CloudFront::VpcOrigin です。必須プロパティは VpcOriginEndpointConfig のみで、Tags は任意です。

Resources:
  AlbVpcOrigin:
    Type: AWS::CloudFront::VpcOrigin
    Properties:
      VpcOriginEndpointConfig:
        Name: internal-alb-origin
        Arn: !GetAtt InternalAlb.LoadBalancerArn
        HTTPPort: 80
        HTTPSPort: 443
        IpAddressType: ipv4
        OriginProtocolPolicy: http-only
        OriginSSLProtocols:
          - TLSv1.2

ここで注意したいのが、CloudFormationとAPI／CLIでプロパティ定義が食い違う点です。差分は3つあります。第一に、SSL関連プロパティの表記がCloudFormationでは OriginSSLProtocols、API・CLIでは OriginSslProtocols です。第二に、必須項目の範囲が違い、CloudFormationで必須なのは Arn と Name だけで、HTTPPort・HTTPSPort・OriginProtocolPolicy は任意です（APIではいずれも必須）。第三に、IpAddressType はCloudFormationにのみ定義されており、APIリファレンスの VpcOriginEndpointConfig には存在しません。CLI用のJSONをそのままテンプレートへ転記すると、プロパティ名の検証で落ちます。

許容値は、OriginProtocolPolicy が http-only・match-viewer・https-only の3値、IpAddressType が ipv4 と dualstack、OriginSSLProtocols が SSLv3・TLSv1・TLSv1.1・TLSv1.2 です。HTTPPort の既定値は80、HTTPSPort の既定値は443です。OriginSSLProtocols はCloudFrontがオリジンへHTTPS接続する際の最小SSL/TLSプロトコル設定であり、TLSv1.2以外を選ぶ実務上の理由はほとんどありません。戻り値としては Ref のほか、Fn::GetAtt で AccountId、Arn、CreatedTime、Id、LastModifiedTime、Status を取得できます。Terraformを使う場合は、AWSプロバイダーの aws_cloudfront_vpc_origin リソースが vpc_origin_endpoint_config ブロックで同じ設定を担います。

稼働中ディストリビューションへ後付けする場合の継続的デプロイ

すでに本番稼働しているディストリビューションにVPCオリジンを足すとき、公式手順は継続的デプロイ（Continuous Deployment）での検証を推奨しています。VPCオリジンを作成したうえでステージングディストリビューションを作り、そこにVPCオリジンを設定してテストし、問題がなければプライマリへ昇格させる流れです。ただし開発者ガイドには「ステージングディストリビューションを作らずに既存ディストリビューションへVPCオリジンを追加することも選択できる」と明記されており、必須ではありません。この手順が使えるのは従量課金の場合に限られます（理由は後述のコスト章で扱います）。

見落としやすいのは最後の一手です。昇格しただけではオリジンはまだパブリックサブネットに置かれたままなので、ルートテーブルの関連付けを変更してサブネットをプライベート化する作業が別途必要です。この操作を経て初めてオリジンはインターネットから発見できなくなり、CloudFrontからのプライベートアクセスだけが残ります。

EC2インスタンスをオリジンにする場合の設定値と可用性リスク

オリジンドメインに指定する値

EC2インスタンスをVPCオリジンにする構成は「CloudFrontからEC2へ直接配信したい」という要件に対する公式の答えですが、設定値が他のオリジンと違います。ALBやNLBはドロップダウンから選べるのに対し、EC2インスタンスの場合はインスタンスのプライベートIP DNS名をオリジンドメイン欄へ貼り付ける必要があります。パブリックDNS名やインスタンスIDでは通りません。

ロードバランサーを挟まない構成のリスク

手軽ですが、判断は慎重に行うべきです。単一インスタンス構成では障害時の切り替え先がなく、インスタンスタイプ変更やAMI更新のたびにVPCオリジンの再設定が要ります。その再設定は後述のとおり、紐づく全ディストリビューションからの切り離しと、最大15分の再デプロイ待ちを伴います。入れ替わりの多いEC2をオリジンに固定すると運用負荷が高くなります。検証環境や配信量の小さい社内向けアプリケーションならEC2直結で十分ですが、可用性要件のある本番系では内部ALBを挟む構成を推奨します。

VPCオリジンの制約と運用上の落とし穴

ネットワークACLが評価されない仕様

影響が最も大きい制約です。開発者ガイドは、VPCオリジンのトラフィックについてサブネットレベルの許可・拒否ルール、すなわちネットワークACL（NACL）が評価されないと明記しています。「サブネットのNACLで拒否しているから安全」という判断はVPCオリジン経由の通信に当てはまらず、多層防御としてNACLを使っている組織はその層が機能しない前提で設計を組み直す必要があります。アクセス制御はセキュリティグループに集約し、監査時の説明もセキュリティグループとサービス管理セキュリティグループの組み合わせで行うことになります。

gRPCとLambda@Edgeオリジントリガーの非対応

VPCオリジンはgRPCトラフィックをサポートしません。gRPCのAPIを配信したい場合は別の構成を検討することになります。

Lambda@Edgeのオリジンリクエストトリガーとオリジンレスポンストリガーも非対応です。オリジンリクエストのタイミングでヘッダーを書き換えたり、動的にオリジンを切り替えたりしている既存構成は、そのままVPCオリジンへ移せません。ビューワーリクエスト・ビューワーレスポンスのトリガーは対象外の記載がないため、その処理をビューワー側のトリガーやCloudFront Functionsへ寄せられるかが移行可否の分かれ目になります。オリジンを動的に切り替える用途については、2025年4月にCloudFront FunctionsのオリジンモディフィケーションがVPCオリジンとオリジングループに対応したため、オリジンIDを渡す形で代替できます。AWS CloudFront、API Gateway、Lambdaの連携とは何か？基本解説のようなサーバーレス構成と組み合わせる場合は、この制約を先に確認してください。

オリジンに指定できないロードバランサー構成

Gateway Load Balancerはオリジンとして追加できません。また、TLSリスナーを使用するNetwork Load Balancerもオリジンにできません。NLBでTLS終端を行っている既存構成をVPCオリジンへ移す場合は、TLS終端の位置をCloudFront側またはバックエンド側へ寄せる設計変更が必要になります。

設定変更時に必要な切り離し手順

VPCオリジンの設定を後から変更する手順は、直感に反する順序になっています。公式手順では、まず対象のVPCオリジンがキャッシュビヘイビアのデフォルトオリジンになっていないことを確認したうえで、ディストリビューションのオリジンタブから当該VPCオリジンを削除して関連付けを解除します。複数のディストリビューションに紐づいている場合は、そのすべてで解除が必要です。そのうえでVPCオリジンを編集し、再びデプロイ済みになるまで最大15分待ってから、各ディストリビューションへオリジンとして再登録します。

ポート番号やオリジンプロトコルポリシーを1つ変えるだけでもこの手順を踏みます。設計段階でポートとプロトコルポリシーを確定させておかないと、後の変更が配信断を伴う作業になります。

リージョンとアベイラビリティーゾーンの制限

VPCオリジンは商用リージョンの多くで利用できますが、一部のアベイラビリティーゾーンが除外されています。東京リージョン（ap-northeast-1）で除外対象となるのは apne1-az3 です。ほかにバージニア北部（us-east-1）の use1-az3、北カリフォルニア（us-west-1）の usw1-az2、カナダ中部（ca-central-1）の cac1-az3 が除外対象として明記されています。大阪リージョン（ap-northeast-3）に除外の注記はありません。

アベイラビリティーゾーンIDはAWSアカウントごとにゾーン名との対応が変わります。既存サブネットがどのゾーンIDに属するかをVPCコンソールやCLIで確認しておかないと、除外ゾーンのサブネットしか用意していない場合に原因の分かりにくい作成エラーとなります。

VPCオリジンのコスト効果と料金の考え方

パブリックIPv4アドレス削減の試算

金銭的な効果は、主にパブリックIPv4アドレスの削減から生まれます。AWSのVPC料金ページでは、使用中のパブリックIPv4アドレスもアイドル状態のパブリックIPv4アドレスも1時間あたり0.005 USDと記載されており、リソースへの関連付けの有無で料金は変わりません。

インターネット向けALBは有効化したアベイラビリティーゾーンごとにパブリックIPv4アドレスを消費します。2ゾーン構成なら2アドレスで、月を730時間として 0.005 × 2 × 730 = 7.3 USD が毎月かかる計算です。これは下限で、負荷に応じてALBのノードがスケールアウトすれば消費アドレス数とともに増えます。内部向けALBへ切り替えてVPCオリジン経由の配信にすると、この分がゼロになります。VPCオリジンが使うENIのIPv4アドレスはプライベートアドレスであり、追加費用は発生しないと開発者ガイドに明記されています。

ALB1台で月7.3 USDから、という規模はそれ自体で導入を決める額ではありませんが、パブリックサブネットのALBやEC2が数十台ある環境では無視できない差になります。CloudFrontとAWSオリジン間のデータ転送も、CloudFront経由でトラフィックを処理する場合は自動的に免除されると料金ページに記載されています。

定額プランではBusiness以上が要件

「VPCオリジンに追加料金はかからない」という2024年11月の発表時の説明が当てはまるのは、従量課金（pay-as-you-go）を使う場合です。2025年11月に加わった定額プラン（Free 月0 USD／Pro 月15 USD／Business 月200 USD／Premium 月1,000 USD）では扱いが変わります。開発者ガイドのプラン別機能表で「Private origins within VPC」に印が付くのはBusinessとPremiumだけで、FreeとProでは利用できません。

加えて、定額プランのUnsupported featuresには継続的デプロイとステージングディストリビューションが挙げられており、代替として従量課金の利用が案内されています。段階的に検証しながらVPCオリジンへ移行したい場合は、定額プランではなく従量課金を選ぶ判断になります。

なお、キャッシュを伴わずグローバル配信の高速化だけが目的なら、AWS Global Acceleratorとは何か：グローバルネットワーク最適化の概要で扱うサービスが適する場合もあります。VPCオリジンはCloudFrontを入口に据える構成の部品です。

VPCオリジンを採用すべきでないケース

次の3条件のいずれかに当てはまるなら、移行は見送るか構成そのものを再設計してください。1つ目はLambda@Edgeのオリジンリクエスト／オリジンレスポンストリガーで認証やヘッダー操作を行っている構成、2つ目はgRPCが通信要件の中心にある構成です。前者はロジックをCloudFront Functionsやビューワートリガーへずらせるかを先に検証し、それができないなら選べません。後者に代替の余地はありません。

3つ目が判断の分かれ目です。ネットワークACLによる通信制御を統制要件として文書化している組織では、NACLが評価されない以上、統制文書と実際の防御構成が食い違います。技術的に動作しても監査での説明責任を果たせない構成は採用すべきではないため、セキュリティグループへ制御を集約する形で統制設計を改訂できるかを移行判断より前に確認してください。

逆に、HTTPまたはHTTPSで配信する一般的なWebアプリケーションで、オリジンをインターネットから隠すことが主目的であれば、VPCオリジンは追加料金なしでその要件をほぼそのまま満たします。

よくある質問

VPCオリジンとVPCエンドポイント（PrivateLink）は何が違いますか

方向が逆です。VPCエンドポイントは、自分のVPC内からAWSサービスや他社サービスへプライベートに接続するための仕組みです。VPCオリジンは、CloudFrontから自分のVPC内のリソースへ到達するための仕組みで、CloudFrontが作成するサービス管理ENIを経由します。CloudFrontのオリジンをプライベート化する目的でVPCエンドポイントを作る必要はありません。

パブリックサブネットにあるALBでもVPCオリジンにできますか

技術的には可能です。既存のパブリックサブネット構成から移行する公式手順も、パブリックサブネットのリソースをVPCオリジンとして登録し、検証と昇格を終えた後にルートテーブルの関連付けを変更してサブネットをプライベート化する順序になっています。ただし開発者ガイドはプライベートサブネットでホストされたリソースを前提に記載しており、セキュリティ上の効果はこのプライベート化まで完了して初めて得られます。

別のAWSアカウントにあるALBをVPCオリジンにできますか

できます。提供開始当初はCloudFrontとオリジンが同一アカウントにある必要がありましたが、2025年11月にクロスアカウント対応が追加されました。同一組織内かどうかは問われず、共有はCloudFrontコンソールから行うか、AWS Resource Access Manager（AWS RAM）を使います。マルチアカウント構成でアプリケーション用アカウントと配信用アカウントを分けている場合の選択肢になります。

オリジンのポート番号を80・443以外に変更できますか

変更できます。VpcOriginEndpointConfig の HTTPPort と HTTPSPort で指定し、既定値はそれぞれ80と443です。ただし変更にはディストリビューションからの切り離しと再登録が必要で、デプロイ完了まで最大15分かかるため、稼働後の変更は計画的に行ってください。

オンプレミスや他社クラウドのサーバーをVPCオリジンにできますか

できません。VPCオリジンはARNで指定するALB・NLB・EC2インスタンスのみを対象としており、VPC外のサーバーは対象外です。オンプレミス側をオリジンにする場合は、従来どおりカスタムオリジンとして公開し、CloudFrontのマネージドプレフィックスリストやカスタムヘッダーによる照合でアクセスを絞る構成になります。

関連記事

• Amazon CloudFrontとは？仕組み・料金プランとエッジ機能・採用判断を実装者目線で解説
• CloudFrontでOrigin Access Control (OAC)を利用したアクセス制御の概要と利点
• ALBとELBの違いとは？AWSロードバランサーの種類・使い分け・リスナールール設定を解説
• AWS CloudFront、API Gateway、Lambdaの連携とは何か？基本解説
• AWS Global Acceleratorとは何か：グローバルネットワーク最適化の概要