EC2のインスタンスタイプや料金モデルを理解した後、本当の課題は本番環境でEC2をいかに安定かつ安全に運用するかにあります。
本セクションでは、実際のシステムにおけるEC2運用に焦点を当て、セキュリティ強化、ネットワーク設計、ストレージ管理、そして長期的なコスト最適化について解説します。単にEC2を「動かす」だけでなく、安全・効率的かつスケーラブルに運用することを目的としています。

本番環境におけるEC2のセキュリティ

EC2が開発環境から本番環境へ移行すると、セキュリティは「任意」ではなくなります。この段階では、ミスは単なる設定不備では済みません。データ漏洩、サービス停止、コンプライアンス違反といった現実的なリスクへと直結します。

実務上、EC2におけるセキュリティ問題の多くは高度な攻撃によるものではありません。過度に開放されたネットワークアクセス、放置されたルール、開発初期に取られた安易な設定が原因です。本セクションでは、実際の本番環境で行われている方法に基づき、最も基本的かつ重要な制御であるセキュリティグループから解説します。

セキュリティグループの本質

セキュリティグループは一般的に「仮想ファイアウォール」と説明されますが、それだけでは不十分です。本番環境においては、セキュリティグループは「契約（コントラクト）」として理解すべきです。つまり、どの主体が、どのポートで、どの目的でインスタンスと通信できるのかを厳密に定義するものです。

セキュリティグループはインスタンス単位で適用され、ステートフルに動作します。インバウンド通信が許可されると、その応答トラフィックは自動的に許可されます。アウトバウンドルールを別途設定する必要はありません。

見落とされがちな重要なポイントは以下の2点です：

• 拒否ルールは存在しない：明示的に許可されていない通信はすべて拒否される
• 変更は即時反映される：インスタンスの再起動は不要

この特性により、セキュリティグループはEC2における最初かつ最も重要なセキュリティ境界となります。

各ルールは以下の要素で構成されます：

• プロトコル（TCP / UDP / ICMP）
• ポート範囲
• 送信元／送信先（CIDR またはセキュリティグループ参照）

一般的なセキュリティグループパターン

セキュリティグループは意図的にシンプルに設計されています。

複雑なファイアウォールロジックを再現することを目的としていません。基本原則は一つです：必要な通信のみを明示的に許可し、それ以外はすべてデフォルトで拒否すること。この設計により、実務上重要な挙動が生まれます。

セキュリティグループのルールは「許可」のみを定義します。拒否ルールという概念は存在しません。いずれのルールにも一致しない通信は自動的に拒否されます。これにより、挙動が予測しやすくなり、例外的な設定によるリスクが低減されます。セキュリティグループ作成時、AWSはデフォルトで以下の設定を付与します：

アウトバウンド：すべて許可（0.0.0.0/0、全プロトコル、全ポート）

インバウンド：すべて拒否（ルールなし）

この挙動は、アプリケーションの外向き通信を阻害しないための設計です。一方で、インバウンドは完全に閉じた状態から始まります。そのため、本番環境ではSecurity Groupは通常、個々のインスタンスではなく「アプリケーションの役割（ロール）」単位で設計されます。

例えば、Web公開サーバーの場合：

Webサーバー用セキュリティグループ

• HTTP（80）：インターネットから許可
• HTTPS（443）：インターネットから許可
• SSH（22）：内部IPレンジからのみ許可

このような構成により、ユーザーに必要な通信のみを公開しつつ、運用アクセスは適切に制御することができます。データベースに関しては、さらに厳格な設計が求められます。データベースインスタンスは、インターネットからの直接アクセスを許可すべきではありません。代わりに、アプリケーションサーバーからの接続のみを許可する構成とするのが基本です。

データベース用セキュリティグループ

- DBポート（例：3306）：アプリケーションのSecurity Groupからのみ許可

この構成によりレイヤー間の分離が明確になり、公開コンポーネントが侵害された場合でも攻撃範囲を大幅に限定できます。

高度なセキュリティグループベストプラクティス

動的な環境では、IPアドレスを直接ルールに記述すると管理が困難になります。

そのため、Security Groupは他のSecurity Groupを通信元または通信先として参照することが可能です。

1. IPアドレスではなくSecurity Group参照を使用する

可能な限りIPレンジのハードコードは避けるべきです。本番環境では、スケーリング、障害対応、デプロイによりインスタンスは頻繁に置き換えられます。IPベースのルールはこうした状況で静かに破綻します。

Security Group参照を使用することで、以下の利点が得られます：

• アクセス制御がインスタンスではなくサービス単位で管理される
• Auto Scalingに対応しやすい
• マルチAZ構成でも一貫性が維持される

2. 最小権限の原則を厳格に適用する

最小権限の原則は、ネットワークレベルにおいても厳格に適用されるべきです。アーキテクチャ上明確な要件がある場合を除き、サブネット全体やVPCのCIDRブロック単位でのトラフィック許可は避ける必要があります。各インバウンドルールは、単一のサービス、単一のプロトコル、そして明確な運用目的に対応しているべきです。広範囲な許可や便宜的な設定は、障害発生時の影響範囲（blast radius）を拡大させ、インシデント対応を困難にします。

3. 説明的な命名規則を使用する

Security Groupの名称は環境ではなく、その用途や役割を明確に表すべきです。たとえば、alb-sg、app-tier-sg、db-private-sgといった命名は、レビューや障害対応時において責任範囲や通信経路を直感的に把握するのに役立ちます。一方で、曖昧または汎用的な名称は監査プロセスを遅延させ、設定ミスのリスクを高める要因となります。

4. 未使用ルールの定期的な監査

未使用のルールは定期的にレビューし、不要なものは削除する必要があります。デバッグや移行作業中に一時的に追加されたアクセス許可が、そのまま放置されて恒久化してしまうケースは少なくありません。時間の経過とともに、これらのルールは文脈を失い、潜在的なセキュリティリスクへと変化します。ルールセットは可能な限りシンプルに保つことで、理解しやすく、より安全な運用が可能になります。

5. 他のセキュリティレイヤーと組み合わせる

Security Groupはインスタンスレベルのアクセス制御に限定されるため、それ単体では十分な防御とは言えません。インターネット公開システムにおいては、Network ACL、AWS WAF、AWS Shieldと組み合わせることで、多層防御（defense in depth）を実現する必要があります。

EC2におけるIPアドレッシングとネットワーク設計

プライベートIPアドレス

プライベートIPアドレスは、プライベートネットワーク内部での通信に使用されます。

これらはインターネットから直接アクセスすることはできません。EC2インスタンスが外部サービスへアクセスする必要がある場合、トラフィックはNAT GatewayまたはNATインスタンスを経由する必要があります。プライベートIP自体がインターネットと直接通信することはできません。

AWSでは、以下の3つのプライベートIPv4アドレス範囲がサポートされています：

• 10.0.0.0/8
• 172.16.0.0/12
• 192.168.0.0/16

インスタンスが内部サービスとの通信のみを必要とする場合は、プライベートIPを使用すべきです。

代表的なユースケースは以下の通りです：

• データベース接続やマイクロサービス間通信などのサービス間通信
• プライベートサブネット内のApplication Load Balancerなど、内部向けロードバランサー
• 複数VPC間の通信を可能にするVPCピアリング
• オンプレミス環境とAWS間のVPN接続

パブリックIPアドレス

パブリックIPアドレスは、EC2インスタンスがVPC内部およびインターネットの両方と通信することを可能にします。これらはプライベートIP範囲に属さない任意のIPv4アドレスです。

パブリックIPの主な特性は以下の通りです：

• 動的割り当て：インスタンスを停止・再起動するとIPアドレスが変更される可能性がある
• Internet Gatewayが必要：インターネットとの通信には、VPCにInternet Gatewayがアタッチされている必要がある
• 課金対象：パブリックIPv4アドレスは、AWSの料金体系に基づき時間単位で課金される
• グローバルに一意：インターネット上で一意のアドレスである

一方で、いくつかの制約にも注意が必要です。これらの制約により、パブリックIPは安定したエンドポイントを必要とするワークロードには一般的に適していません。

パブリックIPには以下のような制限があります：

• インスタンスの停止・起動時に変更される
• 他のインスタンスへ再割り当てできない
• インスタンス終了時に解放される
• 特定のIPアドレスを指定・制御できない

Elastic IP (EIP)

デフォルトでは、EC2インスタンスのパブリックIPアドレスは停止および再起動のたびに変更されます。この挙動は一時的なワークロードでは問題ありませんが、安定したエンドポイントを必要とする本番環境では大きな課題となります。Elastic IPは、この制約を解決するために設計されています。

Elastic IPとは、EC2インスタンスに割り当てることができる予約済みのパブリックIPv4アドレスです。インスタンスを停止・再起動しても変更されず、必要に応じて別のインスタンスへ再割り当てすることも可能です。

Elastic IPの主な特性は以下の通りです：

• 固定パブリックIP：停止・起動を行ってもアドレスは変わらない
• 再割り当て可能：インスタンス間で付け替えが可能であり、障害対応やインスタンス置き換え時に有効
• リージョン単位のリソース：特定のAWSリージョンに属し、他リージョンへ移動できない
• 未使用時は課金対象：稼働中のインスタンスに関連付けられていない場合、料金が発生する

本番環境におけるElastic IPの利用方法

1. 必要最小限に利用する

Elastic IPは、外部システムが固定IPアドレスを必要とする場合にのみ使用すべきです。これは、IPアドレスによる許可リスト（allowlist）やレガシーシステム連携でよく見られます。

2. まずは代替手段を検討する

多くの本番システムにおいて、Elastic IPはデフォルトの選択肢として最適とは限りません。

• Application Load BalancerとRoute 53を組み合わせることで、安定したDNSとフェイルオーバーを実現可能
• CloudFrontはカスタムドメインによるグローバルアクセスに適している
• アウトバウンド専用のインターネット通信にはNAT Gatewayが適切

3. 無駄を避ける
   停止中のインスタンスに紐付いたElastic IPや未使用のElastic IPはコストが発生します。 不要なElastic IPは解放する必要があります。
4. 利用状況とコストを監視する
   Elastic IPの使用状況は見落とされがちです。

課金アラートを設定することで、気付かないうちにコストが増加するのを防ぐことができます。

コスト概要

• 稼働中のインスタンスに関連付けられている場合：追加料金なし
• 停止中のインスタンスに関連付けられている場合：1時間あたり0.005ドル
• 未関連付け（未使用）の場合：1時間あたり0.005ドル
• 1インスタンスあたりの追加Elastic IP：1時間あたり0.005ドル

IPv6対応

EC2はデュアルスタックネットワーキングに対応しており、インスタンスはIPv4アドレスとIPv6アドレスの両方を持つことが可能です。

AWSにおけるすべてのIPv6アドレスはグローバルユニキャストであり、デフォルトでパブリックにルーティング可能です。IPv6の利用に追加コストは発生せず、128ビットのアドレス空間によりIPv4アドレス枯渇の問題も解消されます。

EC2でIPv6を有効化するには、以下の手順が必要です。

• VPCレベルでIPv6 CIDRブロックを有効化する
• サブネットにIPv6 CIDRブロックを関連付ける
• ルートテーブルにIPv6ルートを追加する
• セキュリティグループのルールでIPv6トラフィックを許可する
• EC2インスタンスでIPv6の自動割り当てを有効化する

設定後、EC2インスタンスはデュアルスタックモードで動作し、必要に応じてIPv4およびIPv6の両方で通信できるようになります。

ストレージ管理：EBS、AMI、スナップショット

Elastic Block Store (EBS)

Elastic Block Storeは、EC2向けのAWSのブロックストレージサービスです。EBSボリュームはEC2インスタンスへのアタッチおよびデタッチが可能であり、インスタンスのライフサイクルとは独立してデータを永続化し、複数のインスタンス間で再利用することができます。

EBSボリューム作成時には、ワークロード要件に応じてIOPSやスループットを設定できます。

なお、EBSボリュームはサイズの拡張は可能ですが、縮小することはできません。AWSコンソールまたはCLIを使用してボリュームサイズを拡張した場合、OSレベルでファイルシステムの拡張も実施する必要があります。この手順を行わない場合、追加された容量はOSから認識されません。

EBSの主な機能：

• 保存データおよび転送中データに対するAES-256による暗号化
• io1およびio2ボリュームタイプにおけるMulti-Attachのサポート
• Amazon S3に保存されるポイントインタイムスナップショット
• Elastic Volumesにより、ダウンタイムなしでサイズ、タイプ、性能の変更が可能

Amazon Machine Images (AMI)

Amazon Machine Image（AMI）は、EC2インスタンスを起動するためのテンプレートです。

AMIには以下が含まれます：

• オペレーティングシステムおよび事前にインストールされたソフトウェア
• 1つ以上のアタッチされたEBSボリューム
• AMIの利用可否を制御する起動権限（Launch Permissions）
• ストレージ構成を定義するブロックデバイスマッピング

AMIは既存のEC2インスタンスから作成することが可能です。これにより、動作確認済みの構成をそのまま保存し、同一構成のインスタンスを再利用・展開することができます。

AMIには以下の種類があります：

• AWSまたはコミュニティが提供するパブリックAMI
• AWS Marketplaceで提供される商用AMI
• 自分のAWSアカウント内で利用するプライベートAMI
• 他のAWSアカウントから共有されたAMI

本番環境では、AMIはデプロイの標準化、セットアップ時間の短縮、およびスケーリングやインスタンス置き換え時の迅速な復旧を目的として広く利用されています。

スナップショット

スナップショットは、Amazon S3に保存されるEBSボリュームのポイントインタイムバックアップです。初回のスナップショットはボリューム全体を取得し、それ以降は前回から変更されたブロックのみを保存する増分方式となります。

スナップショットは以下の用途で利用できます：

• 障害発生時のデータ復旧
• 新規EBSボリュームの作成
• 新規AMIの作成
• AWSリージョン間でのデータコピー

スナップショットの作成は、稼働中のEC2インスタンスを停止することなく実行可能です。ただし、整合性が重要なワークロードでは、ボリュームが安定した状態で取得することが推奨されます。

主な特性：

• 増分バックアップによりストレージコストを削減
• リージョン間コピーに対応
• 暗号化されたEBSボリュームに対してはスナップショットも暗号化
• ポイントインタイムでの復旧が可能
• ボリューム全体ではなく、実際に保存されたデータ量に対してのみ課金

EBSパフォーマンスとコストの最適化

EBSのパフォーマンスは、ワークロード要件に応じてIOPSやスループットを調整することで最適化できます。

IOPSの最適化

• gp3: ベースライン3,000 IOPS、最大16,000 IOPSまでスケール可能
• io2: 最大256,000 IOPSをサポートし、Multi-Attachに対応
• 一貫性と予測可能性が求められるワークロードには、より高いIOPSをプロビジョニングする
• EC2とEBS間の帯域を確保するため、EBS最適化インスタンスを利用する

スループットの最適化

• gp3: スループットを最大1,000 MiB/sまで独立して設定可能
• st1: シーケンシャルアクセスに最適化されたHDDボリューム
• RAID 0を使用することでスループットを向上可能（ただし障害リスクに注意）
• スナップショットから復元後は、全ブロックを読み込むことでボリュームをウォームアップする

コストの最適化

• gp2からgp3へ移行することでストレージコストを削減（最大20%）
• CloudWatchメトリクスを監視し、実使用量に基づいてボリュームサイズを適正化する
• スナップショットのライフサイクルポリシーを適用し、古いバックアップを自動削除する
• アクセス頻度の低いデータにはCold HDD（sc1）を使用する

本番環境におけるEC2運用：ベストプラクティス

AWSリージョン選定の基準

AWSリージョンの選択は、レイテンシー、コンプライアンス、コスト、サービス可用性に影響を与えます。これらの要素は、本番環境でEC2インスタンスを起動する前に十分に評価する必要があります。

レイテンシー

• エンドユーザーに最も近いリージョンを選択し、アクセスレイテンシーを低減する
• アジアパシフィック（シンガポール）– ap-southeast-1：東南アジア向けに最適
• 米国東部（バージニア北部）– us-east-1：CloudFrontやRoute 53などのグローバルサービスに最適
• 欧州（アイルランド）– eu-west-1：欧州ユーザー向けに適している
• レイテンシー測定ツール：CloudPing、AWS Region latency checker

法規制およびコンプライアンス要件

• 規制により、特定リージョンでのデータ保存が求められる場合がある
• GDPR対応：欧州市民データはEUリージョンでの管理が必要
• データレジデンシー：政府・金融分野における要件
• SOC / PCI DSS：必要な認証を取得しているリージョンでのみ利用可能

コスト

• EC2およびAWSサービスの料金はリージョンごとに異なる
• us-east-1（バージニア北部）：一般的に最も低コストで基準となる価格
• us-west-2（オレゴン）：米国西海岸向けに競争力のある価格
• ap-southeast-1（シンガポール）：コストは高めだがアジア向けに適している
• eu-west-1（アイルランド）：欧州ワークロード向けに中程度のコスト

サービス可用性

すべてのインスタンスタイプやAWSサービスがすべてのリージョンで利用できるわけではありません。新しいインスタンスファミリーは通常、主要リージョンから提供が開始されます。また、一部のマネージドサービスは特定リージョンに限定されており、先進的なAI/MLサービスは利用可能なリージョンが限られる場合があります。

インスタンスサイジングとキャパシティプランニング

EC2インスタンスを起動する際には、まずアプリケーションのリソース使用特性（CPU、メモリ、ディスクI/O）を把握する必要があります。これにより、適切なインスタンスタイプを選定することができます。

また、ステートレスワークロードとステートフルワークロードを区別することも重要です。ステートレスなアプリケーションはスケールしやすく、スポットインスタンスの利用にも適しています。一方で、ステートフルなワークロードは、安定したインスタンスと永続ストレージを必要とするケースが一般的です。

• リソースプランニングのアプローチ：
  • ベースライン測定：現在のリソース使用状況を測定する
  • ピーク分析：負荷のピークパターンを特定する
  • 成長予測：今後6〜12か月の利用増加を見込んだ計画を立てる
  • コストモデリング：異なるインスタンスタイプや料金モデルを比較する
  • モニタリング設定：リソース使用率に対するCloudWatchアラームを設定する
     
• ライトサイジングの指針：
  • CPU使用率：平均70〜80％を目安とし、スパイクに備えた余裕を確保する
  • メモリ使用率：スワップを回避するため、80〜85％を目安とする
  • ネットワーク使用率：帯域使用パターンを継続的に監視する
  • ストレージIOPS：実測ピークIOPSの約20％上を目安にプロビジョニングする

セキュリティおよびコンプライアンスチェックリスト

EC2ワークロードを本番環境で運用する前に、基本的なセキュリティおよびコンプライアンスのベースラインを確立しておく必要があります。

以下のチェックリストは、実運用環境で一般的に求められる、EC2に特化した実践的な対策に焦点を当てています。

• 最新のセキュリティパッチが適用されたAMIを使用する
• セキュリティグループにおいて最小権限の原則を適用する
• すべての永続データに対してEBS暗号化を有効化する
• 長期的なアクセスキーの代わりにIAMロールを使用する
• 可能な限りEC2インスタンスをプライベートサブネットに配置する
• 直接的なSSHアクセスを避け、SSM Session Managerを利用する
• すべての公開系ワークロードをロードバランサの背後に配置する
• 保持ポリシー付きでEBSスナップショットを自動取得する
• 一貫した再デプロイおよび復旧のために、AMIを定期的に作成する

EC2運用の自動化

システム規模が拡大するにつれて、インスタンスの手動管理は困難になります。本番環境では、一貫性、スケーラビリティ、安全なデプロイを確保するために、EC2運用は自動化されるのが一般的です。

一般的なパターンとして、インスタンスはAuto Scaling Group（ASG）内で実行されます。ASGは、負荷やヘルスチェックに基づいてインスタンス数を自動的に調整し、障害が発生したインスタンスを手動介入なしで置き換えます。通常、これらはApplication Load Balancerなどのロードバランサーの背後に配置され、複数のインスタンスおよびアベイラビリティゾーンにトラフィックを分散します。

インスタンス構成は通常、Launch Templateによって定義されます。これにより、AMI、インスタンスタイプ、IAMロール、ネットワーク設定、ブートストラップスクリプトなどのパラメータが標準化されます。その結果、新しく起動されるインスタンスは既存のインスタンスと同一の構成になります。

インフラの再現性を確保するために、多くのチームはAWS CloudFormationやTerraformなどのInfrastructure as Codeツールを使用してEC2環境を管理します。このアプローチにより、インフラ変更はバージョン管理され、レビューされ、複数環境に一貫してデプロイすることが可能になります。

アプリケーションの更新には、Blue-Greenデプロイメントがよく利用されます。新しいバージョンのアプリケーションを含む環境を別途構築し、テスト後にロードバランサーを用いてトラフィックを切り替えます。問題が発生した場合は、トラフィックを迅速に旧環境へ戻すことができます。

モニタリングとオブザーバビリティ

信頼性の高いEC2ワークロードを維持するためには、パフォーマンス低下、障害、異常な挙動を検知するための継続的なモニタリングが不可欠です。

CPU使用率、ネットワークスループット、インスタンスのヘルス状態などのインフラメトリクスは、Amazon CloudWatchによって収集されます。これらのメトリクスにより、インスタンスのパフォーマンス状況や、追加のキャパシティが必要かどうかを可視化できます。

CloudWatchアラームを使用することで、しきい値を超えた場合にオペレーターへ通知したり、高負荷時にインスタンスをスケールアウトするなどの自動アクションをトリガーすることが可能です。

ログは通常、Amazon CloudWatch Logsや外部のオブザーバビリティプラットフォームを利用して一元管理されます。ログの集中管理により、トラブルシューティングが容易になり、監査やコンプライアンス要件への対応にも役立ちます。

最後に、ロードバランサーによるヘルスチェックおよびEC2のステータスチェックにより、不健全なインスタンスを検出することができます。これらをAuto Scalingと組み合わせることで、障害インスタンスは自動的に除去・置き換えされ、システム全体の耐障害性が向上します。

まとめ

EC2は過度に複雑に考えなければ、本番環境でも安定して運用することができます。
公開範囲を最小限に抑え、実際の利用状況に基づいてサイジングを行い、システムの成長に合わせてセキュリティとストレージを適切に管理することが重要です。多くの問題はEC2そのものではなく、初期段階での小さな妥協や設計上の近道から生じます。

Haposoftでは、本番レベルのAWSシステムの設計および運用を支援しています。主なサービス内容は以下の通りです：

• スケーラブルなアプリケーションのためのAWSアーキテクチャ設計
• EC2のセキュリティ強化およびネットワーク設計
• コスト最適化およびライトサイジング戦略の策定
• Terraformなどを用いたInfrastructure as Codeによるインフラ自動化
• モニタリングおよび運用ベストプラクティスの導入

すでにEC2を本番環境でご利用中で、構成の妥当性を専門的な視点で確認したい場合は、ぜひHaposoftまでご相談ください。セキュリティ、信頼性、コスト効率の観点から現状のアーキテクチャを評価し、改善の機会をご提案いたします。