AWS VPCとは？仕組み・構成要素・料金をわかりやすく解説

AWS VPC(Amazon Virtual Private Cloud)とは、AWS上に自社専用の仮想ネットワーク空間を構築できるサービスです。本記事では、VPCの基本構造から構成要素、セキュリティの考え方、料金体系までを体系的に解説します。AWSでシステムを構築する際にまず理解しておくべき土台となる知識を、初めてクラウドインフラに触れる方にも分かりやすくまとめています。

AWS VPCとは何か

AWS VPCとは、AWSアカウント内に作成できる、論理的に隔離された仮想ネットワーク環境のことです。オンプレミスのデータセンターで構築していたネットワークと同じような環境を、AWSのクラウド基盤上で柔軟かつ短時間で用意できる点が特徴です。

AWS公式の説明によれば、Amazon VPCを使うことで、論理的に隔離された仮想ネットワーク内にAWSリソースを起動できます。この仮想ネットワークは従来型のネットワークとよく似ていますが、AWSのスケーラブルなインフラを利用できる点が大きなメリットです。EC2(仮想サーバー)やRDS(マネージド型データベース)など、多くのAWSサービスはこのVPCの中で稼働するため、AWSを使ったシステム設計はVPCの理解から始まると言っても過言ではありません。

VPCという名称の意味

VPCはVirtual Private Cloudの略称で、直訳すると仮想プライベートクラウドです。クラウド上に自分専用の隔離された区画を持てるイメージを表しています。

具体的には、利用者ごとにIPアドレスの範囲(CIDR)を指定してネットワークを定義し、その中にサーバーやデータベースなどのリソースを配置していきます。同じVPC内のリソース同士は内部通信が可能で、外部のVPCとは初期状態では分離されているため、セキュリティ境界を意識した設計がしやすくなっています。

オンプレミスのネットワークとの違い

VPCは、物理的な機器を用意することなく、数分でネットワーク基盤を構築できる点がオンプレミス環境との大きな違いです。

従来のオンプレミス環境では、ルーターやファイアウォールなどの物理機器の調達、配線、設定作業に時間とコストがかかっていました。一方でVPCでは、ルーティング機能やDNS、NTPといった基本機能がAWS側で提供されるため、管理コンソール上の設定だけでネットワーク環境を立ち上げられます。機器の老朽化対応や障害対応といった保守作業もAWS側が担うため、運用負荷を抑えやすいことも特徴です。

VPCを構成する主要なコンポーネント

VPCは、サブネット・ルートテーブル・ゲートウェイ・セキュリティグループといった複数のコンポーネントの組み合わせで構成されています。それぞれの役割を理解することで、要件に応じたネットワーク設計が可能になります。

以下の表に、VPCを構成する代表的な要素とその役割をまとめます。

サブネットとアベイラビリティーゾーン

サブネットとは、VPCに割り当てたIPアドレスの範囲をさらに細かく分割したネットワーク区画のことです。サブネットは必ず1つのアベイラビリティーゾーン(AZ)の中に作成します。

1つのVPCの中に複数のサブネットを作成し、それぞれに異なる用途やセキュリティ要件を持たせることで、Webサーバー用・アプリケーションサーバー用・データベース用といった役割分担を行うのが一般的な設計パターンです。複数のAZにサブネットを分散配置することで、特定のAZで障害が発生した場合でもシステム全体への影響を抑える、可用性の高い構成を実現できます。

ルートテーブルによる通信経路の制御

ルートテーブルとは、サブネットやゲートウェイから送信されるトラフィックの行き先を定義する経路情報のことです。サブネットごとに適切なルートテーブルを関連付けることで、通信経路を細かく制御できます。

VPCを作成すると、デフォルトのルートテーブルが自動的に生成されます。あるサブネットのルートテーブルにインターネットゲートウェイへの経路が設定されていれば、そのサブネットは外部と通信できるパブリックサブネットとして機能します。逆にインターネットゲートウェイへの経路を持たないサブネットは、外部から直接アクセスできないプライベートサブネットになります。

パブリックサブネットとプライベートサブネットの使い分け

パブリックサブネットはインターネットからアクセス可能な区画、プライベートサブネットはインターネットから隔離された区画です。重要なデータを扱うリソースほど、プライベートサブネットに配置するのが基本的なセキュリティ設計の考え方です。

例えば、外部公開が必要なWebサーバーはパブリックサブネットに、顧客情報などを保持するデータベースサーバーはプライベートサブネットに配置するという構成がよく採用されます。これにより、インターネットからの不正アクセスのリスクを最小限に抑えながら、必要なリソースだけを外部に公開できます。

STEP1:要件に応じたサブネット構成を決める

まず、どのリソースを外部公開し、どのリソースを内部に留めるかを整理することから設計を始めます。

一般的なWebアプリケーションであれば、ロードバランサーやWebサーバーをパブリックサブネットに、アプリケーションサーバーやデータベースをプライベートサブネットに配置する3層構成が基本形となります。要件によっては、パブリックサブネットを設けずすべてプライベートサブネットで完結させる構成も選択可能です。

STEP2:CIDRブロックを設計する

サブネットを作成する前に、VPC全体で使用するIPアドレスの範囲(CIDR)を決定する必要があります。CIDRはClassless Inter-Domain Routingの略で、利用可能なIPアドレス数を表す表記方法です。

CIDR設計では、将来的なリソースの増加を見越して余裕を持った範囲を確保すること、他VPCやオンプレミス環境と接続する予定がある場合はアドレス範囲が重複しないようにすることがポイントです。プライベートIPアドレスの範囲(RFC1918で規定された範囲)を使用するのがAWSの推奨方法です。

STEP3:ゲートウェイとルートテーブルを設定する

サブネット構成が決まったら、必要なゲートウェイを作成し、各サブネットのルートテーブルに適切な経路を設定します。

パブリックサブネットにはインターネットゲートウェイへの経路を、プライベートサブネットから外部への限定的な通信が必要な場合はNATゲートウェイへの経路を設定します。この段階で経路設定を誤ると、想定した通信ができない、あるいは意図せず外部公開されてしまうといった事故につながるため、設計内容を一つひとつ確認しながら進めることが重要です。

VPCとインターネット・外部ネットワークとの接続方法

VPCを外部ネットワークと接続する方法は、用途に応じてインターネットゲートウェイ・NATゲートウェイ・VPN・Transit Gatewayなど複数用意されています。目的に合った接続方式を選ぶことで、セキュリティと利便性を両立できます。

インターネットゲートウェイ

インターネットゲートウェイ(IGW)とは、VPC内部と外部インターネットを双方向に接続するための機能です。AWS上のアプリケーションを一般公開する場合に利用します。

1つのVPCに対してアタッチできるインターネットゲートウェイは1つのみです。パブリックサブネットのルートテーブルにインターネットゲートウェイへの経路を設定することで、そのサブネット内のリソースが外部と通信できるようになります。

NATゲートウェイ

NATゲートウェイとは、プライベートサブネット内のリソースから外部への一方向の通信を可能にするネットワークアドレス変換サービスです。外部からプライベートサブネットへ接続を開始することはできません。

例えば、プライベートサブネットに配置したデータベースサーバーのソフトウェア更新など、定期的に外部との通信が必要なケースで利用されます。NATゲートウェイにはパブリックなトラフィックを扱うパブリックNATゲートウェイと、他VPCやオンプレミスとの通信に使うプライベートNATゲートウェイの2種類があります。

VPCエンドポイントとVPNによる接続

VPCエンドポイントとは、インターネットゲートウェイやNATデバイスを経由せずに、AWSサービスへプライベートに接続できる仕組みです。VPNやTransit Gatewayは、オンプレミス環境や他VPCとの恒常的な接続に利用します。

S3やDynamoDBといったAWSのマネージドサービスへのアクセスが多い場合、VPCエンドポイントを利用することでNATゲートウェイを経由させずに通信でき、セキュリティ強化とコスト削減の両方に寄与します。また、AWS Site-to-Site VPNを使えば、自社のデータセンターとVPCをセキュアに接続し、クラウドをオンプレミスの延長として活用することも可能です。複数のVPCやVPN接続を集約したい場合は、中央ハブとして機能するTransit Gatewayの利用が選択肢になります。

VPCのセキュリティ機能

VPCには、セキュリティグループとネットワークACLという2種類のアクセス制御機能が用意されています。両者を組み合わせることで、多層的な防御を実現できます。

セキュリティグループの特徴

セキュリティグループは、EC2やRDSなど個々のリソースに対するインバウンド・アウトバウンド通信を制御する、ステートフルなファイアウォール機能です。

ステートフルとは、インバウンド通信を許可すると、それに対応するアウトバウンド通信が自動的に許可される性質を指します。新規に作成したセキュリティグループにはインバウンドルールが設定されていないため、必要な通信を個別に許可する設定が必要です。1つのインスタンスには複数のセキュリティグループを割り当てられ、用途ごとに異なるルールセットを適用することもできます。

ネットワークACLの特徴

ネットワークACLは、サブネット単位で通信を制御するステートレスなファイアウォール機能です。許可だけでなく明示的な拒否ルールも設定できる点がセキュリティグループとの違いです。

ステートレスであるため、インバウンドとアウトバウンドそれぞれについて個別にルールを設定する必要があります。セキュリティグループがリソース単位の細かい制御に向くのに対し、ネットワークACLはサブネット単位で大枠の通信を制御したい場合に適しています。両方を組み合わせることで、より堅牢なネットワークセキュリティを構築できます。

AWS VPCの料金体系

VPC自体の作成や基本的な利用に料金は発生しませんが、NATゲートウェイなどのオプション機能を利用すると課金対象になります。コストを抑えるには、不要な経由を避ける設計の工夫が重要です。

AWS公式の料金ページによると、NATゲートウェイを利用する場合、ゲートウェイが稼働している時間に対する料金と、処理したデータ量(GB単位)に対する料金がかかります。東京リージョンの料金例では、NATゲートウェイの処理データに対して1GBあたり0.062USD、稼働時間に対して1時間あたり0.062USDが発生するケースが紹介されています。

主な課金対象

これらはいずれもオプション機能の利用に伴う課金であり、シンプルなVPCとサブネットだけの構成であれば、基本的に追加費用はかかりません。

コストを抑えるポイント

NATゲートウェイの利用を必要最小限に絞り、S3やDynamoDBなどへのアクセスにはVPCエンドポイントを活用することで、データ処理料金を抑えられます。

AWSの公式ナレッジセンターでも、同一リージョン内のS3やDynamoDBへの通信がNATゲートウェイ料金の大部分を占めている場合は、ゲートウェイ型のVPCエンドポイントを設定することで、データ処理料金や時間単位の料金を発生させずに通信できると案内されています。NATゲートウェイを経由する通信のうち、AWSサービス宛のものをVPCエンドポイント経由に切り替えるだけで、コスト構造が大きく改善するケースは少なくありません。定期的にAWS Cost ExplorerやCost and Usage Reportを確認し、無駄な経路がないかをチェックする運用も有効です。

VPC設計でつまずきやすいポイント

VPC設計では、CIDR範囲の重複やサブネット分割の粒度、セキュリティグループの設定ミスなどが典型的なつまずきポイントです。設計段階で将来の拡張性を考慮しておくことがトラブル回避につながります。

CIDR範囲の重複

オンプレミス環境や他のVPCと接続する計画がある場合、CIDR範囲が重複していると、該当するネットワークとは通信できなくなります。事前に全体のIPアドレス設計図を作成し、重複が生じないように調整することが欠かせません。

サブネット分割が細かすぎる、または粗すぎる

必要以上に細かくサブネットを分割すると管理が煩雑になり、逆に粗すぎるとセキュリティ境界が曖昧になります。用途別・AZ別にバランスの取れた分割を行うことが望まれます。

セキュリティグループの許可範囲が広すぎる

動作確認のために一時的に開けた通信ポートを閉じ忘れるなど、セキュリティグループの設定が必要以上に緩いまま放置されるケースもよくある失敗例です。定期的なルールの棚卸しを運用フローに組み込むことが推奨されます。

本記事の振り返りと次のアクション

AWS VPCとは、AWS上に専用の仮想ネットワークを構築できるサービスであり、サブネット・ルートテーブル・各種ゲートウェイ・セキュリティグループといった要素を組み合わせることで、要件に応じたネットワーク環境を実現します。パブリックサブネットとプライベートサブネットを使い分けてセキュリティを担保しつつ、NATゲートウェイやVPCエンドポイントを適切に選択することでコストの最適化も図れます。

まずは自社システムの要件を整理し、どのリソースを外部公開し、どのリソースを内部に留めるべきかを明確にするところから始めてみてください。CIDR設計やサブネット構成は後からの変更が難しい部分も多いため、将来的な拡張も見据えた設計を初期段階で検討しておくことが、安定したクラウド基盤の運用につながります。