AWS EC2とVPC徹底攻略！設計から接続、応用まで完全ガイド

EC2とVPCの基礎から応用まで：セキュアなインフラ構築の全体像

クラウド時代におけるEC2とVPCの重要性

日本の企業におけるクラウドサービスの利用率は、令和5年版の情報通信白書によると72.2%に達しており、クラウドサービスはもはや業務遂行に不可欠な基盤です。この流れの中で、パブリッククラウド市場で高いシェアを誇るAWSは、多くの企業にとってIaaS/PaaSの選択肢の筆頭となっています。AWSの中でも、仮想サーバーを提供するAmazon EC2と、隔離された仮想ネットワークを構築するAmazon VPCは、セキュアで柔軟なクラウドインフラの実現に不可欠な要素です。これらを適切に設計・構築することで、企業のビジネス要件に応じた堅牢なシステム基盤をクラウド上に構築することが可能になります。しかし、その一方で、クラウド利用の拡大に伴い、脆弱性対策やアクセス制御といったセキュリティ設計の重要性が一層高まっています。EC2とVPCを深く理解し、適切な設定を行うことが、安全なクラウド利用の第一歩となるでしょう。

Amazon EC2とは？仮想サーバーの基本と選択肢

Amazon EC2 (Elastic Compute Cloud) は、AWSクラウド上で仮想サーバー（インスタンス）を構築できるサービスです。オンプレミスの物理サーバーを用意することなく、数分でLinuxやWindowsのサーバーを起動し、すぐに利用を開始できます。EC2の大きな特徴は、計算能力、メモリ、ストレージといったリソースを、用途に合わせて柔軟に選択できる点です。Webサーバー、データベースサーバー、バッチ処理用サーバーなど、ワークロードに応じて多様なインスタンスタイプが提供されており、必要に応じて瞬時にスペックを拡張・縮小することが可能です。これにより、リソースの無駄をなくし、コスト最適化にも貢献します。また、料金体系も従量課金制のため、利用した分だけ費用が発生し、初期投資を抑えながら利用を開始できるメリットがあります。

Amazon VPCとは？セキュアな仮想ネットワークの構築

Amazon VPC (Virtual Private Cloud) は、AWS環境内に隔離された自分専用の仮想ネットワークを構築するサービスです。このVPCを基盤として、EC2インスタンスやRDSなどのAWSリソースを配置します。VPCの最大の利点は、IPアドレス範囲（CIDRブロック）を自由に指定し、サブネットに分割することで、オンプレミス環境に近い厳密なネットワーク制御が可能になる点です。例えば、インターネットに公開するWebサーバー用サブネットと、内部向けデータベースサーバー用サブネットを分けることで、セキュリティを強化できます。また、ルートテーブルによる通信経路の制御や、インターネットゲートウェイ、NAT Gatewayなどの利用により、外部とのセキュアな通信経路も構築できます。VPCは、クラウド上でのシステム設計において、セキュリティとネットワークの柔軟性を確保するための最も重要な要素の一つです。

出典：総務省、Amazon Elastic Compute Cloud (AWS Documentation)、Amazon Virtual Private Cloud (AWS Documentation)

EC2とVPCの具体的な構築・設定ステップ：基本から応用接続まで

EC2インスタンスの作成と基本的な接続手順

EC2インスタンスを作成する最初のステップは、AWSマネジメントコンソールにサインインし、「EC2」サービスへ移動することです。次に「インスタンスを起動」を選択し、以下の項目を設定していきます。

• AMI (Amazon Machine Image) の選択: OSや初期設定済みソフトウェアを含むテンプレートを選択します。
• インスタンスタイプ: CPU、メモリ、ネットワーク性能など、用途に合ったスペックを選びます。
• キーペアの作成: SSH接続に必要な秘密鍵と公開鍵のペアを作成し、秘密鍵をダウンロードします。これは認証に不可欠です。
• ネットワーク設定: 既存のVPCやサブネットを選択し、セキュリティグループを作成または選択します。セキュリティグループは仮想ファイアウォールとして機能し、インスタンスへのインバウンド・アウトバウンドトラフィックを制御します。WebサーバーであればHTTP/HTTPSポートを開放します。

これらの設定後、インスタンスを起動し、ダウンロードした秘密鍵を使ってSSHクライアント（Linux/macOS）やTera Term/PuTTY（Windows）で接続確認を行います。Windowsインスタンスの場合はRDP接続を利用します。

VPCネットワークの設計とサブネット・ルートテーブル設定

VPCの構築は、まずAWSマネジメントコンソールで「VPC」サービスに移動し、「VPCを作成」から開始します。まず、VPC全体のプライベートIPアドレス範囲をCIDRブロックで指定します（例: 10.0.0.0/16）。次に、このVPC内でリソースを配置するためのサブネットを作成します。通常、インターネットに直接公開するリソースを置く「パブリックサブネット」と、内部リソースを置く「プライベートサブネット」に分割します。パブリックサブネットにはインターネットゲートウェイをアタッチし、ルートテーブルに「0.0.0.0/0 をインターネットゲートウェイへルーティングする」という設定を追加することで、インターネットへのアクセスを可能にします。プライベートサブネットはインターネットゲートウェイへ直接ルーティングせず、必要に応じてNAT Gateway経由でインターネットにアクセスさせます。この設計により、内部リソースのセキュリティを強化できます。

セキュリティグループとネットワークACLによるアクセス制御の実践

AWSでのセキュリティ設計において、セキュリティグループとネットワークACL（NACL）は非常に重要な役割を果たします。これらは仮想ファイアウォールとして機能しますが、それぞれ異なるレベルで動作します。

• セキュリティグループ: EC2インスタンスレベルで動作し、インスタンスへのインバウンド/アウトバウンドトラフィックを許可ベースで制御します。ステートフルであり、一度許可された通信の戻りも自動的に許可されます。推奨されるアクセス制御の第一歩です。
• ネットワークACL: サブネットレベルで動作し、サブネットへのインバウンド/アウトバウンドトラフィックをルール番号順に評価し、許可・拒否を制御します。ステートレスであり、インバウンドを許可したらアウトバウンドも個別に許可する必要があります。より厳格なネットワーク層での制御が必要な場合に利用します。

基本的にはセキュリティグループでアクセスを制御し、必要に応じてNACLで二重の防御を構築することが推奨されます。特にWebサーバーやデータベースサーバーなど、重要なサービスへのアクセスは最小限に絞り、定期的な設定見直しを行いましょう。

出典：Amazon Elastic Compute Cloud (AWS Documentation)、Amazon Virtual Private Cloud (AWS Documentation)

セキュリティと可用性を高める！EC2とVPCの応用活用事例

ロードバランシングとオートスケーリングで高可用性を実現

ウェブアプリケーションなどのサービスにおいて、急なアクセス増大やインスタンス障害に備えることは、高い可用性を維持するために不可欠です。Amazon EC2では、Elastic Load Balancing（ELB）とAuto Scalingを組み合わせることで、これらの課題を解決できます。ELBは、複数のEC2インスタンスにトラフィックを自動的に分散させ、単一障害点（SPOF）を排除します。これにより、特定のインスタンスに負荷が集中することを防ぎ、アプリケーションの応答性を維持します。一方、Auto Scalingは、定義されたルール（CPU使用率など）に基づいてEC2インスタンスの数を自動的に増減させます。これにより、トラフィックの変動に合わせてリソースを最適化し、コストを抑えつつ、常に適切なパフォーマンスを維持することが可能です。障害が発生したインスタンスを自動的に置き換える機能もあり、サービスの停止時間を最小限に抑えられます。

VPN/Direct Connectによるオンプレミス連携

企業がクラウド移行を進める際、既存のオンプレミス環境とAWS VPC環境をセキュアに接続するニーズが頻繁に発生します。AWSでは、このハイブリッドクラウド環境を実現するための複数のソリューションを提供しています。AWS VPNは、インターネット経由でオンプレミスネットワークとVPCを暗号化されたトンネルで接続する方法です。手軽に導入でき、比較的低コストでセキュアな通信経路を確立できます。より高速で安定した専用線接続が必要な場合は、AWS Direct Connectが選択肢となります。Direct Connectは、AWSネットワークへの専用物理回線を提供し、低レイテンシーで高帯域幅のプライベート接続を可能にします。これにより、オンプレミスのデータベースとVPC上のアプリケーション間の連携や、大規模なデータ転送などを安定して行うことができます。どちらの接続方法も、VPCのルートテーブルを適切に設定することで、オンプレミスとクラウド間でシームレスなルーティングを実現します。

プライベートサブネットでのデータベース配置とセキュリティ強化

機密性の高いデータを扱うデータベースは、インターネットから直接アクセスできないようにすることがセキュリティ上の鉄則です。Amazon VPCでは、これを「プライベートサブネット」にデータベースを配置することで実現します。プライベートサブネット内のリソースは、インターネットゲートウェイを経由せずに直接インターネットと通信することはできません。代わりに、インターネットへのアウトバウンド通信が必要な場合は、NAT GatewayやNATインスタンスを経由させます。これにより、データベースはインターネットからの不正アクセスから保護されつつ、必要な場合はAWSのアップデートや外部サービスへのアクセスが可能です。さらに、VPC PeeringやAWS Transit Gatewayを利用して、異なるVPC間のプライベート接続を確立し、セキュアなマイクロサービス連携を実現するといった応用も可能です。この設計は、情報漏えいや不正アクセスのリスクを大幅に低減し、堅牢なシステム基盤を構築するために不可欠です。

出典：Amazon Virtual Private Cloud (AWS Documentation)、Amazon Elastic Compute Cloud (AWS Documentation)

トラブルを未然に防ぐ：EC2・VPC運用における注意点とベストプラクティス

セキュリティグループ・NACL設定ミスによるアクセス障害対策

クラウド環境は利便性が高い一方で、セキュリティ設定のミスは情報漏えいやサービス停止に直結するリスクがあります。特にセキュリティグループやネットワークACL（NACL）の設定は、EC2インスタンスへのアクセスを制御する要であり、その不適切な設定は、意図しないポート開放による不正アクセスや、必要な通信が遮断されることによるサービス障害を引き起こす可能性があります。IPAが発表した「情報セキュリティ10大脅威 2026」で「ランサム攻撃による被害」が第1位になるなど、サイバー攻撃のリスクは高まる一方です。これを防ぐためには、最小権限の原則に基づき、必要なポートとIPアドレスのみを許可する設定を徹底することが重要です。また、設定変更時には必ず影響範囲を事前に確認し、定期的に設定内容のレビューを行う仕組みを導入しましょう。AWS ConfigやCloudTrailを活用して、設定変更履歴を追跡することも有効です。

コスト最適化のためのリソース監視と管理戦略

クラウドは初期コストを抑えられるメリットがある反面、意図しないリソースの起動や不適切なサイジングは、予想外のコスト増大を招く可能性があります。コスト最適化のためには、まずリソースの可視化と監視が不可欠です。AWS Cost ExplorerやAWS Budgetsを活用して、コストの現状を把握し、予算超過のアラートを設定しましょう。次に、不要なEC2インスタンスやEBSボリューム、スナップショットなどを定期的に棚卸しし、削除または停止することが重要です。稼働が終了したプロジェクトのリソースが残り続けているケースは少なくありません。さらに、ワークロードの特性に合わせて、適切なインスタンスタイプを選択することもコスト削減につながります。例えば、一時的な負荷に対応するスポットインスタンスや、長期的な利用が見込まれる場合はリザーブドインスタンスやSavings Plansを検討することで、大幅なコスト削減が期待できます。EC2のAuto Scaling Groupを導入し、アクセス負荷に応じて自動でリソースを調整することも有効です。

最新情報のキャッチアップと継続的なシステム改善

AWSをはじめとするクラウドサービスは、機能追加や仕様変更の頻度が高く、常に進化を続けています。このため、一度構築したシステムをそのままにしておくと、古い技術や非効率な構成になってしまい、セキュリティリスクやコスト増大、パフォーマンス低下につながる可能性があります。常にAWS公式サイトや公式ブログ、発表されるドキュメントに目を通し、最新情報を継続的にキャッチアップすることが極めて重要です。新しいサービスや機能がリリースされた際には、それが自社のシステムに適用できないか、より効率的・セキュアな方法はないかを積極的に検討しましょう。定期的なシステム構成の見直し（モダナイゼーション）を計画に組み込み、セキュリティパッチの適用や、OS・ミドルウェアのバージョンアップを怠らない運用体制を構築することも重要です。これにより、システムの安定性と競争力を維持し、変化の速いビジネス環境に対応できるレジリエントなインフラを保つことができます。

出典：IPA 独立行政法人 情報処理推進機構、Amazon Virtual Private Cloud (AWS Documentation)

【ケース】VPCネットワーク設計ミスによる接続障害と改善策

(架空のケース) VPCピアリング設定ミスによるサービス停止

ある中規模企業A社では、開発環境VPC（VPC-Dev）と本番環境VPC（VPC-Prod）を分離し、互いにVPCピアリングで接続して一部サービスを連携するアーキテクチャを採用していました。しかし、ある日突然、開発環境から本番環境のデータベースへの接続ができなくなり、開発作業が停止するという事態が発生しました。インシデント発生前には、VPC-Prodのネットワーク設計変更が行われており、その際に新しいサブネットが追加されていました。担当者はVPCピアリングの設定を変更したつもりでしたが、実際にデータベースが配置されているプライベートサブネットへのルーティングが正しく行われていない状態だったのです。結果として、開発環境からのデータベース接続リクエストは、本番環境のVPC内に到達するものの、正しいルーティング経路を見つけられずタイムアウトしていました。サービス停止時間は約2時間に及び、開発チームの生産性に大きな影響が出ました。

問題解決のための原因特定と具体的な改善ステップ

この接続障害の解決に向けて、A社は以下の手順で原因を特定し、改善策を実施しました。

1. VPCフローログの確認: 開発環境から本番環境データベースへの通信が、どの段階でブロックされているかをVPCフローログで確認しました。その結果、VPC-Prod内のデータベースがあるサブネットに到達していないことが判明しました。
2. VPCピアリング接続状態の確認: VPCピアリング接続自体は「Active」状態であり、接続自体に問題はないことを確認。
3. ルートテーブルの確認: VPC-Dev側のルートテーブルで、VPC-Prodへの通信が正しくVPCピアリング接続を指しているかを確認。問題なし。次に、VPC-Prod側のルートテーブルで、VPC-Devからの通信をデータベースがあるサブネットにルーティングするエントリが不足していることを発見。特に、新しいサブネットの追加に伴い、古いルート情報が残っていたり、新しいサブネットへの経路が未定義であったりするケースはよくあります。
4. セキュリティグループの確認: データベースインスタンスにアタッチされているセキュリティグループが、VPC-Devからの通信（IPアドレス範囲）を許可しているかを確認。これも問題なし。

原因はVPC-Prod側のルートテーブルに、VPC-Devからのアクセスをデータベースのプライベートサブネットへ誘導するルーティングエントリが不足していたことでした。このエントリを追加したところ、開発環境からのデータベース接続が無事に復旧しました。

今後のネットワーク設計における教訓と再発防止策

この事例から得られた教訓は、クラウド環境のネットワーク設計では「変更管理」と「影響範囲の確認」が極めて重要であるということです。A社では再発防止策として、以下の取り組みを実施しました。

• 設計レビューの徹底: ネットワーク構成を変更する際は、必ず複数名で設計書をレビューし、影響範囲を事前に検討するプロセスを導入しました。
• ドキュメント化の徹底: VPC、サブネット、ルートテーブル、セキュリティグループなど、全てのネットワークリソースの設定内容と目的を詳細にドキュメント化し、常に最新の状態に保つようにしました。
• テスト環境での事前検証: 本番環境に変更を適用する前に、同等の構成を持つステージング環境やテスト環境で十分に動作検証を行うことを義務付けました。
• IAMロールによる権限管理: ネットワーク設定変更権限を持つエンジニアを限定し、最小限の権限原則を徹底することで、意図しない変更のリスクを低減しました。
• モニタリングとアラートの強化: CloudWatchを利用して、VPCフローログの異常値や接続エラー数を監視し、早期に問題を発見できるアラートを設定しました。

これらの対策により、A社はネットワーク構成変更に伴うリスクを低減し、より安定したサービス運用を実現しています。