MENU
CloudFormationでAWS環境を構築
  1. ホーム
  2. AWS
  3. LinuxインスタンスにSSM Session Manager経由でアクセスする

LinuxインスタンスにSSM Session Manager経由でアクセスする

AWS
LinuxインスタンスにSSM Session Manager経由でアクセスする

LinuxインスタンスにSSM Session Manager経由でアクセスする

EC2インスタンスにSSM Session Manager経由でアクセスする構成を確認します。

Session Manager は完全マネージド型の AWS Systems Manager 機能です。ブラウザベースのインタラクティブなワンクリックシェルまたは AWS CLI を介して Amazon EC2 インスタンスを管理できます。Session Manager を使用して、アカウント内のインスタンスとのセッションを開始できます。セッションの開始後、他の接続タイプと同様、bash コマンドを実行できます。

Session Manager を使用した Linux インスタンスへの接続

SSM Session Managerを使用したインスタンスへのアクセスは、一般的なSSHでのアクセスと比べてさまざまなメリットがあります。特に注目すべきポイントは、リモートアクセス用のポート開放が不要になる点と、踏み台サーバも不要になる点です。

インスタンスでインバウンド SSH ポートとリモート PowerShell ポートを開いたままにすると、エンティティが許可されていないコマンドや、悪意のあるコマンドをインスタンス上で実行するリスクが大幅に増加します。Session Manager は、これらの着信ポートを閉じることにより、SSH キーと証明書、踏み台ホスト、およびジャンプボックスの管理からユーザーを解放して、セキュリティ体制を向上させるのに役立ちます。

AWS Systems Manager Session Manager

今回はSSM Session Managerを使用してEC2インスタンスにアクセスする3パターンをご紹介します。

  • インターネット経由でSSM Session Managerを使用してアクセス
  • NATゲートウェイ経由でSSM Session Managerを使用してアクセス
  • VPCエンドポイント経由でSSM Session Managerを使用してアクセス

SSM Session Managerを使用した接続の比較対象として、SSHを使用した接続もご紹介します。

なお本ページはLinuxインスタンスを対象とした内容です。WindowsインスタンスにSession Manager経由でアクセスする方法については、以下のページをご確認ください。

あわせて読みたい
WindowsインスタンスにSSM Session Manager経由でアクセスする 【WindowsインスタンスにSSM Session Manager経由でアクセスする構成】 WindowsインスタンスにSSM Session Manager経由でアクセスする構成を確認します。 Session Manag...

構築する環境

Diagram of accessing Linux instance via SSM Session Manager

2つのVPCを作成します。

1つ目のVPCには2つのサブネットを作成します。
1つはインターネットにアクセス可能なパブリックサブネットとし、もう1つは不可なプライベートサブネットとします。
パブリックサブネットにインターネットゲートウェイとNATゲートウェイを作成します。

2つ目のVPCにはプライベートサブネットを1つ作成します。
こちらのVPCにはSSM用のVPCエンドポイントを設定します。

1つ目のVPCには3つのEC2インスタンス、2つ目のVPCにはEC2インスタンスを1つ作成します。
今回作成するインスタンスは最新のAmazon Linux 2023とします。

検証シナリオ

4つのインスタンスに対してアクセスを試みます。
以下に4インスタンスへのアクセス方法と、そのために作成するリソースを整理します。

ポイントはアクセス時の経路と方法です。

インスタンス経路方法
インスタンス1インターネットゲートウェイSSH
インスタンス2インターネットゲートウェイSSM Session Manager
インスタンス3NATゲートウェイSSM Session Manager
インスタンス4VPCエンドポイントSSM Session Manager

環境構築用のCloudFormationテンプレートファイル

上記の構成をCloudFormationで構築します。
以下のURLにCloudFormationテンプレートを配置しています。

https://github.com/awstut-an-r/awstut-fa/tree/main/003

テンプレートファイルのポイント解説

セキュリティグループ設定

SSHとSSM Session Managerを比較する上で大きな違いがあるのがセキュリティグループです。
SSHの場合、同サービス用のポート(一般にtcp/22)を開ける必要があります。
一方SSM Session Managerであれば、そのような対応は不要です。

以下がセキュリティグループにおいて各インスタンスが許可するインバウンド通信をまとめた表です。

インスタンス方法セキュリティグループ
インスタンス1SSH22/tcpを許可
インスタンス2SSM Session Manager–
インスタンス3SSM Session Manager–
インスタンス4SSM Session Manager–

インスタンス1：SSHを許可するセキュリティグループ

Resources:
  InstanceSecurityGroup1:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupName: !Sub "${Prefix}-InstanceSecurityGroup1"
      GroupDescription: Allow SSH.
      VpcId: !Ref VPC1
      SecurityGroupIngress:
        - IpProtocol: tcp
          FromPort: !Ref SSHPort
          ToPort: !Ref SSHPort
          CidrIp: 0.0.0.0/0
Code language: YAML (yaml)

セキュリティグループを考える上でポイントは2つです。

1つ目はポート番号です。
今回はSSH(22/tcp)によってこのセキュリティグループが適用されるインスタンス1にアクセスしますから、同ポートを指定します。

2つ目は送信元です。
今回はCIDRとして「0.0.0.0/0」を指定します。
このように設定することによって、全送信元アドレスからのアクセスを許可することを意味します。

以上をまとめるとインターネット経由の全アドレスからのSSHを許可することになります。

インスタンス2および3：SSM Session Managerではインバウンド通信は発生しない

Resources:
  InstanceSecurityGroup2:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupName: !Sub "${Prefix}-InstanceSecurityGroup2"
      GroupDescription: Deny All.
      VpcId: !Ref VPC1
Code language: YAML (yaml)

インスタンス2および3に適用するセキュリティグループです。
インスタンス1と比較すると良くわかりますが、何もインバウンド通信を許可していません。
つまり全てのインバウンド通信を許可しないということです。

実はSSM Session Manager等のSSMの働きは、インスタンス内のSSMエージェントが実行しています。
SSMエージェントはSSMと定期的に通信しており、この時の通信はSSMエージェントが送信元、SSMが宛先となります。
つまりSSM Session Managerを実行するためには、許可するべきインバウンド通信が存在しないということです。
ですから全インバウンド通信を許可しないセキュリティグループを作成します。

インスタンス4：VPCエンドポイント用のセキュリティグループではインスタンスからのHTTPSを許可する

Resources:
  InstanceSecurityGroup3:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupName: !Sub "${Prefix}-InstanceSecurityGroup3"
      GroupDescription: Deny All.
      VpcId: !Ref VPC2

  EndpointSecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupName: !Sub "${Prefix}-EndpointSecurityGroup"
      GroupDescription: Allow HTTPS from InstanceSecurityGroup3.
      VpcId: !Ref VPC2
      SecurityGroupIngress:
        - IpProtocol: tcp
          FromPort: !Ref HTTPSPort
          ToPort: !Ref HTTPSPort
          SourceSecurityGroupId: !Ref InstanceSecurityGroup3
Code language: YAML (yaml)

前者がインスタンス4に適用するセキュリティグループです。
本インスタンスもSSM Session Managerを使用するため、全インバウンド通信を許可していません。

注目するべきは後者のセキュリティグループです。
これはVPCエンドポイント用です。
インスタンス4からのHTTPS通信(443/tcp)を許可します。

これは後述するVPCエンドポイントを作成する上での要件の1つです。

VPC エンドポイントにアタッチされたセキュリティグループでは、マネージドインスタンスのプライベートサブネットから、ポート 443 で着信接続を許可する必要があります。着信接続が許可されていない場合、マネージドインスタンスは SSM および EC2 エンドポイントに接続できません。

VPC エンドポイントの制約と制限

ルーティング設定

ルーティングを考える上でのポイントはインターネットゲートウェイを経由するかどうかです。
インターネットゲートウェイを経由する場合は、同ゲートウェイ向けのルーティング設定が必要となります。
一方インターフェースタイプのVPC Endpointを使用する場合はルーティング設定は不要です。

以下が各インスタンスに関係するルーティング設定をまとめた表です。

インスタンス方法経路配置するサブネットルーティング
インスタンス1SSHインターネットゲートウェイパブリックサブネットインターネット向け
インスタンス2SSM Session Managerインターネットゲートウェイパブリックサブネットインターネット向け
インスタンス3SSM Session ManagerNATゲートウェイプライベートサブネット1NATゲートウェイ向け
インスタンス4SSM Session ManagerVPCエンドポイントプライベートサブネット2–

インスタンス1および2：インターネットゲートウェイ向けのルーティング設定

インスタンス1および2はインターネットに向かって通信します。
それぞれSSH・SSM Session Managerを使用してアクセスしますが、どちらの方法を使用する場合もインターネット向けに通信ができるように設定する必要があります。

インスタンス1およびインスタンス2のために、以下のリソースを定義します。

Resources:
  IGW:
    Type: AWS::EC2::InternetGateway

  IGWAttachment:
    Type: AWS::EC2::VPCGatewayAttachment
    Properties:
      VpcId: !Ref VPC1
      InternetGatewayId: !Ref IGW

  PublicSubnet:
    Type: AWS::EC2::Subnet
    Properties:
      CidrBlock: !Ref CidrIp1
      VpcId: !Ref VPC1
      AvailabilityZone: !Sub "${AWS::Region}${AvailabilityZone1}"

  PublicRouteTable:
    Type: AWS::EC2::RouteTable
    Properties:
      VpcId: !Ref VPC1

  RouteToInternet:
    Type: AWS::EC2::Route
    Properties:
      RouteTableId: !Ref PublicRouteTable
      DestinationCidrBlock: 0.0.0.0/0
      GatewayId: !Ref IGW

  PublicSubnetRouteTableAssociation:
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      SubnetId: !Ref PublicSubnet
      RouteTableId: !Ref PublicRouteTable
Code language: YAML (yaml)

まずパブリックサブネットとインターネットゲートウェイを定義します。
そしてパブリックサブネット用のルートテーブルを用意し、同ゲートウェイ向けのデフォルトルートを作成します。
デフォルトルートはDestinationCidrBlockプロパティに「0.0.0.0/0」を指定することで作成できます。

これらのリソースを作成することによって、インスタンス1および2がインターネット向けに通信できるようになります。

インスタンス3：NATゲートウェイ向けのルーティング設定

NATゲートウェイを経由する場合もルーティングについて考慮する必要があります。
一般にNATゲートウェイの使用方法は、プライベートサブネット内に設置されているインスタンスがインターネットにアクセスできるようにするために使用します。
まさにインスタンス3のような構成ということです。

インスタンス3のために、以下のリソースを定義します。

Resources:
  EIP:
    Type: AWS::EC2::EIP
    Properties:
      Domain: vpc

  NATGateway:
    Type: AWS::EC2::NatGateway
    Properties:
      AllocationId: !GetAtt EIP.AllocationId
      SubnetId: !Ref PublicSubnet

  PrivateSubnet1:
    Type: AWS::EC2::Subnet
    Properties:
      CidrBlock: !Ref CidrIp2
      VpcId: !Ref VPC1
      AvailabilityZone: !Sub "${AWS::Region}${AvailabilityZone1}"

  PrivateSubnet1RouteTable:
    Type: AWS::EC2::RouteTable
    Properties:
      VpcId: !Ref VPC1

  RouteToNATGateway:
    Type: AWS::EC2::Route
    Properties:
      RouteTableId: !Ref PrivateSubnet1RouteTable
      DestinationCidrBlock: 0.0.0.0/0
      NatGatewayId: !Ref NATGateway

  PrivateRoute1TableAssociation:
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      SubnetId: !Ref PrivateSubnet1
      RouteTableId: !Ref PrivateSubnet1RouteTable
Code language: YAML (yaml)

ポイントは2つです。

1点目はNATゲートウェイはパブリックサブネットに配置します。
NATゲートウェイにはElastic IPを設定し、インターネットアクセス用のパブリックアドレスを固定化します。

2点目はプライベートサブネット1用のルートテーブルを作成し、このテーブルにNATゲートウェイ向けのルートを設定します。

このようにリソースを作成することによって、プライベートサブネット1内のインスタンス3からのSSM通信は、NATゲートウェイへルーティングされるようになります。
そして前項で確認した通り、パブリックサブネットにはインターネットゲートウェイ向けのルーティングが設定されています。
ですからSSM通信はインターネットに抜けて、最終的にSSMまで到達することができるようになります。

インスタンス4：SSM Session Managerを使用するためには、3つのVPCエンドポイントを作成する

前項ではプライベートサブネット内のインスタンスがSSM通信を行うために、NATゲートウェイを使用する方法を確認しました。
もう1つの方法はVPCエンドポイントを使用する方法です。
こちらの場合、インターネットを経由することなくSSM通信が可能です。

インスタンス4のためにプライベートサブネット2を定義します。

Resources:
  PrivateSubnet2:
    Type: AWS::EC2::Subnet
    Properties:
      CidrBlock: !Ref CidrIp3
      VpcId: !Ref VPC2
      AvailabilityZone: !Sub "${AWS::Region}${AvailabilityZone2}"
Code language: YAML (yaml)

ルーティングに関する設定は行いません。
インスタンス4は以下のVPCエンドポイントを経由してSSMにアクセスするため、インターネットゲートウェイ等を使用しないためです。

以下がVPCエンドポイントです。

Resources:
  SSMEndpoint:
    Type: AWS::EC2::VPCEndpoint
    Properties:
      PrivateDnsEnabled: true
      SecurityGroupIds:
        - !Ref EndpointSecurityGroup
      ServiceName: !Sub "com.amazonaws.${AWS::Region}.ssm"
      SubnetIds:
        - !Ref PrivateSubnet
      VpcEndpointType: Interface
      VpcId: !Ref VPC2

  EC2MessagesEndpoint:
    Type: AWS::EC2::VPCEndpoint
    Properties:
      PrivateDnsEnabled: true
      SecurityGroupIds:
        - !Ref EndpointSecurityGroup
      ServiceName: !Sub "com.amazonaws.${AWS::Region}.ec2messages"
      SubnetIds:
        - !Ref PrivateSubnet
      VpcEndpointType: Interface
      VpcId: !Ref VPC2

  SSMMessagesEndpoint:
    Type: AWS::EC2::VPCEndpoint
    Properties:
      PrivateDnsEnabled: true
      SecurityGroupIds:
        - !Ref EndpointSecurityGroup
      ServiceName: !Sub "com.amazonaws.${AWS::Region}.ssmmessages"
      SubnetIds:
        - !Ref PrivateSubnet
      VpcEndpointType: Interface
      VpcId: !Ref VPC2
Code language: YAML (yaml)

ポイントは4点です。

1点目はSSM Session Managerを使用するためには、3種類のVPCエンドポイントを作成する必要があります。
SSM Session Managerを使用してEC2インスタンスにアクセスするために必要なサービスは以下の3つです。

com.amazonaws.[region].ssm
com.amazonaws.[region].ec2messages
com.amazonaws.[region].ssmmessages

Systems Manager を使用してインターネットアクセスなしでプライベート EC2 インスタンスを管理できるように、VPC エンドポイントを作成するにはどうすればよいですか?

ServiceNameプロパティに各サービス名を指定します。

2点目はVPCエンドポイントのタイプです。
VpcEndpointTypeプロパティに「Interface」を指定して、インターフェースタイプを選択します。

インターフェイスエンドポイントは、サブネットの IP アドレス範囲のプライベート IP アドレスを持つ Elastic Network Interface です。サポートされている AWS のサービスまたは VPC エンドポイントサービスへのトラフィックのエントリポイントとして機能します。インターフェイスエンドポイントは を使用します AWS PrivateLink

VPC エンドポイント

VPCエンドポイントにはゲートウェイタイプも存在しますが、対象のサービスが限定されています。

ゲートウェイエンドポイントは、次のサポートされている AWS のサービスを対象としています。

Amazon S3
DynamoDB

VPC エンドポイント

3点目はセキュリティグループです。
SecurityGroupIdsプロパティに先述のVPCエンドポイント用のセキュリティグループを指定します。
これでインスタンス4からのHTTPS通信(443/tcp)を受け付けることができるようになります。

4点目はプライベートDNSです。
PrivateDnsEnabledプロパティに「true」を指定して、プライベートDNSを有効化します。

AWS のサービスおよび AWS Marketplace パートナーサービス用に作成されたエンドポイントに対しては、プライベート DNS がデフォルトで有効になります。

インターフェイス VPC エンドポイント ( AWS PrivateLink )

加えてVPC側でもプライベートDNS機能を有効化する必要があります。
以下の通りにVPCを設定します。

Resources:
  VPC2:
    Type: AWS::EC2::VPC
    Properties:
      CidrBlock: !Ref VPCCidrBlock
      EnableDnsHostnames: true
      EnableDnsSupport: true
Code language: YAML (yaml)

VPCエンドポイントを設置する場合、VPCで2つのパラメータを設定する必要があります。

インターフェイス VPC エンドポイント ( AWS PrivateLink ) でプライベート DNS を使用する場合は、enableDnsHostnames 属性と enableDnsSupport 属性の両方を true に設定する必要があります。

VPC 内の DNS 属性

上記に従い、2プロパティに「true」を設定します。

EC2設定

EC2インスタンスの設定において、今回ポイントとなる点は4つです。

1つ目はセキュリティグループです。
これは前項で確認したため割愛します。

2つ目はアドレスです。
インターネット向けに通信させるためにインスタンスをパブリックサブネットに配置する場合、インスタンスにパブリックアドレスを設定する必要があります。
逆にプライベートサブネットに配置するインスタンスであれば、パブリックアドレスは不要です。

3つ目はIAMロールです。
SSM Session Managerを使用するためには、IAMロールを関連付けてインスタンスに複数のSSMアクションを許可する必要があります。
必要なアクションはAWS管理ポリシー(AmazonSSMManagedInstanceCore)という形でまとめられており、作成するIAMロールにこれをアタッチします。

4つ目はキーペアです。
SSHを使用する場合は、キーペアの設定が必要です。

キーペアには、プライベートキーと公開キーを含んでおり、 Amazon EC2 インスタンスへの接続時の身分証明に使用する、セキュリティ認証情報のセットを構成しています。

Amazon EC2 のキーペアと Linux インスタンス

以下が各インスタンスの設定をまとめた表です。

インスタンス方法配置するサブネットアドレスIAMロールにアタッチするポリシーキーペア
インスタンス1SSHパブリックサブネットパブリックアドレス–設定する
インスタンス2SSM Session ManagerパブリックサブネットパブリックアドレスSSM用AWS管理ポリシー–
インスタンス3SSM Session Managerプライベートサブネット1プライベートアドレスSSM用AWS管理ポリシー–
インスタンス4SSM Session Managerプライベートサブネット2プライベートアドレスSSM用AWS管理ポリシー–

インスタンス1：パブリックアドレスを設定し、キーペアとセキュリティグループでSSHを許可する

Resources:
  Instance1:
    Type: AWS::EC2::Instance
    Properties:
      ImageId: !Ref ImageId
      InstanceType: !Ref InstanceType
      KeyName: !Ref KeyName
      NetworkInterfaces:
        - AssociatePublicIpAddress: true
          DeviceIndex: 0
          SubnetId: !Ref PublicSubnet
          GroupSet:
            - !Ref InstanceSecurityGroup1
Code language: YAML (yaml)

インスタンス1はパブリックサブネットに配置してインターネット向けに通信します。
ですからパブリックアドレスが必要になりますが、AssociatePublicIpAddressプロパティに「true」を指定することで、同アドレスが設定されます。

インスタンス1用のセキュリティグループを使用します。
これはインターネットからのSSH(22/tcp)を許可するものです。

キーペアを設定します。
今回は「MyKeyPair」という名前のキーペアを作成しているものとして記載しています。
キーペアの作成に関しては以下のページをご確認ください。

https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/cli-services-ec2-keypairs.html

インスタンス2：パブリックアドレスを設定して、IAMロールでSession Managerを許可する

Resources:
  Instance2:
    Type: AWS::EC2::Instance
    Properties:
      IamInstanceProfile: !Ref InstanceProfile
      ImageId: !Ref ImageId
      InstanceType: !Ref InstanceType
      NetworkInterfaces:
        - AssociatePublicIpAddress: true
          DeviceIndex: 0
          SubnetId: !Ref PublicSubnet
          GroupSet:
            - !Ref InstanceSecurityGroup2

  InstanceProfile:
    Type: AWS::IAM::InstanceProfile
    Properties:
      Path: /
      Roles:
        - !Ref InstanceRole

  InstanceRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Version: 2012-10-17
        Statement:
          - Effect: Allow
            Action: sts:AssumeRole
            Principal:
              Service:
                - ec2.amazonaws.com
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
Code language: YAML (yaml)

インスタンス2もパブリックサブネットに配置してインターネット向けに通信するため、パブリックサブネットを設定します。

インスタンス2用のセキュリティグループでは、全インバウンド通信を許可していません。

IamInstanceProfileプロパティでIAMロールを関連づけます。
今回関連付けるIAMロールには、AWS管理ポリシーAmazonSSMManagedInstanceCoreをアタッチしています。
これをアタッチすることでSSM Session Managerを実行するために必要なアクションが許可されます。

なおSSM Session Managerを実行するためのもう1つの条件として、インスタンスにSSMエージェントがインストールする必要があります。
ただし今回使用しているAmazon Linux 2023のように、Amazon Linux 系のインスタンスでは、デフォルトで同エージェントがインストールされているため、追加の対応は不要です。

https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/sysman-manual-agent-install.html

インスタンス3および4：パブリックアドレスは不要

Resources:
  Instance3:
    Type: AWS::EC2::Instance
    Properties:
      IamInstanceProfile: !Ref InstanceProfile
      ImageId: !Ref ImageId
      InstanceType: !Ref InstanceType
      NetworkInterfaces:
        - DeviceIndex: 0
          SubnetId: !Ref PrivateSubnet1
          GroupSet:
            - !Ref InstanceSecurityGroup2

  Instance4:
    Type: AWS::EC2::Instance
    Properties:
      IamInstanceProfile: !Ref InstanceProfile
      ImageId: !Ref ImageId
      InstanceType: !Ref InstanceType
      NetworkInterfaces:
        - DeviceIndex: 0
          SubnetId: !Ref PrivateSubnet2
          GroupSet:
            - !Ref InstanceSecurityGroup3
Code language: YAML (yaml)

2つのインスタンスは概ね共通しています。
どちらも先述のIAMロールを関連づけますし、どちらもプライベートサブネットに配置するため、パブリックアドレスは設定しません。

異なる点は設置するプライベートサブネットです。
インスタンス3はプライベートサブネット1に配置しますから、NATゲートウェイを経由してインターネット面からSSMと通信します。
対してインスタンス4はプライベートサブネット2に配置しますから、VPCエンドポイントを経由してSSMと通信します。
つまりSSMと通信する過程でインターネットを中継するかどうかが大きく異なります。

環境構築

CloudFormationを使用して、本環境を構築し、実際の挙動を確認します。

CloudFormationスタックを作成し、スタック内のリソースを確認する

CloudFormationスタックを作成します。
スタックの作成および各スタックの確認方法については、以下のページをご確認ください。

あわせて読みたい
CloudFormationのネストされたスタックで環境を構築する 【CloudFormationのネストされたスタックで環境を構築する方法】 CloudFormationにおけるネストされたスタックを検証します。 CloudFormationでは、スタックをネストす...

AWS Management Consoleから各リソースを確認します。

セキュリティグループ

インスタンス1
Detail of VPC 01.

全アドレスからのSSHを許可する設定です。

インスタンス2および3
Detail of VPC 02

インバウンド通信を許可していません。
SSM Session Managerを使用する上で、インバウンド通信が発生しないためです。

インスタンス4およびVPCエンドポイント
Detail of VPC 03

インスタンス4用セキュリティグループを見ると、やはりインバウンド通信を許可していません。

Detail of VPC 04

VPCエンドポイント用のセキュリティグループを見ると、送信元を先述のセキュリティグループとしてHTTPS(443/tcp)を許可しています。

ルーティング

パブリックサブネット
Detail of VPC 05

パブリックサブネットに紐づくルートテーブルを見ると、インターネットゲートウェイ向けにデフォルトルートが設定されていることがわかります。
つまりVPCで使用しているCIDR(10.0.0.0/16)以外のアドレス帯への通信はインターネットへルーティングされます。
このことからパブリックサブネットに配置されているインスタンス1および2、そしてNATゲートウェイはインターネット向けの通信が行うことができます。

プライベートサブネット1
Detail of VPC 06

同様にプライベートサブネット1のルートテーブルを見ると、NATゲートウェイ向けにデフォルトルートが設定されていることがわかります。
つまりVPC外のアドレス帯への通信はNATゲートウェイにルーティングされます。
先ほどのパブリックサブネットのルーティング設定と組み合わせることで、インスタンス3はインターネット向けに通信を行うことができます。

プライベートサブネット2
Detail of VPC 07

そしてプライベートサブネット2のルートテーブルを見ると、デフォルトルートが設定されていないことが分かります。
このサブネット内のEC2インスタンス4はVPCエンドポイント経由でSSMにアクセスするため、ルーティング設定が不要なためです。

VPCエンドポイント

Detail of VPC 08
Detail of VPC 09
Detail of VPC 10

3種類のVPCエンドポイントが作成されています。
サブネット情報を見ると、プライベートサブネット2のアドレスが付与されています。
ですからVPC2内のEC2インスタンス4は、同エンドポイントを経由してSSMにアクセスすることができるようになります。

EC2インスタンス

インスタンス1
Detail of VPC 11

パブリックアドレスとキーペアが設定されています。
これらの設定はインスタンス1にインターネット越しにSSHでアクセスするためです。

インスタンス2
Detail of VPC 12

パブリックアドレスが設定されているのに対して、キーペアは設定されていません。
これらはインススタンス2にインターネット越しにSSM Session Managerでアクセスするためです。

インスタンス3
Detail of VPC 13

パブリックアドレスが設定されていません。
インスタンス3はプライベートサブネット1に配置されており、NATゲートウェイを経由してSSMにアクセスするため、パブリックアドレスが不要だからです。

インスタンス4
Detail of VPC 14

こちらもパブリックアドレスが設定されていません。
インスタンス4はプライベートサブネット2に配置されており、VPCエンドポイントを経由してSSMにアクセスするため、パブリックアドレスが不要だからです。

動作確認

インスタンス1

インスタンス1へのアクセスはSSHを使用します。

$ ssh -i MyKeyPair.pem ec2-54-238-222-53.ap-northeast-1.compute.amazonaws.com
...
   ,     #_
   ~\_  ####_        Amazon Linux 2023
  ~~  \_#####\
  ~~     \###|
  ~~       \#/ ___   https://aws.amazon.com/linux/amazon-linux-2023
   ~~       V~' '->
    ~~~         /
      ~~._.   _/
         _/ _/
       _/m/'
[ec2-user@ip-10-0-1-16 ~]$ 
Code language: Bash (bash)

キーペアを指定することで、インスタンス1にアクセスすることができました。

試しにパブリックアドレスを確認後、インターネット向けに通信を行います。

[ec2-user@ip-10-0-1-16 ~]$ ec2-metadata --public-ipv4
public-ipv4: 54.238.222.53

[ec2-user@ip-10-0-1-16 ~]$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=112 time=1.24 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=112 time=1.22 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=112 time=1.21 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=112 time=1.19 ms
^C
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 1.194/1.214/1.239/0.016 ms
Code language: Bash (bash)

パブリックアドレスが付与されており、インターネットへのアクセスも確認できました。
このようにSSHを使用する場合は、セキュリティグループでSSHを許可した上で、パブリックアドレスの付与やルーティング設定、加えてキーペアの設定・管理を行う必要があります。

インスタンス2

インスタンス2へのアクセスはSSM Session Managerを使用します。

$ aws ssm start-session --target i-0456a149fdc9a185a
...
sh-5.2$
Code language: Bash (bash)

確かにインスタンス2へアクセスすることができました。

試しにパブリックアドレスを確認後、インターネット向けに通信を行います。

sh-5.2$ ec2-metadata --public-ipv4
public-ipv4: 54.250.118.93

sh-5.2$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=2.02 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=117 time=2.04 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=117 time=2.04 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=117 time=2.05 ms
^C
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 2.022/2.038/2.049/0.010 ms
Code language: Bash (bash)

パブリックアドレスが付与されており、インターネットへのアクセスも確認できました。
インスタンス2のようにパブリックサブネットに配置されているインスタンスの場合は、SSM Session Managerを使用するために、セキュリティグループで特定のインバウンド通信を許可する必要はありませんが、パブリックアドレスの付与やルーティング設定が必要になります。

インスタンス3

インスタンス3へのアクセスはSSM Session Managerを使用します。

$ aws ssm start-session --target i-07764dec3ebaa7723
...
sh-5.2$
Code language: Bash (bash)

確かにインスタンス3へアクセスすることができました。

試しにパブリックアドレスを確認後、インターネット向けに通信を行います。

sh-5.2$ ec2-metadata --public-ipv4
public-ipv4: not available

sh-5.2$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=113 time=2.70 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=113 time=2.18 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=113 time=2.17 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=113 time=2.16 ms
^C
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 2.161/2.302/2.702/0.231 ms
Code language: Bash (bash)

パブリックアドレスは付与されていませんが、インターネットへのアクセスも確認できました。
これはNATゲートウェイを経由してインターネットにアクセスしているためです。
インスタンス3のようにプライベートサブネットに配置されているインスタンスの場合は、SSM Session Managerを使用するために、パブリックサブネットにNATゲートウェイを配置し、適切にルーティング設定をすることによって、セキュリティグループによる特定のインバウンド通信の許可や、パブリックアドレスの付与が不要となります。

インスタンス4

インスタンス4へのアクセスはSSM Session Managerを使用します。

$ aws ssm start-session --target i-048d60ca236073a63
...
sh-5.2$
Code language: Bash (bash)

確かにインスタンス4へアクセスすることができました。

試しにパブリックアドレスを確認後、インターネット向けに通信を行います。

sh-5.2$ ec2-metadata --public-ipv4
public-ipv4: not available

sh-5.2$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
^C
--- 8.8.8.8 ping statistics ---
8 packets transmitted, 0 received, 100% packet loss, time 7280ms
Code language: Bash (bash)

パブリックアドレスは付与されておらず、インターネットへのアクセスも不可でした。
これはインスタンス4がVPCエンドポイント経由でSSMにアクセスしており、インターネットへのアクセスする経路がないためです。
インスタンス4のようにプライベートサブネットに配置されているインスタンスの場合は、SSM Session Managerを使用するために、VPCエンドポイントを設定することによって、セキュリティグループによる特定のインバウンド通信の許可や、パブリックアドレスの付与が不要となります。

まとめ

今回はSSM Session Managerを使用してEC2インスタンスにアクセスする3パターンをご紹介しました。

  • インターネット経由でSSM Session Managerを使用してアクセス
  • NATゲートウェイ経由でSSM Session Managerを使用してアクセス
  • VPCエンドポイント経由でSSM Session Managerを使用してアクセス

SSM Session ManagerとSSHを比較すると、ポート解放やキーペア設定が不要となります。
SSM Session Managerを使用することで、インスタンスに不正にアクセスされるリスクを低減することができますし、インスタンスの管理工数の軽減にも繋がるでしょう。

AWS
EC2(Linux) SSM Session Manager