SSHのない世界へ：System ManagerでプライベートサブネットにあるEC2インスタンスに踏台サーバを使わずにログイン

# 目次

1. [SSHキーペア方式の問題点](#1-sshキーペア方式の問題点)
1. [目標](#2-目標)
1. [事前準備](#3-事前準備)
   1. [SSMエージェントのインストール](#31-ssmエージェントのインストール)
   1. [IAMロールの準備](#32-iamロールの準備)
1. [Systems ManagerのSession ManagerでEC2へ接続](#4-systems-managerのsession-managerでec2へ接続)
   1. [EC2のマネジメントコンソールから接続](#41-ec2のマネジメントコンソールから接続)
   1. [Systems Managerのコンソール画面から接続](#42-systems-managerのコンソール画面から接続)
   1. [ローカルPCでAWS CLIから接続](#43-ローカルpcでaws-cliから接続)
1. [構成パターン](#5-構成パターン)
   1. [パブリックサブネットにあるEC2に接続するパターン](#51-パブリックサブネットにあるec2に接続するパターン)
   1. [プライベートサブネットにあるEC2に接続するパターン（NAT Gatewayなし）](#52-プライベートサブネットにあるec2に接続するパターンnat-gatewayなし)
1. [SSH key pairとSession Managerの比較](#6-ssh-key-pairとsession-managerの比較)

# 1. SSHキーペア方式の問題点

普段、AWS EC2にはどのようにログインし、管理しているのでしょうか。おそらく多くの方がSSH key pair方式を利用しているのではないでしょうか。しかし、SSH key pair方式には多くのデメリットがあります。

1. セキュリティリスク:
   - EC2のセキュリティグループのインバウンドでSSH用22番ポートを開く必要があり、攻撃対象となる可能性が高まる。
     - 標準の22番ポートから別のポートに変更したり、特定のIPアドレスからのアクセスのみを許可したり、SSHアクセスをVPN経由に限定したりするなど、いくつかの対策があります。これらによってリスクをある程度緩和できますが、運用が複雑になるのは避けられません。
   - 秘密鍵の漏洩リスクがあり、漏洩した場合の影響が大きい。
     - 多数のサーバーに分散したキーを特定し、削除するのが難しい。
     - 退職者のキーが完全に削除されず、不正アクセスの可能性が残る。<font color="red">メンバーが退職した際に、新たにプライベートキーを作成し、残っているメンバー全員に配布し直し、さらにすべてのEC2インスタンスの公開鍵を更新するという作業は、現実的にはほぼ不可能</font>

1. 細かなアクセス制御が困難：
   - 粒度の低い制御：
     - EC2インスタンスの一般的な利用方法では、個別のOSユーザーを作成せず、<font color="red">全ユーザーが同じOSユーザー（例：`ec2-user`）でSSHログインすることが多い</font>
     - <font color="red">基本的には全ユーザーが同じキーペアを利用</font>
     - <font color="red">キーペアは通常、全てか無しの権限しか提供せず、特定の操作や時間帯に限定した制御が難しい</font>。
   - 動的な権限変更の困難さ：一度付与した権限を動的に変更したり、一時的に制限することが容易ではない。

1. 踏み台サーバーが必要な場合がある：
   - 複雑なネットワーク構成：多層のネットワークでは、プライベートサブネット内のEC2インスタンスに接続する場合、踏み台が必要。
   - セキュリティリスクの増大：踏み台サーバー自体が攻撃対象となり、追加のセキュリティ対策が必要。
   - 運用コストの増加：踏み台サーバーの管理・監視・更新に追加のリソースが必要。

1. 監査とコンプライアンス
   - セッションの記録や監査が困難：
     - アクティビティの可視性不足：<font color="red">SSH接続中の具体的な操作内容を記録・監視することが標準では困難</font>
     - アクセス履歴の不完全性：<font color="red">誰がいつどのサーバーにアクセスしたかの完全な記録を維持するのが難しい</font>
       - .historyファイルは実行されたコマンドのみを記録し、コマンドの出力や対話的なセッションの詳細は記録しません。
       - ユーザーが自身の`.history`ファイルを編集したり削除したりすることが可能です。
       - `.history`ファイルはセッション終了時に更新されるため、リアルタイムでの監視ができません。
       - タイムスタンプ、接続元IPアドレス、セッション時間などの重要な情報が記録されません。

# 2. 目標

<font color="red">SSHからの脱却</font>を図り、SSHキーペアを使用したEC2へのログイン方法を完全に廃止し、`AWS System Manager`の`Session Manager`を活用してEC2インスタンスにアクセスする運用体制へ移行する。これにより、以下のような利点を持つ新しい運用環境の実現を目指す。

- セキュアな接続の確立
- インバウンドポートの開放が不要
- SSHキーの管理が不要
- 踏み台サーバーなくてもプライベートサブネット内のインスタンスにもアクセス可能
- パブリックIPアドレスの管理が不要
- 監査可能な詳細なログ記録の実現
- IAMポリシーを使用して、誰がどのインスタンスにアクセスできるかを詳細に制御可能

この移行により、セキュリティの向上と運用負荷の軽減を同時に達成し、より効率的で安全なインフラ管理を実現する。

- SSHある世界

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/71737984-8328-3bea-68cc-dca0b0a606d1.png)

https://qiita.com/dennis_wang/items/3173f1fe33e40c190f97

- SSHない世界

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/5d2516b5-33be-ab68-f027-a816183d27d3.png)

# 3. 事前準備
## 3.1 SSMエージェントのインストール
- EC2に`Session Manager`経由で接続するには、EC2側にSSMエージェントの準備と、EC2から`Session Manager`への通信を許可するIAMロールの設定が必要です。
- EC2インスタンスにインストールされたSSMエージェントが`Session Manager`と連携し、SSMエージェントから`Session Manager`への接続を確立します。これにより、`Session Manager`側からEC2を管理・接続できるようになります。
- <font color="red">AWSが提供する比較的新しいマシンイメージ（AMI）を使用している場合、SSMエージェントはすでに実装済みなので、手動でSSMエージェントをインストールする必要がありません。</font>
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/0fde8115-2a11-c297-d913-36a3aaf1ed75.png)

## 3.2 IAMロールの準備
EC2インスタンスから`Session Manager`への通信を可能にするため、EC2インスタンスにIAMロールを付与し、`Session Manager`への接続を許可する必要があります。
AWSが事前に用意しているIAMポリシー`AmazonSSMManagedInstanceCore`には、`Session Manager`に必要な権限が含まれています。このポリシーを使用してIAMロールを作成し、作成したロールをEC2インスタンスにアタッチします。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/89d22cf4-2223-c827-2123-2fe67438874a.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/c090ffb8-deee-fd89-4054-127a717eada7.png)

# 4. `Systems Manager`の`Session Manager`でEC2へ接続

先にEC2のネットワーク構成的に`Session Manager`に接続できる状態になっている前提で進めます。

## 4.1 EC2のマネジメントコンソールから接続

1. EC2ダッシュボードより接続を行いたいEC2を選択し、`Connect`→`Session Manager`タブの`Connect`ボタンを押下
   ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/48ce2929-7447-bcec-1b5a-209d12c9b755.png)
   ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/ac96d55c-479a-9897-2471-680ec99bbebf.png)

2. 表示されているシェル画面に自由にコマンド実行

    ```
    sh-5.2$ exec /bin/bash
    [ssm-user@ip-10-0-20-223 bin]$ timestamp=$(date '+%Y-%m-%dT%H:%M:%SZ')
    [ssm-user@ip-10-0-20-223 bin]$ echo $timestamp
    2024-08-28T14:54:48Z
    ```
   実際の画面：
   ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/c62db77b-8ce9-3549-1b21-fb6fe959e37e.png)

## 4.2 Systems Managerのコンソール画面から接続
`Systems Manager`ダッシュボード画面の`Session Manage`→`Session`タブから`Start Session`で接続したいEC2を選択し、`Start session`を押下しても接続できます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/4b3d2c83-b81e-058c-c648-9cfba0cd59c7.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/8af64bf9-9bd2-707e-b61e-aa1a1100526b.png)

## 4.3 ローカルPCでAWS CLIから接続
ローカルPCから`Session Manager`で接続するためには`aws ssm start-session`コマンドで接続したいEC2のインスタンスIDを指定して実行することで`Session Manager`経由でEC2に接続することができます。

1. 先に[こちらのドキュメント](https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html)を参考し、必要な`Session Manager plugin`をインストール
   ```
   $ curl "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/mac_arm64/sessionmanager-bundle.zip" -o "sessionmanager-bundle.zip"
   $ unzip sessionmanager-bundle.zip
   $ sudo ./sessionmanager-bundle/install -i /usr/local/sessionmanagerplugin -b /usr/local/bin/session-manager-plugin
   $ session-manager-plugin --version
   1.2.650.0
   ```

2. `aws ssm start-session`コマンドでEC2に接続
   ```
   $ aws ssm start-session --target i-03dbcf6d7c0264b47
   
   Starting session with SessionId: Dan-6mcz4l2zzjq75pmidle6o3pcva
   sh-5.2$ exec /bin/bash
   [ssm-user@ip-10-0-20-223 bin]$ timestamp=$(date '+%Y-%m-%dT%H:%M:%SZ')
   [ssm-user@ip-10-0-20-223 bin]$ echo $timestamp
   2024-08-28T15:22:13Z
   ```

:::note info
`Session Manager`ですべての接続履歴確認が確認可能：
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/543d4058-17d8-2a45-2d33-b2ec00eb2125.png)
:::

# 5. 構成パターン
## 5.1 パブリックサブネットにあるEC2に接続するパターン
EC2が直接グローバルIPアドレスを持っているパブリックサブネットに所属している場合、EC2はインターネット経由で`Session Manager`と連携できるため、EC2でSSMエージェントが動作していれば特に何もせずとも`Session Manager`経由で接続可能です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/c86299e7-19b0-3288-cbe8-633bc6a8c8ab.png)

## 5.2 プライベートサブネットにあるEC2に接続するパターン（<font color="red">NAT Gatewayなし</font>）
インターネットに接続していないプライベートサブネット内のEC2インスタンスに接続する場合、EC2から`Session Manager`への接続経路がないため、そのままでは`Session Manager`と連携できません。そこで、`Session Manager`との接続を確立するための`VPCエンドポイント`を作成する必要があります。
VPCエンドポイントを作成することで、<font color="red">通常はAWSのグローバルネットワーク経由で行う`Session Manager`との接続を、内部のプライベートネットワークから直接確立</font>することが可能になります。
簡単に言えば、該当のプライベートネットワークに`Session Manager`サービスと直接接続する仮想ネットワークインターフェース（ENI）を作成することで、内部から`Session Manager`に接続できるようにします。

### 5.2.1 事前準備

https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/connect-to-an-amazon-ec2-instance-by-using-session-manager.html

https://qiita.com/hisato_imanishi/items/9993c86e02f5cbf4deae

1. ネットワークインターフェース（`ENI`）用セキュリティグループの作成
   - VPCエンドポイントを作成する前に、`ENI`用セキュリティグループを作成しておきます

    - インバウンドルールで以下を許容するルールを作成
        - タイプ：HTTPS(443) ⇒　`Session Manager`との通信は443ポートで行われるため
        - ソース：
            - プライベートサブネットのCIDRブロック：該当プライベートサブネット配下のすべてのECS2インスタンスがこのENIに対して送信可能
            - EC2インスタンスのセキュリティグループのID：このセキュリティグループがattachされているすべてのEC2インスタンスがこのENIにたいして送信可能
        - アウトバウンドではなくインバウンドの443ポートを指定する理由：
          - セキュリティグループを付与する対象は`ENI`であり、`ENI`から見た場合、`EC2`から`ENI`に入ってくる通信はインバウンドとなるため、インバウンドの許可設定が必要となります。
    ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/70b8c9aa-ad80-d13d-aed7-5f5a99a53c67.png)

    - アウトバウンドルール：デフォルトのまま（すべてのトラフィックを許可）
        - セキュリティグループはステートフルなので、許可されたインバウンドトラフィックに対する応答は自動的に許可されます。
    ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/eb87d2ec-c057-3b9e-4ae2-537f3d965be6.png)

2. VPCエンドポイントの作成

サービスとしては以下のサービスを指定する必要があり、まとめて選択するようなことはできないことから、最大で以下六個のVPCエンドポイントを作成します。
|サービス名|必須有無|説明|
|:--|:--|:--|
|`com.amazonaws.*region*.ec2messages`|必須|
|`com.amazonaws.*region*.ssm`|必須|
|`com.amazonaws.*region*.ssmmessages`|必須|
|`com.amazonaws.*region*.logs`|オプション|`CloudWatch Logs`へログ転送する場合に必要|
|`com.amazonaws.*region*.s3`|オプション|`S3`へログ転送する場合に必要|
|`com.amazonaws.*region*.kms`|オプション|`暗号化オプション`を使う場合に必要|

`VPC`エンドポイントの設定は以下のように設定:
|項目|設定|備考|
|:--|:--|:--|
|サービスカテゴリ|AWSのサービス||
|サービス|※上記のサービスを指定||
|VPC|※VPCエンドポイントを作成するVPCを指定||
|DNS名を有効化|チェック|DNSが有効でないと作成に失敗するため、指定する|
|サブネット|<font color="red">EC2が存在するプライベートサブネット</font>を指定||
|セキュリティグループ|session_manager_sg|先程作成したセキュリティグループを指定|

上記`VPC`エンドポイントを作成することで、`EC2`から`Session Manager`へ接続できるようになります。

`EC2`から`Session Manager`へ接続する際には`DNS`で内部に作られたENIのアドレスを問い合わせて`VPC`エンドポイント経由で接続することになるため、特にルーティング等は不要です。

今回は以下4つのエンドポイントに対して実施します。

- `com.amazonaws.ap-northeast-1.ssm`
- `com.amazonaws.ap-northeast-1.ec2messages`
- `com.amazonaws.ap-northeast-1.ssmmessages`
- `com.amazonaws.ap-northeast-1.s3`
  - エンドポイントのタイプとして`Gateway`と`Interface`が選択可能ですが、今回は`Gateway`を選択

まずは`com.amazonaws.region.ssm`のVPCエンドポイントを作成してみる
- サービスカテゴリの`AWS services` を選択、サービス名の検索ボックスに`ssm`と入力し、`com.amazonaws.ap-northeast-1.ssm`を選択
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/2f931bf8-9193-a56b-050f-62c7c947f481.png)

- エンドポイントを作成するVPCを選択
「プライベートDNS名を有効にする」オプションにチェックを入れます(デフォルトはチェック入っている)。これにより、<font color="red">標準のAWSのSSMエンドポイントがVPCエンドポイントにリダイレクト</font>されます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/6d69114c-d816-4ca6-41dc-4e1ece60d8d9.png)

- サブネット選択
    - エンドポイントを作成する<font color="red">プライベートサブネット</font>を選択します。
    - 複数のアベイラビリティーゾーンにまたがるサブネットを選択することをお勧めします。
    - 選択されるサブネットごとに新しい`ENI`が自動的に作成される

- セキュリティグループを選択：
先ほど作成したVPCエンドポイント用のセキュリティグループを選択
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/c828e0b3-d927-3a97-c5ea-bef9bf6b256c.png)

- 作られたVPCエンドポイントの一覧
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/14310881-5a7c-93a2-4f73-c6c06d76e2d3.png)

### 5.2.2 Systems ManagerのVPCエンドポイントでEC2にアクセスしてみる
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/5cb0928f-2513-84b4-145a-54dd34b3f7f0.png)
```
sh-5.2$ exec /bin/bash
[ssm-user@ip-10-0-30-163 bin]$ timestamp=$(date '+%Y-%m-%dT%H:%M:%SZ')
[ssm-user@ip-10-0-30-163 bin]$ echo $timestamp
2024-08-28T16:22:23Z
```

### 5.2.3 仕組みの解説

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/60997ad2-c36e-ddff-902b-9554132cc2ea.png)

1. インターフェースVPCエンドポイントの<font color="red">正体はENIだ</font>
    - インターフェース型エンドポイントは`Elastic Network Interface (ENI)` を介することで、<font color="red">インターネットを経由せずにAWSのプライベートネットワーク経由で直接AWSサービスにアクセスできる</font>
    - ENIは、物理的な環境における`Network Interface Card (NIC)`に相当します。VPC内のリソースとAWSサービス間の通信を仲介する役割を果たします。
    - インターフェース型エンドポイントを作成する時に、VPC内1つ以上の<font color="red">プライベートサブネットを選択</font>し、<font color="red">選択したサブネット上にそれぞれ`ENI`が作成</font>されます。
    生成されるENIのリスト：
    ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/ea332838-3558-0f8d-33db-f4f7df488f57.png)
    - ENIに<font color="red">プライベートIPアドレス</font>を割り当て、VPC内(プライベートサブネット内)からAWSのプライベートネットワーク経由で直接AWSサービスにアクセスできる
    ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/684d32c3-379c-acb5-b6e1-69ed71f05b23.png)

1. セキュリティ:
    - トラフィックは<font color="red">AWSのプライベートネットワーク内に留まる</font>ため、インターネットを経由しません。
    - <font color="red">ENIに対してセキュリティグループを使用</font>してアクセス制御が可能

1. DNS解決:
    - プライベートDNS名を使用してサービスにアクセス可能で、既存のアプリケーションの設定変更しなくても済む
    - インターフェースVPCエンドポイントには、主に以下の3種類のDNS名が存在：
        1. リージョンDNS名
           - エンドポイント全体を表し、関連するすべてのAZのIPアドレスに解決されます。
        1. <font color="red">AZごと</font>のDNS名
           - 特定のAZ内のエンドポイントのIPアドレスに解決されます。
        1. プライベートDNS名（オプション）
           - <font color="red">普通は`ssm.ap-northeast-1.amazonaws.com`のような標準のAWSサービスエンドポイント名はpublic IPに名前解決される</font>。
           - エンドポイントの作成時に「プライベートDNS名を有効にする」オプションを選択する場合は、<font color="red">標準のAWSサービスエンドポイント名がVPCエンドポイントのプライベートIPアドレス(つまり`ENI`のIP)に解決</font>されます。
           - この機能を使うためにはVPCでは`Enable DNS hostnames`と`Enable DNS resolution`が有効になっている必要があります。(VPC作成する時に、こちらの2つの項目はデフォルトではチェックされる)
    
    - これらのDNS名は、エンドポイントの作成時に自動的に生成され、<font color="red">AWS管理のプライベートホストゾーン</font>に登録され、<font color="red">ホストゾーンはユーザーには直接見えない</font>形で管理。
    - プライベートDNS名を有効にすると、<font color="red">VPC内のリソースは標準のAWSサービスエンドポイント名を使用してサービスにアクセスでき、アプリケーションの設定変更が不要になります</font>。
    - 一方、リージョナルDNS名とゾーナルDNS名は、より細かい制御やトラブルシューティングが必要な場合に使用されます。
    ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/cf29e89a-aab4-8e45-5d4c-79db67570cef.png)


1. DNS名を解決してみる： 

- private subnetにあるEC2に`System Manager`(`Session Manager`)経由でログインした上で以下のコマンドを実行
    - 3つのDNSとも同じ`10.0.30.93`(ENIのプライベートIP)に名前解決された。
    - 10.0.0.2#53経由で名前解決されていることが分かる
    ```
    # 1. リージョンDNS名
    $ nslookup vpce-0d4404df16ee7c94f-rptn23x5.ssm.ap-northeast-1.vpce.amazonaws.com
    Server:		10.0.0.2
    Address:	10.0.0.2#53
    
    Non-authoritative answer:
    Name:	vpce-0d4404df16ee7c94f-rptn23x5.ssm.ap-northeast-1.vpce.amazonaws.com
    Address: 10.0.30.93 ⇒ ENIのプライベートIPだ
    
    # 2. AZごとのDNS名
    $ nslookup vpce-0d4404df16ee7c94f-rptn23x5-ap-northeast-1a.ssm.ap-northeast-1.vpce.amazonaws.com
    Server:		10.0.0.2
    Address:	10.0.0.2#53
    
    Non-authoritative answer:
    Name:	vpce-0d4404df16ee7c94f-rptn23x5-ap-northeast-1a.ssm.ap-northeast-1.vpce.amazonaws.com
    Address: 10.0.30.93 ⇒ ENIのプライベートIPだ
    
    # 3. プライベートDNS名
    $ nslookup ssm.ap-northeast-1.amazonaws.com
    Server:		10.0.0.2
    Address:	10.0.0.2#53
    Non-authoritative answer:
    Name:	ssm.ap-northeast-1.amazonaws.com
    Address: 10.0.30.93 ⇒ ENIのプライベートIPだ
    ```
- DNS名前解決の流れ：
    ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/409d8ba5-9a1b-968d-4a26-12cf78775a49.png)
:::note info
- `Route 53 Resolver`（旧 `Amazon Provided DNS`）について：
    - <font color="red">VPC毎に存在</font>
    - VPC+2のIPアドレスでアクセス可能(VPCのCIDRが`10.0.0.0/16`の場合、<font color="red">`10.0.0.2`</font>でアクセス)![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/22e37bce-2418-2709-8539-dc8c4280f101.png)
:::


参考記事:

https://qiita.com/inoue_d/items/7495f90a95636cf4298e#%E3%82%A4%E3%83%B3%E3%82%BF%E3%83%BC%E3%83%95%E3%82%A7%E3%83%BC%E3%82%B9vpc%E3%82%A8%E3%83%B3%E3%83%89%E3%83%9D%E3%82%A4%E3%83%B3%E3%83%88%E3%81%AE%E6%AD%A3%E4%BD%93%E3%81%AF

https://dev.classmethod.jp/articles/amazon-s3-private-connectivity-on-premises-networks/

https://dev.classmethod.jp/articles/s3-privatelink-diagram/

https://zenn.dev/fdnsy/articles/1b4933f719f98f

https://blog.serverworks.co.jp/route53-nameresolution-features

### 5.2.4 VPNエンドポイントを利用する時に既存アプリケーションへの影響

1.  <font color="red">プライベートDNSを有効にすることで、既存のアプリケーションに対して修正を加える必要はありません</font>。
インターフェース型VPCエンドポイントを作成する際に、`プライベートDNS名を有効にする`オプションを選択します。このオプションを有効にすると、<font color="red">AWSサービスの公開エンドポイントのDNS名を使用しながら、VPCエンドポイント経由でプライベート接続を利用できる</font>ようになります。結果として、アプリケーションのコードを変更することなく、VPCエンドポイントを介してAWSサービスにアクセスすることが可能になります。
1.  AWSのSDKやCLIを使用している場合、デフォルトのエンドポイントを使用したままで(`--endpoint-url`を指定する必要はありません)、トラフィックは自動的にVPCエンドポイントを経由します。

    -  `--endpoint-url`指定せず、プライベートDNSを使用する方法
        ```
        aws ssm describe-sessions --state History
        ```
        ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/38408431-b14b-6258-520a-7a90e8aaa45d.png)

    -  `--endpoint-url`指定して、リージョンDNSを使用する方法
        ```
        aws ssm --endpoint-url https://vpce-0d4404df16ee7c94f-rptn23x5.ssm.ap-northeast-1.vpce.amazonaws.com  describe-sessions --state History
        ```
        結果的にはこちらでも問題なくSysterm Managerから情報取得できた。
        ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/28664/25090f85-dd19-b215-f532-89abf007732b.png)


# 6. SSH key pairとSession Managerの比較
| 項目 | SSH key pair | Systems Manager Session Manager |
|------|--------------|--------------------------------|
| セキュリティ | <font color="red">鍵の作成と管理が必要</font>、漏洩リスクあり | <font color="red">- 鍵の作成と管理不要<br>- IAMベースのアクセス制御<br> - IAM userやaccesskeyとsecret accesskeyの作成と配布が必要</font> |
| ネットワーク設定(security group) | <font color="red">インバウンドSSHポートの開放が必要</font> | <font color="red">インバウンドポートの開放不要</font> |
| 踏み台サーバー | - <font color="red">プライベートサブネットアクセス時に必要</font> <br> - 踏み台サーバー自体はpublic subnetに配置 | 不要 |
| アクセス制御 | 鍵の配布・管理で制御 | IAMポリシーで細かく制御可能 |
| 監査とログ | 限定的 | <font color="red">CloudTrail、CloudWatchと連携可能</font> |
| クライアントツール | 標準SSHクライアント | ・AWS CLI(Session Managerプラグイン)<br>・ブラウザベースのコンソールも利用可能 |
| プロトコル対応 | SSH、SCP、SFTP | 独自プロトコル（SSH対応も可能） |
| セットアップ複雑さ | 比較的シンプル | IAM、VPCエンドポイントの設定が必要 |
| 運用コスト | 鍵の管理コストが高い | 初期設定後の運用コストは低い |
| スケーラビリティ | 大規模環境での管理が困難 | 大規模環境でも一元管理が容易 |
| コンプライアンス | 鍵管理のポリシーが必要 | IAMポリシーで一元管理可能 |
| 多要素認証 | 追加設定が必要 | IAMと連携して容易に実装可能 |