G-gen の杉村です。当記事では Google Cloud の Virtual Private Cloud（略称 VPC）について徹底解説します。なお当記事は VPC の基本機能に絞った「基本編」です。「応用編」もあわせてご参照ください。

Virtual Private Cloud（VPC）とは
ネットワークとサブネット
オンプレミスや他のクラウドとの接続
ルート
ファイアウォール（Cloud NGFW）
インターネットとのアクセス
Google Cloud サービスへのプライベートサービスアクセス
運用
料金
応用編へのリンク

Virtual Private Cloud（VPC）とは

Virtual Private Cloud（以下、VPC）とは Google Cloud（旧称 GCP）に仮想ネットワークを構築するためのサービスです。構築された VPC ネットワークは、他の Google Cloud 利用者からは完全に独立したプライベートネットワークとなります。

VPC ネットワークはサブネットと呼ばれる小分けしたネットワークに分割され、サブネットにはプライベート IP アドレス帯が割り当てられます。サブネット内には Compute Engine の仮想マシン（VM）を配置したり、Google Kubernetes Engine（GKE）のクラスタを配置したり、App Engine（Flexible）のアプリを配置することができます。

VPC ネットワークは、IPSec VPN（サービス名 Cloud VPN）や専用線（サービス名 Cloud Interconnect）を使って、オンプレミスのネットワークや、他のパブリッククラウドのネットワークと接続することもできます。

参考 : Virtual Private Cloud（VPC）の概要

VPC は、Andromeda という Google のネットワーク仮想化技術を使って実装されています。仮想的なネットワークのため、物理ネットワークで考慮が必要な「セグメントを小さく分けることでブロードキャストドメインを分割し、ネットワークの輻輳を軽減する」といった考慮は必要ありません。そのため、物理的なネットワークとはネットワーク設計の勘所が異なる点に注意が必要です。

ネットワークとサブネット

ネットワーク

VPC ネットワークまたは単にネットワークとは、VPC で構築された1つのネットワークのことを指しています。

ネットワークはグローバルリソース です。これは、ネットワークがリージョンをまたぐ存在であることを示しています。

他のパブリッククラウドの代表例として Amazon Web Services（AWS）を例に取ると、VPC はリージョンリソースであり、リージョンごとに VPC を作成する必要があります。これに対して Google Cloud の VPC はグローバルリソースであるため、作成時にリージョンを指定する必要がありません。ネットワークの中にサブネットを作成する際に、リージョンを指定します。

また VPC ネットワークは IP アドレス帯を持ちません。Google Cloud では VPC 内のサブネットが、サブネットごとに IP アドレス帯を持ちます。このことから、VPC は「サブネットをまとめるグルーピングリソースである」と解釈することもできます。

ネットワークは中に「ルート」「ファイアウォールルール」などの子リソースを持ちます。これらもグローバルリソースです。

参考 : VPC ネットワーク

サブネット

サブネット（もしくはサブネットワーク）は、VPC ネットワークの中に存在する、小分けされたネットワークです。

サブネットはリージョンリソースであるため、作成時にリージョンを指定します。また、作成時に IP アドレス帯を CIDR 形式で指定します。

サブネットを作って初めて、その中に Compute Engine の VM（仮想サーバー）などを配置することができるようになります。

前述しましたが、VPC ネットワークやサブネットは仮想的な存在のため「セグメントを小さく分けることでブロードキャストドメインを分割し、ネットワークの輻輳を軽減する」といった考慮は必要ありません。

また、セグメントを分けることは通信制御にはなりません。同一 VPC に所属するサブネット同士は自動的にルートが生成され、相互に通信することができます。サブネット同士の通信制御を行いたいときは、後述のファイアウォールルールにより行います。

「同一 VPC に所属するサブネット同士は通信できる」という原則は、リージョンが異なっても変わりません。違うリージョンのサブネット同士でも、同一 VPC に所属していれば相互に通信することができます。

参考 : サブネット

サブネットの IP アドレス

サブネットには CIDR 形式で IP アドレス範囲を指定します。サブネットには IPv4 または IPv6 範囲を割り当てることが可能です。

IPv4 では、10.0.0.0/8、172.16.0.0/12、192.168.0.0/16、すなわち RFC 1918 のプライベート IP アドレス範囲の中から割り当て可能なほか、その他のいくつかの範囲が利用可能です。

最小のサブネットサイズは /29（IP アドレス数が8個。後述の予約アドレスを除くと利用可能は4個のみ）です。

参考 : 有効な IPv4 範囲
参考 : IPv4 サブネット範囲の制限事項

なおサブネットの IP アドレスの第4オクテットのうち、最初の2つと最後の2つの IP アドレスは Google Cloud によって予約されているため、ユーザーは利用することができません。

例えば 10.1.2.0/24 というサブネットであれば、10.1.2.0、10.1.2.1、10.1.2.254、10.1.2.255 は予約アドレスであり、VM インスタンス等を配置することができないことになります。

参考 : IPv4 サブネット範囲で使用できないアドレス

その他に、禁止されているサブネット範囲が存在します。Google に予約されている 199.36.153.4/30 や 199.36.153.8/30、リンクローカルアドレスである 169.254.0.0/16 などです。詳細なリストは以下の公式ドキュメントに記載があります。

参考 : 禁止されている IPv4 サブネット範囲

サブネット作成モード

VPC 構築時にサブネットを作成する際、自動モードとカスタムモードから選択できます。

自動モードを選択すると、全リージョンに1つずつ、自動的にサブネットが作成されます。各サブネットの CIDR ブロックは 10.128.0.0/9 の範囲から決まった CIDR が自動的に設定されます。このモードでは、不要なリージョンにも自動的にサブネットが作成されること、また CIDR が特定のものになってしまうことから、検証目的等 でのみ使うことが推奨されます。自動モードの VPC で割り当てられる IP アドレス範囲は、以下のドキュメントを参照してください。

参考 : 自動モードの IPv4 範囲

一方のカスタムモードでは、自動的にサブネットが作成されることはなく、サブネット作成先のリージョンや CIDR はユーザーが指定します。VPC ネットワークを作成すると、サブネットのない空のネットワークができあがるため、「東京リージョンに 192.168.0.0/24 でサブネットを作成」のように個別にサブネットを作成していきます。本番用途等ではこちらのカスタムモードを利用することが推奨されています。

参考 : サブネット作成モード

VPC 間接続

異なる VPC 間同士は、VPC ネットワークピアリング機能で接続することができます。当機能では、異なる Google Cloud プロジェクトにある VPC とも接続させることが可能です。

VPC ネットワークピアリングの使用条件として、サブネットの IP アドレス範囲が重複していないことがあります。また VPC ネットワークピアリング経由では、推移的ピアリングはできないなどの制限もあります。つまり、VPC A <=> VPC B <=> VPC C がそれぞれピアリングされている場合で、VPC A と VPC C が直接ピアリングされていない場合、VPC A と VPC C は通信することができません（間の VPC B を経由して反対側に到達することはできません）。これは、いわゆる「2ホップ制限」として知られています。

参考 : VPC ネットワークピアリング

また Cloud VPN を使って VPC 間を接続することも可能です。Cloud VPN では推移的な接続が可能ですが、料金が発生する点が VPC ネットワークピアリングとの違いです。

これらの仕様は、応用編の記事で紹介します。

オンプレミスや他のクラウドとの接続

VPC は Cloud VPN と呼ばれる IPSec VPN の仕組みや、Cloud Interconnect という専用線サービスを使うことで、オンプレミスの既存ネットワークや、他のパブリッククラウドのネットワークと接続することが可能です。

これによりインターネットを介さず、プライベート IP を用いて他のネットワークから Google Cloud の VPC 内のリソースにアクセスすることができます。

他のネットワークと VPC の接続においては、原則として接続される他のネットワークと VPC サブネットの IP アドレス帯が重複していないことが条件です。ルーティングの設定によっては一部が重複していても通信が可能になる場合がありますが、シンプルなルート設計のためには、VPC 設計の際に他のネットワークとの接続の可能性は十分考慮に入れることが推奨されます。

当記事では Cloud VPN や Cloud Interconnect については詳述しないため、以下のドキュメントをご参照ください。

参考 : Cloud VPN の概要
参考 : Cloud Interconnect の概要

また Cloud VPN については以下の記事もご参照ください。

blog.g-gen.co.jp

さらに、Google Cloud の VPC と、Amazon Web Services（AWS）や Microsoft Azure など他クラウドのネットワークを接続することができる Cross-Cloud Interconnect と呼ばれる専用線サービスも存在します。以下の記事をご参照ください。

blog.g-gen.co.jp

ルート

ルートは、VPC ネットワーク内のパケットが従う、ルーティングのルールです。VPC ネットワーク単位でルートテーブルが存在します。

注意すべき点は、VPC のルートは「VPC ネットワークの中から外へパケットが到達するための経路を指定する」ルールである、という点です。逆方向、つまり VPC の外から中方向への経路は自動的に生成され、削除することができません。

ルートには、最初から Google Cloud により生成されるシステム生成ルートとユーザーが自分で定義するカスタムルートがあります。インターネットへ通信するためのデフォルトゲートウェイルートや、同一 VPC 内のサブネット同士のルートは自動的に生成されます。なお、前者は削除したり置換したりできますが、後者は削除や変更ができません。

参考 : ルート

前述の通り、同一 VPC ネットワーク内のサブネット同士の通信は自動的にできるようになりますので、特に追加の設定は必要ありません。また VPN や専用線で VPC ネットワークを他のネットワークと接続する際も、仕様上、多くの場合で BGP による動的ルート交換が行われるため、VPC ルートテーブルに手動でルートを追加することは稀です。ルートの追加設定が必要になるのは、以下のような限られた場面です。

特定ネットワークへのパケットを VM 上の仮想アプライアンスへルーティングしたい場合
Cloud VPN の Classic VPN 機能を使っており、静的ルートの追加が必要な場合

このように、Google Cloud の VPC では、ルートを手動で編集する機会は少ないといえます。むしろ VPN、専用線、VPC Peering 等で他ネットワークへ接続する際に、ルート交換が正常に行われているかを確認する際などに参照する方が多いです。

ファイアウォール（Cloud NGFW）

Google Cloud の VPC には備え付きのファイアウォール機能があります。これは Cloud Next Generation Firewall（以下、Cloud NGFW）という Google Cloud プロダクトとしてブランディングされていますが、VPC と密に連携しています。

参考 : Cloud NGFW の概要

Cloud NGFW はフルマネージドの分散システムであり、一般的なファイアウォールアプライアンスのようなイメージではなく、VPC 内の通信に対して透過的に制御をかけます。ユーザは、Google Cloud コンソールや gcloud コマンドラインでルールを追加するだけでよく、インフラの管理などを考える必要がありません。

当機能は Amazon Web Services（AWS）における「セキュリティグループ」に相当しています。

詳細は以下の記事で解説しています。以下の記事は Cloud NGFW の全体像を解説していて読むのに時間がかかるので、基本的な理解だけをしたい人は、まずは以下記事の「概要」「VPC ファイアウォールルール」だけをお読みください。

blog.g-gen.co.jp

インターネットとのアクセス

VM とインターネット間の通信

VPC ネットワーク（サブネット）内からインターネットへ接続することも可能です。

VPC にはデフォルトインターネットゲートウェイ（default-internet-gateway）が存在し、サブネット内の VM はこれを通じてインターネットと通信することができます。 VM がインターネットと通信するには以下の条件を全て満たしている必要があります。

VPC のルートにデフォルトインターネットゲートウェイへの経路が存在する
VM が External IP（外部 IP、いわゆる Public IP）アドレスを持つ
VM とインターネット上のノード間の通信が VPC ファイアウォールで許可されている

VPC ネットワークが作成されると、いくつかのルートがシステムによって自動生成されます。その中には 0.0.0.0/0 をデフォルトインターネットゲートウェイへ向けるルートも存在しているため 1. に関して、追加の手順は必要ありません。

参考 : システム生成のデフォルトルート

2. について、全ての VM は Internal IP（内部 IP、Private IP）アドレスを持ちますが、インターネットと通信するための External IP（いわゆる Public IP）アドレスについては、VM の構築時に持たせるかどうかを選択できます。VM 構築後でも、停止時であれば Exnternal IP アドレスの有無を変更できます。

参考 : 外部 IP アドレス

3. については、VPC のファイアウォール（Cloud NGFW）にて VM とインターネット上のノードの間の通信が許可されている必要があります。VM から始まる通信であれば下り（Egress）ルールで、外部から始まる通信であれば上り（Ingress）ルールで許可されている必要があります。VPC ファイアウォールルールでは、デフォルトでは下り（Egress）ルールで 0.0.0.0/0 に対する通信を許可、上り（Ingress）ルールでは 0.0.0.0/0 からの通信を拒否しているので、上り通信を許可するには明示的にルール追加する必要があります。

参考 : 暗黙のルール

Cloud NAT

Cloud NAT はフルマネージドな NAT 機器です。External IP を持っていない VM でも、インターネットへの通信（VM から開始しインターネットへ到達する方向の通信）が可能になります。

フルマネージドとは、このサービスの基盤が Google Cloud によって完全に管理されていることを意味しています。我々利用者は、一度 Cloud NAT を使用する設定を追加すれば「障害対応」「パッチ適用」「性能監視・スケーリング」などを行う必要がありません。Cloud NAT のバックエンドは仮想化・分散アーキテクチャになっており、スケーラビリティ・可用性・パフォーマンスが確保されています。

Cloud NAT を VPC ネットワークに追加すれば、 External IP を持たない VM でもインターネットへ通信することができます。逆にインターネットから開始して VM へ到達する方向の通信は許可されません。これにより例えば「パッチ配信サーバからのファイルダウンロード」「インターネット上のソースコードレポジトリからのソースコード取得」「SaaS サービスの HTTP API 呼び出し」などがセキュアに可能になります。

以下の条件を全て満たすと、VM は Cloud NAT を利用してインターネットへ出ていくことができます。

VM の所属するサブネットが Cloud NAT を利用するよう紐付けられている
VM に External IP（外部 IP）アドレスが割り振られていない
VPC のルートにて 0.0.0.0/0 のネクストホップがデフォルトインターネットゲートウェイになっている
ファイアウォールの下り（Egress）ルールで通信が許可されている

Cloud NAT はフルマネージドであるため多くの場合で簡単に利用できますが、様々な機能や仕様を持っています。詳細は以下の公式ドキュメントをご参照ください。

参考 : Cloud NAT の概要

インターネットとの通信を防ぐ方法

セキュリティ上の理由で VPC 内の VM とインターネットの接続をさせないようにするには、以下のような方法があります。

VPC のルートを編集してデフォルトインターネットゲートウェイへのルートを削除する
VM に External IP アドレスを持たせない
ファイアウォール（Cloud NGFW）で通信を制限する

1. のようにルートを削除してしまえば、 VPC 内の全ての VM はインターネットと通信できなくなります。影響範囲は VPC 全体となるので、もし同一 VPC 内にインターネットとの通信要件の異なる複数の VM がある場合は、この方法は取れません。AWS を例に取ると「パブリックサブネット」「プライベートサブネット」のように通信要件ごとにネットワークセグメントを分けるケースがありますが、 Google Cloud においてはこれは実現できません。実現する場合は VPC ごと分割することになります。

2. は読んで字のごとく、 VM に External IP アドレスを持たせないことで、ルート設定等に関係なく通信できなくさせてしまう方法です。ただし前述の Cloud NAT が設定されていると、External IP を持たない VM はインターネットへ出ていくことは可能となってしまいます。これを防ぐには 3. を実施します。

参考 : 外部 IP アドレスを使用しない方法

3. は VPC のファイアウォールでブロックする方法です。前述のように VPC を分割すると管理面で煩雑になる場合があるため、Google Cloud の場合は、ファイアウォールでインターネットとの通信可否を制御することが多いといえます。なお前述の通りファイアウォールの上り（Ingress）はデフォルトで拒否（Deny）のため、インターネットから VM への通信は明示的に許可しなければ到達しません。逆に下り通信はデフォルトで許可（Allow）のため、明示的に拒否ルールを追加しなければ、VM から外部方向への通信は可能なままです。

プレミアムティアとスタンダードティア

VPC ネットワーク内の VM とインターネット間の通信では、料金の異なるネットワークティアを、VM やロードバランサーごとに選択することができます。

プレミアムティアとスタンダードティアの2種類があり、前者は Google の持つ高品質な専用バックボーンネットワークを利用し、後者はコストパフォーマンスに優れた通常のインターネットを利用するティアです。デフォルトでは前者が利用されるようになっており、また Google の推奨は前者です。

前者は高品質・高パフォーマンスであり、特にグローバルに利用されるシステムでの利用が推奨されています。一方で後者は、単一の地域で利用されるシステムで、かつコスト最適化が望まれる場合に利用されます。

参考 : Network Service Tiers の概要

前述のとおり、料金は下り方向のパケットのデータ量に応じて課金されます。具体的な料金単価は、以下のページから確認できます。

参考 : Network Service Tiers の料金

Google Cloud サービスへのプライベートサービスアクセス

いくつかの Google Cloud サービスは、リソース配置に専用の VPC ネットワークとサブネットを使います。例えば以下のようなサービスです。

Cloud SQL
Memorystore
Cloud Build
Vertex AI

上記のサービスでは、リソースを作成するとサービスプロデューサーのネットワークと呼ばれる専用の VPC ネットワークに配置されます。例として AWS の Amazon RDS ではユーザーの VPC・サブネット内にインスタンスが配置されますが、Google Cloud の Cloud SQL では、ユーザーの VPC ではなく、Google が管理する専用 VPC ネットワークの中にインスタンスが配置されます。

ユーザーの VPC ネットワークとサービスプロデューサーのネットワークは VPC ネットワークピアリングで接続され、ユーザーの VM からはピアリング経由で、Cloud SQL インスタンス等に到達します。

このサービスプロデューサーのネットワークの IP レンジ（CIDR）は、ユーザー側で指定できます。その際には、ユーザーの VPC ネットワークと重複しない CIDR を指定する必要があります。

一度サービスプロデューサーのネットワークを作成すれば、その中に複数の Cloud SQL インスタンスや Memorystore インスタンスを配置することが可能です。

なお、この一連の仕組みはプライベートサービスアクセスと呼ばれます。

参考 : プライベートサービスアクセス

運用

VPC Flow Logs

VPC Flow Logs（VPC フローログ）とは、VM によって送受信されたトラフィック記録のサンプルをログとして保存する仕組みです。利用目的としては以下が挙げられます。

ネットワークモニタリング
トラブルシューティング
費用最適化
セキュリティ（フォレンジック、リアルタイム分析）

VPC Flow Logs では全てのトラフィックが記録対象となるわけではなく、事前に指定するサンプリングレート（%指定）に基づいた割合のトラフィックのログだけが記録されます。また「特定の VM のみ」「特定送信元 IP のトラフィックのみ」といったように記録する対象トラフィックをフィルタすることもできます。

なお VPC Flow Logs は、VPC の仮想化基盤に高度に組み込まれていることから、有効化してもパフォーマンス遅延等は発生しません。

参考 : VPC Flow Logs

VPC Flow Logs にはいわゆる 5 タプル（送信元 IP アドレス、送信元ポート番号、送信先 IP アドレス、送信先ポート番号、プロトコル番号) が含まれる他、時刻、バイト数、 TCP の ACK のレイテンシなどが含まれます。VPC Flow Logs ではこういったパケットの関連情報が記録されるのであり、パケットそのものがキャプチャされるのではありません。

オプションでメタデータの記録を有効化すると、ログのサイズは大きくなりますが、通信を行った VM や VPC ネットワークに関する追加情報も記録されるようになります。

参考 : VPC Flow Logs のレコードについて

VPC フローログの有効化有無や、サンプリングレート等の設定は、サブネットごとに設定できます。サブネット作成時に決定するほか、あとからでも変更可能です。

参考 : VPC Flow Logs を構成する

当機能で記録されたログは、デフォルトでは Cloud Logging のログバケットに保管されます。Cloud Logging の詳細や料金については以下をご参照ください。

blog.g-gen.co.jp

デフォルトのログバケットであれば、ログは30日間保存され、この範囲内であれば保存料金は無料です。ただし保存料金とは別に、取り込んだログのサイズに応じた料金が発生します。2025年3月現在では $0.50/GiB/月です。これは、Cloud Logging の Vended Network Logs ストレージ料金（$0.25/GiB/月）と、VPC のネットワークテレメトリー料金（$0.25/GiB/月）を併せた金額です。ネットワークテレメトリー料金は、取り込み量に応じて徐々に単価が安くなります。詳細は公式ドキュメントを参照してください。

参考 : Cloud Logging の料金概要
参考 : ネットワーキングのすべての料金体系

ファイアウォールルールのログ

ファイアウォールルールのログは、ファイアウォールのルールの監査、検証、分析のために用いるログです。以下のような目的で利用されます。

意図通りにファイアウォールルールが許可/拒否しているか確認
特定のルールが何台の VM に影響を与えているか調査
トラブル時に通信にファイアウォールが影響しているかの確認

特徴として、ファイアウォールルールのロギングはファイアウォールのルールごとに設定します。VPC ごと（ルールテーブルごと）ではありません。1行のルールごとに「ロギングの有効、無効」と「メタデータを含むか否か」を設定します。ログは、VPC Flow Logs と同様、Cloud Logging に出力されます。

なお当ロギング機能は VPC ファイアウォールとファイアウォールポリシーの両方で使用可能です。

参考 : ファイアウォールルールのロギング

ファイアウォールルールのログには、以下のような内容が記載されます。

日時
5タプル（送信元 IP アドレス、送信元ポート番号、送信先 IP アドレス、送信先ポート番号、プロトコル番号）
許可されたか拒否されたか
該当するファイアウォールルールの詳細

また、メタデータの記録も有効化すると、VPC ネットワークや VM の詳細など追加情報が記録されます。

参考 : ファイアウォールログ形式

VPC ネットワークの監査ログ

ネットワーク関連設定が作成、変更、削除された履歴は、監査ログとして自動的に記録されるようになっています。記録を無効化することはできません。

これは Cloud Audit Logs の機能で実現されており、「誰が、いつ、どこで、何をしたか」が記録されます。Cloud Audit Logs については、以下の記事をご参照ください。

blog.g-gen.co.jp

設定の作成、変更、削除など、更新系 API リクエストに関するログは、管理アクティビティ監査ログと呼ばれます。前述の Cloud Audit Logs の記事にあるように、デフォルトではログは400日間保存されます。デフォルトで有効化されている管理アクティビティ監査ログについては、料金は発生しません。

一方で、設定の読み取りや一覧表示など、読取系 API リクエストに関する履歴は、データアクセス監査ログ と呼ばれ、ログサイズが膨大になりがちなことからデフォルトでは無効化されています。前述の記事にある通りデータアクセス監査ログは有償のため、有効化の際は料金を意識する必要があります。

参考 : Virtual Private Cloud（VPC）の監査ロギング

料金

概要

VPC の利用料金は、以下の要素で構成されます。

下り（Egress）トラフィックのデータ量
確保した External IP（外部 IP）アドレスの利用時間

なお、VPC を作成するのみであれば無償です。

参考 : ネットワーキングのすべての料金体系

トラフィック量への課金

1. は、VPC ネットワーク内を通るトラフィックの量に応じた課金です。特徴的なのは、パケットの通信方向によって課金の有無が異なります。VPC ネットワークを上側 / Internal 側とみなし、インターネットやオンプレミス側を下側 / External 側としたときに、上り（Ingress）パケットは課金されません。反対に、下り（Egress）パケットは課金されます。

例えば VPC ネットワーク内の VM に Web サーバーを配置した時、ユーザーからの HTTP リクエストや、データのアップロードには課金されません。反対にユーザーがデータをダウンロードした際には、データ量に応じて課金されます。これは他の多くのパブリッククラウドのネットワーク課金体系と類似しています。

例として、2025年3月現在、東京リージョンから日本国内へのインターネットへの通信は、GiB あたり$0.12ドルです（プレミアムティアの場合）。月に100GiBの外向き通信が発生するとして、概ね￥1,800円程度の課金が発生することになります（1ドル150円換算）。なおこの料金は通信先の地域や、月間の総データ量によっても変化します。

また、インターネットに対する通信だけではなく、VPC 内の VM 同士の通信であっても、異なるゾーンや異なるリージョン同士の通信には課金が発生します。こちらも、同一リージョン内の異ゾーンとの通信なのか、リージョン間であればどのリージョンへの通信なのか、によって料金が変動します。

参考 : Google Cloud 内の VM 間データ転送の料金

IP アドレスへの課金

2. は、VM（Compute Engine の仮想マシン）に付与するための IP アドレスに対する課金です。Internal IP アドレス（内部 IP アドレス）には課金されませんが、インターネットとの通信に必要な External IP アドレス（外部 IP アドレス）には割り当て時間に応じた課金が発生します。External IP アドレスには、VM を停止すると解放されてしまう一時的なエフェメラル IP アドレスと、固定的に確保できる静的 IP アドレスがありますが、どちらも同様に課金されます。