222-AWS SAP AWS 「理論・実践・一問道場」トラフィックをEC2インスタンス経由

type

status

date

slug

summary

理論

AWS VPCでトラフィックをEC2インスタンス経由にする理由と課題

背景：問題の設定

ある企業がVPC内外のすべてのネットワークトラフィックを3台のEC2インスタンス経由で処理し、分析ソフトウェアを実行しています。このような構成を取る理由や課題について、以下で解説します。

1. すべてのトラフィックをEC2インスタンス経由にする目的

セキュリティの強化

トラフィックを一元的に検査し、外部からの不正アクセスや内部の異常な通信を検知・遮断する。

IDS/IPS（侵入検知/防止システム）やファイアウォールを導入することで、セキュリティリスクを軽減。

トラフィックの可視化と管理

トラフィックの量やパターンを監視し、ネットワークのボトルネックや異常を特定。

運用データを基に、ネットワーク設計や負荷分散を最適化。

拡張性と柔軟性

トラフィック分析やセキュリティルールをアップデートしやすく、新たな要件にも柔軟に対応可能。

2. 設定方法のポイント

ルーティング設定

VPCのルートテーブルで、VPC内部や外部インターネットへのすべてのトラフィックを、3台のEC2インスタンス（またはそのENI: Elastic Network Interface）に向ける。

NATゲートウェイまたはゲートウェイ型ロードバランサ（GWLB）の活用

VPC内外の通信を最適に制御するため、NATやGWLBを使ってトラフィックをEC2インスタンスに転送。

Auto Scalingとルートの更新

Auto Scalingでインスタンスを置き換える場合、新しいインスタンスのENIにルートを更新する必要がある。
このために、CloudWatchアラームやLambda関数を活用し、自動的にルート更新を行う仕組みを構築。

3. 課題と解決策

課題：インスタンス置き換え時のルート更新

Auto Scalingによってインスタンスが置き換えられても、ルートが古いインスタンスを指したままになると、トラフィックが正しく処理されなくなる。

解決策

CloudWatchとLambdaの連携：インスタンスの異常を監視し、置き換え後にルートテーブルを新しいインスタンスに自動更新。
ゲートウェイ型ロードバランサの導入：GWLBを活用し、インスタンスの追加や置き換えを抽象化する。

4. まとめ

このような構成は、セキュリティと可視化を重視したネットワーク設計において非常に重要です。ただし、インスタンスの置き換えに伴うルートの管理や設定の自動化が不可欠です。AWSが提供するツール（CloudWatch、Lambda、GWLBなど）を活用することで、より堅牢で効率的なシステムを構築できます。

実践

略

一問道場

問題 #222

トピック 1

ある企業は、VPCを出入りするトラフィックを検査するカスタムネットワーク分析ソフトウェアパッケージを実行したいと考えています。この企業は、AWS CloudFormationを使用して、Auto Scalingグループ内の3つのAmazon EC2インスタンスにこのソリューションを展開しました。すべてのネットワークルーティングは、トラフィックをEC2インスタンスに向けるように設定されています。

分析ソフトウェアが停止すると、Auto Scalingグループはインスタンスを置き換えますが、インスタンスの置き換えが行われてもネットワークルートは更新されません。

この問題を解決するためのステップの組み合わせはどれですか？（3つ選んでください）

A. EC2ステータスチェックメトリクスに基づくアラームを作成し、Auto Scalingグループが障害のあるインスタンスを置き換えるようにする。

B. CloudFormationテンプレートを更新して、EC2インスタンスにAmazon CloudWatchエージェントをインストールする。CloudWatchエージェントを構成して、アプリケーションのプロセスメトリクスを送信する。

C. CloudFormationテンプレートを更新して、EC2インスタンスにAWS Systems Managerエージェントをインストールする。Systems Managerエージェントを構成して、アプリケーションのプロセスメトリクスを送信する。

D. カスタムメトリクスの障害シナリオに対するアラームをAmazon CloudWatchで作成する。アラームがAmazon Simple Notification Service (Amazon SNS)トピックにメッセージを送信するように設定する。

E. Amazon SNSメッセージに応答するAWS Lambda関数を作成し、そのインスタンスをサービスから外す。ネットワークルートを更新して、置き換えられたインスタンスに指すようにする。

F. CloudFormationテンプレートに条件を記述して、インスタンスが置き換えられるとネットワークルートを更新する。

解説

選択肢 B, D, E も問題の解決に有効です。以下にそれぞれの選択肢について詳しく説明します。

B. CloudFormationテンプレートを更新して、EC2インスタンスにAmazon CloudWatchエージェントをインストールする。CloudWatchエージェントを構成して、アプリケーションのプロセスメトリクスを送信する。

→ CloudWatchエージェントを使って、アプリケーションのメトリクスを監視することができます。これにより、インスタンスの状態やアプリケーションのパフォーマンスを監視し、障害を早期に発見することが可能になります。

D. カスタムメトリクスの障害シナリオに対するアラームをAmazon CloudWatchで作成する。アラームがAmazon Simple Notification Service (Amazon SNS)トピックにメッセージを送信するように設定する。

→ CloudWatchのカスタムメトリクスを使って、インスタンスの障害を検出し、SNSメッセージを送信することで、インスタンスの障害が発生したことを通知します。この通知を利用して適切な対応が可能になります。

E. Amazon SNSメッセージに応答するAWS Lambda関数を作成し、そのインスタンスをサービスから外す。ネットワークルートを更新して、置き換えられたインスタンスに指すようにする。

→ SNSメッセージを受け取るLambda関数がネットワークルートを更新し、新しいインスタンスに向けてトラフィックをルーティングします。これにより、インスタンスが置き換えられた後も、ルーティングが自動的に更新されることになります。

これらのステップを組み合わせることで、インスタンスの障害時にトラフィックが新しいインスタンスに向けて自動的に再ルーティングされ、ネットワークの設定も適切に更新されます。