Amazon Web Services ブログ

新機能 – VPC Reachability Analyzer

Amazon Virtual Private Cloud (VPC) を使用すると、お客様は、論理的に分離された専用の仮想ネットワークを、AWS クラウド上で起動できます。クラウド上でお客様のフットプリントが拡大し、デプロイされるネットワークアーキテクチャの複雑さも増していく中、誤った設定が原因で発生するネットワーク接続の問題は、その解決に時間がかかるようになっています。今回、当社では、ネットワーク診断ツールである VPC Reachability Analyzer を発表できる運びとなりました。このツールでは、VPC 内の 2 つのエンドポイント間、または複数の VPC 間で、通信の到達性に関する問題を解決できます。

ネットワークが目的どおりに設定されているかを確認
Reachability Analyzer のユーザーは、仮想ネットワーク環境を全体的に制御できます。独自の IP アドレス範囲の選択、サブネットの作成、またルートテーブルやネットワークゲートウェイの設定が可能です。また、VPC のネットワーク設定のカスタマイズも簡単です。例えば、ウェブサーバー用にパブリックサブネットを作成する際、インターネットへのアクセスに、インターネットゲートウェイを使用するように構成できます。データベースやアプリケーションサーバーなど、厳しいセキュリティが必要なバックエンドシステムは、インターネットにアクセスできないプライベートサブネットに配置できます。セキュリティグループや、ネットワークアクセスコントロールリスト (ACL) など、複数のセキュリティレイヤーを使用することで、各サブネットのエンティティへのアクセスを、プロトコル、IP アドレス、ポート番号によって制御できます。

また、VPC ピアリング、もしくは AWS Transit Gateway を経由させながら、リージョン全体またはグローバルなネットワーク接続の中で複数の VPC を組み合わせれば、トラフィックを非公開にルーティングさせられます。さらに、サイトを AWS アカウントに接続して、安全な通信を行うために、VPN Gateway を使用することもできます。AWS LambdaAmazon S3 など、VPC 外に配置された多くの AWS のサービスでは、VPC エンドポイントAWS PrivateLink を VPC 内のエンティティとしてサポートしており、それらのエンティティとは、プライベートな通信が可能です。

このような豊富なコントロールと機能セットがあると、接続の問題を引き起こし得るような意図しない構成を行ってしまうことも、珍しいことではありません。今回リリースされた VPC Reachability Analyzer を使用すると、パケットを一切送信せずに 2 つのエンドポイント間での到達性を解析できます。VPC Reachability Analyzer では、VPC 内のすべてのリソースの設定が確認され、自動化された推論を使用して、実現可能なネットワークフローが特定されます。実際の回線にはトラフィックは一切送信されないまま、ネットワーク内で可能性のある、すべてのパスが分析されます。これらのアルゴリズムの仕組みの詳細については、re: Invent でのトーク、あるいはこちらの資料でご確認ください。

VPC Reachability Analyzer の仕組み
それでは、このツールの仕組みを見てみましょう。VPC Reachability Analyzer の使用は非常に簡単で、そのテストは現在ご使用中の VPC で行っていただけます。テストのために分離された VPC が必要な場合は、この記事の下部にある AWS CloudFormation のYAML テンプレートを実行してください。このテンプレートでは、1 個のサブネット、2 個のセキュリティグループ、そして A、B、C として 3 個のインスタンスを設定しながら VPC を作成します。インスタンス A と B は相互に通信できますが、インスタンス C にアタッチされたセキュリティグループでは着信トラフィックが許可されないため、それら 2 つのインスタンスはインスタンス C と通信できません。

Reachability Analyzer は、VPC マネジメントコンソールの左側のナビゲーションに表示されます。

[Reachability Analyzer] をクリックした後、[Create and analyze path (パスの作成と解析) ] ボタンをクリックすると新しいウィンドウが表示されるので、送信元と送信先の間のパスを指定して解析を開始できます。

エンドポイントタイプは、送信元と送信先で以下のいずれかが指定できます: VPN ゲートウェイ、インスタンス、ネットワークインターフェイス、インターネットゲートウェイ、VPC エンドポイント、VPC ピアリング接続、トランジットゲートウェイ。ここでは、インスタンス A を送信元に、インスタンス B を送信先に設定しています。接続の確認に使用するプロトコルは、TCP または UDP から選択できます。オプションで、ポート番号と、送信元または送信先の IP アドレスも指定できます。

テストパスの設定

最後に、[Create and analyze path (パスの作成と解析) ] ボタンをクリックして解析を開始します。VPC のサイズと複雑さによっては、解析には数分かかる場合がありますが、通常は数秒で完了します。

この場合、解析結果は [Reachable (到達可能) ] として表示されます。解析 ID nip-xxxxxxxxxxxxxxxxx の URL リンクをクリックすると、ホップごとにルートを確認できます。

インスタンス C にアタッチされたセキュリティグループでは着信トラフィックが許可されていないため、通信はインスタンス A からインスタンス C に到達できません。

ここで nip-xxxxxxxxxxxxxxxxx をクリックすると、[Explanations (詳細) ] が表示され内容を確認できます。

結果の詳細

ここでは、通信をブロックしたセキュリティグループが表示されています。右上に表示されているセキュリティグループをクリックすると、セキュリティグループの編集ウィンドウに直接移動して、セキュリティグループのルールを変更できます。この場合では、適切なスコープが設定されたイングレスルールを追加することで、インスタンスに通信を許可できます。

今すぐご利用いただけます
この機能は、中国 (北京) および 中国 (寧夏) リージョンを除く、すべての AWS 商用リージョンで利用可能です。詳細については、技術ドキュメントを参照してください。また、この機能を使用する際は、こちらのドキュメントを参考にしながら、IAM のアクセス許可を設定していただく必要があります。

– Kame

テスト用の CloudFormation YAML テンプレート

---
Description: An AWS VPC configuration with 1 subnet, 2 security groups and 3 instances.When testing ReachabilityAnalyzer, this provides both a path found and path not found scenario.
AWSTemplateFormatVersion: 2010-09-09

Mappings:
  RegionMap:
    us-east-1:
      execution: ami-0915e09cc7ceee3ab
      ecs: ami-08087103f9850bddd

Resources:
  # VPC
  VPC:
    Type: AWS::EC2::VPC
    Properties:
      CidrBlock: 172.0.0.0/16
      EnableDnsSupport: true
      EnableDnsHostnames: true
      InstanceTenancy: default

  # Subnets
  Subnet1:
    Type: AWS::EC2::Subnet
    Properties:
      VpcId: !Ref VPC
      CidrBlock: 172.0.0.0/20
      MapPublicIpOnLaunch: false

  # SGs
  SecurityGroup1:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: Allow all ingress and egress traffic
      VpcId: !Ref VPC
      SecurityGroupIngress:
        - CidrIp: 0.0.0.0/0
          IpProtocol: "-1" # -1 specifies all protocols

  SecurityGroup2:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: Allow all egress traffic
      VpcId: !Ref VPC

  # Instances
  # Instance A and B should have a path between them since they are both in SecurityGroup 1
  InstanceA:
    Type: AWS::EC2::Instance
    Properties:
      ImageId:
        Fn::FindInMap:
          - RegionMap
          - Ref: AWS::Region
          - execution
      InstanceType: 't3.nano'
      SubnetId:
        Ref: Subnet1
      SecurityGroupIds:
        - Ref: SecurityGroup1

  # Instance A and B should have a path between them since they are both in SecurityGroup 1
  InstanceB:
    Type: AWS::EC2::Instance
    Properties:
      ImageId:
        Fn::FindInMap:
          - RegionMap
          - Ref: AWS::Region
          - execution
      InstanceType: 't3.nano'
      SubnetId:
        Ref: Subnet1
      SecurityGroupIds:
        - Ref: SecurityGroup1

  # This instance should not be reachable from Instance A or B since it is in SecurityGroup 2
  InstanceC:
    Type: AWS::EC2::Instance
    Properties:
      ImageId:
        Fn::FindInMap:
          - RegionMap
          - Ref: AWS::Region
          - execution
      InstanceType: 't3.nano'
      SubnetId:
        Ref: Subnet1
      SecurityGroupIds:
        - Ref: SecurityGroup2