API Gateway から WebSocket で EC2 インスタンス上の java サーブレットにリクエストを送る (AWS)

# はじめに
クライアントから WebSocket で送られてきたメッセージを API Gateway 経由で java サーブレット (jetty) に送る手順を残します。
java サーブレットでは、AWS SDK を使って受け取ったメッセージをそのままクライアントに返します。こちらも簡単に手順を残しておきます。

サーバ構成は下図のような感じです。

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/574196/5bde0ee5-2f5f-d2b9-cdc0-7b3913eabfcd.png" width=800px>

インスタンスに API Gateway からとインターネットゲートウェイからの両方でアクセスできるようになってますが、後者は開発端末からの ssh 接続用です。
とりあえず動かす、が目的だったので、踏み台サーバは立てずローカルから直接接続できる構成にしています。

記事中にちょくちょく「▶︎ メモ」が出てきますが、クリックすると開閉します。手順の補足となるキャプチャなどがしまってあります。

# 環境
- OS：macOS Mojava
- java バージョン：11.0.2

# EC2 インスタンスの作成
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/574196/c7e4cccb-e9b6-170d-2283-4d726374c288.png" width=600px>

まずはデフォルトサブネット内にインスタンスを作成します。
この時にセキュリティグループの設定を間違えると NLB やローカルから接続できないので要注意です。
上図のような構成にするには、次のように設定します。

- ネットワーク：デフォルト VPC
- サブネット：任意のデフォルトサブネット
- セキュリティグループ：下表のルールで新しいセキュリティグループを作成

| タイプ | プロトコル | ポート範囲 | ソース |
|:--|:--|:--|:--|
| SSH | TCP | 22 | マイ IP |
| カスタム TCP | TCP | 8080 | デフォルト VPC の CIDR |

1 つ目のルールで開発 PC からの ssh 接続を許可し、2 つ目のルールでこの後作成する NLB からのアクセスを許可します。

<details>
<summary>メモ</summary>
**メモ 1**
CIDR は VPCコンソールで確認できます。
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/574196/d992b827-153c-6342-3426-e8da1a3f0a44.png" width=600px>
<br/>
**メモ 2**
自作のサブネット内にインスタンスを作った場合、インターネットと接続するには別途 Elastic IP の設定が必要ですが、デフォルトサブネット内に作成する場合は不要です (VPC も自作の場合はさらにインターネットゲートウェイとルーティングテーブルの設定が必要)。
<br/>
**メモ 3**
セキュリティグループはファイアウォールのようなもので、作成は VPC 単位、適用はインスタンス単位です。なので、1 つのセキュリティグループを複数のインスタンスに適用できます。
<br/>
<font color="DarkGray">▲  メモ</font>
</details>

# NLB の作成
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/574196/c7e442e4-06c7-ce61-80ce-d4dc262e6399.png" width=600px>

クライアントからのリクエストを EC2 にルーティングするための設定を行います。
まずロードバランサー作成の最初の画面で、次のように入力します。

- スキーム：内部
- リスナー
    - ロードバランサーのプロトコル：TCP
    - ロードバランサーのポート：8080
- VPC：デフォルト VPC
- アベイラビリティゾーン：EC2 インスタンスが存在するアベイラビリティゾーン

<details>
<summary>メモ</summary>
**メモ 1**
アベイラビリティゾーンは VPC コンソールで確認できます。アベイラビリティゾーンはインスタンス作成時に直接は指定していませんが、サブネットが存在するアベイラビリティゾーンが間接的に設定されます。
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/574196/f9b7b715-364b-8af4-023a-74d407214d48.png" width=600px>
<br/>
**メモ 2**
スキームをインターネット向けに設定すると、NLB のを外部のリソースにルーティングさせることになります。
今回は VPC 内の EC2 をターゲットとして選択するので、スキーマは内部を選択します。
尚、インターネット向けの NLB で VPC リンク (後述) として登録しようとすると、警告が表示されます。
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/574196/f7f849b8-ea1d-1316-1ee2-a6fa0d15c431.png" width=600px>
<br/>
**メモ 3**
アベイラビリティゾーンの設定では、1 つのアベイラビリティゾーン内にあるデータセンターで障害が発生した場合に備えて複数のアベイラビリティゾーンを指定した方が良い…らしいですがそもそも EC2 が 1 つなので今回は 1 つだけ指定します。
<br/>
<font color="DarkGray">▲  メモ</font>
</details>

「ルーティングの設定」では、ルーティング先のターゲットの種類などを登録します。

- ターゲットグループ
    - ターゲットグループ：新しいターゲットグループ
        - 先ほど作成した EC2 インスタンス を登録する
    - ターゲットの種類：インスタンス
    - プロトコル：TCP
    - ポート：8080
- ヘルスチェック
    - プロトコル：TCP
    - (詳細設定) ポート：トラフィックポート

<details>
<summary>メモ</summary>
**メモ 1**
以上の設定で、NLB は以下のようなことを行います。
<br/>
1. 指定したターゲットグループに登録された全てのターゲットの状態をヘルスチェクに指定したプロトコル、ポートでモニタリング
2. リスナーで指定した TCP:8080 のリクエスト受付
3. 1 でチェックして正常だったターゲットにリクエストをルーティング
<br/>
**メモ 2**
NLB を作成しただけではターゲットグループのヘルスチェックは unhealthy となっていますが、インスタンス上でサーブレットを起動すると healthy になります。
<br/>
<font color="DarkGray">▲  メモ</font>
</details>

# WebSocket API の作成とデプロイ
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/574196/9235f910-758a-db98-9a5b-10171bc30198.png" width=600px>
テンプレート選択式を使った WebSocket API を作成し、デプロイします。
テンプレート選択式を使うと、クライアントからの情報をサーバで扱いやすい形式に変換してからサーバーに渡すことができます。

## API の作成
最初に、空の API を作成します。作成段階で \$connect、\$disconnect、\$default ルートキーが定義されていますが、全て空 (ルートがない) の状態です。
ルート選択式を「$request.body.action」として WebSocketAPI を作成します。

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/574196/3f477d5e-d29b-fa40-d458-a2b2b1869544.png" width=400px>

<details>
<summary>メモ</summary>
WebSocket 作成時、以下のような画面が表示されない場合は REST に一度チェックし、再度 WebSocket にチェックすると良いです。
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/574196/e7c330d2-adfe-8af7-ef64-8c1bc305a094.png" width=600px>
<font color="DarkGray">▲  メモ</font>
</details>

ルート選択式により、クライアントからの json リクエストボディの特定のプロパティの値を使って処理が振分けることができます。
「$request.body.action」であれば、action プロパティの値と一致するルートキーのルートへリクエストが送られます。その後さらにルートに紐づけられた Lambda 関数や VPC リンクなどへとリクエストが送られます。

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/574196/61aae58b-3562-4aeb-8734-c803a7d842b9.png" width=600px>

\$connect と \$disconnect は、ルート選択式で振分けられるのではなく、接続時、切断時のルートキーです。
\$default は action プロパティ値と一致するルートキーが無い場合やリクエストボディが json でなかった場合に呼び出されます。
今回は新しくルートキーは作成しないので、クライアントからメッセージが送られた場合は \$default に振分けられます。

## VPC リンクの作成
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/574196/101ae91a-bd17-101f-2362-f2d72c9a76f6.png" width=600px>

API Gateway と NLB を繋ぐ準備として、VPC リンクを作成します。

作成は、API Gateway コンソールで API を選択し、メニューの「VPC リンク」から行います。
名前を入力し、NLB を選択して「作成」をクリックします。
ステータスが「利用可能」となれば完了です (5 分程度かかる)。

<details>
<summary>メモ</summary>
VPC リンクは、API Gateway から VPC 内のリソース (今回であれば jettyサーバ) にアクセスする際の、API Gateway の接続先となるもので、実体はリソースにリクエストを振分けるよう設定されたロードバランサーです。
インターネットを経由せずに VPC の内外を繋ぐため、このような経路を作る必要があります。
(ということなのだと思っています。)
<br/>
<font color="DarkGray">▲  メモ</font>
</details>

## ルートの設定
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/574196/10c1d597-861d-8bf4-0ad7-ec1c9193c5d5.png" width=800px>

NLB への接続と任意の形式へのデータ変換を行うための設定をします。
今回クライアントからメッセージを送ると、\$default に振分けられるので、\$default ルートを設定します。

\$default ルートの統合リクエストに以下を入力して保存します。

- 統合タイプ：VPC リンク
- プロキシ統合の使用：チェックを外す
- VPC リンク：先ほど作成した VPC リンク
- HTTP メソッド：POST
- エンドポイント URL：http://(NLB の DNS 名):8080/(API パス)
- デフォルトタイムアウトの使用：チェックを入れる

統合タイプでクライアントからのリクエストを処理する先を指定しています。java サーブレットを直接設定することはできないので、java サーブレットがある EC2 インタンスへ振分け設定した NLB を登録した VPC リンクを設定します。これが API Gateway と NLB を繋ぐ設定にあたります。

<details>
<summary>メモ</summary>
**メモ 1**
エンドポイント URL の DNS 名は EC2 コンソールから確認できます。
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/574196/e799d94c-aa4b-8117-7bb7-b009b8058ed0.png" width=600px>
<br/>
**メモ 2**
\$connect のルートの設定はオプションなので無くても問題ありません。
\$disconnect はベストエフォート型 (最前は尽くすけど保証はしない) です。こちらもルートの設定が無くても問題ありません。
<br/>
**メモ 3**
プロキシ統合については正確には理解できていないのですが、リクエスト内の情報をバックエンドと連携するため、かつては自分で作成していたマッピングの定義を、API Gateway がいい感じにやってくれる、というもののようです。
今回はマッピングを自分で設定するのでチェックを外しています。
<br/>
**メモ 4**
統合タイプが Lambda であれば 1 ルートキーに対し 1 Lambda 関数を割当てて処理を振分けられますが、java サーブレットの場合はエンドポイント URL 末尾の API パスを使ってサーブレット内で処理を振分けます (他にも方法はあると思いますが)。
<br/>
<font color="DarkGray">▲  メモ</font>
</details>

リクエストテンプレート選択式の入力ができるようになるので、以下を入力して保存します。

- テンプレート選択式：\\\$default
- テンプレートキー：$default
- テンプレートの生成：以下のテンプレート選択式

```
{
  "connectionId": "$context.connectionId",
  "domainName": "$context.domainName",
  "stage": "$context.stage",
  "body": $input.json('$.body.body')
}
```

テンプレートキーを保存しようとすると忠告が表示されますが、「はい」で大丈夫です。
保存しても画面上で特に変化はありませんがちゃんと保存されています。

<details>
<summary>メモ</summary><div>
`"body"` に設定した `\$input.json('$.body.body')` には、クライアントからのリクエスト中の body プロパティの値が入ります。例えばクライアントから以下のようなメッセージが送られてきた場合、`"hello"` が入ります。<br/>

```
{
  "action": "actionName"
  "body": "hello"
}
```
<font color="DarkGray">▲  メモ</font>
</div></details>

## API のデプロイ

「アクション」で「API のデプロイ」を選択し、任意のステージを選ぶか作るかしてデプロイします。

デプロイすると Websocke URL が生成されます。URL の最後にはステージ名が入り、クライアントから API Gateway へのアクセスにはこの URL を使います。

以上で Websocket API の作成とデプロイは完了です。

<details>
<summary>メモ</summary>
(ひとやすみ)<br/>
<font color="DarkGray">▲  メモ</font>
</details>

# IAM ユーザの作成
クライアントに対してメッセージを送り返す際、java サーブレットでは、[AWS SDK for Java API](https://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/overview-summary.html) を使って API Gateway にリクエストを送信しています。
このリクエストを実行させるには、API Gateway へのアクセス権限を持ったユーザの認証情報が必要です。

以下の設定で新しいユーザーを作成します。

- アクセスの種類：「プログラムによるアクセス」にチェック
- ポリシー：既存のポリシー > AmazonAPiGatewayInvokeFullAccess をアタッチ

認証情報の CSV ファイルをダウンロードして保存します。
**認証情報は必ずダウンロードし、ファイルは安全な場所に保管してください**

取得した認証情報は、java のシステムプロパティに設定します (後述)。

<details>
<summary>メモ</summary>
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/574196/4b02bec9-5c89-32fd-57ea-3cdb6e243947.png" width=６00px>
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/574196/ec0f0c8e-14cc-995c-af9a-a2687519485b.png" width=600px>
<font color="DarkGray">▲  メモ</font>
</details>

# java サーブレットの実装
サーブレットには jetty、ビルドツールは maven を利用しています。
クライアントからのリクエストを処理して返す部分は下のような感じです (エラー処理や null チェックは全て省略しています)。
クライアントからのリクエストを Map に変換した後は、request.get("xxx") でリクエスト中の値を取得できます。
xxx には、API Gateway のテンプレートで設定したキー名が入ります。
IAM ユーザの認証情報を設定せずに実行しようとすると、クライアントへの送信で認証エラーが発生します。

```java:WebSocket.java

import java.util.Map;
import java.nio.ByteBuffer;
import java.nio.CharBuffer;
import java.nio.charset.Charset;
import java.nio.charset.CharsetEncoder;

import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

import org.codehaus.jackson.map.ObjectMapper;

import com.google.common.io.ByteStreams;

import com.amazonaws.client.builder.AwsClientBuilder.EndpointConfiguration;
import com.amazonaws.regions.Regions;
import com.amazonaws.services.apigatewaymanagementapi.AmazonApiGatewayManagementApi;
import com.amazonaws.services.apigatewaymanagementapi.AmazonApiGatewayManagementApiClientBuilder;
import com.amazonaws.services.apigatewaymanagementapi.model.PostToConnectionRequest;

public class WebSocket {

    /**
     * メイン
     */
    void sendMessage(ServletRequest request_){

        // クライアントからのリクエストを Map に変換
        Map<String, Object> request = parseRequest(request_);

        // API Gateway へリクエストを送るオブジェクトとリクエストデータの作成
        AmazonApiGatewayManagementApi client = createClient(request);
        PostToConnectionRequest postRequest = cratePostRequest(request);
        
        // クライアントへ送信
        client.postToConnection(postRequest);

    }

    /** 
     * クライアントからのリクエストを Map に変換 
     */
    void parseRequest(ServletRequest request_){
        HttpServletRequest request = (HttpServletRequest) request_;
        byte[] requestBodyAsBytes = ByteStreams.toByteArray(request.getInputStream());
        ObjectMapper objectMapper = new ObjectMapper();
        Map<String, Object> request = objectMapper.readValue(requestBodyAsBytes, Map.class);
    }

    /** 
     * API Gateway にリクエストを送るオブジェクト作成
     */
    AmazonApiGatewayManagementApi createClient(Map<String, Object> request) {

        String domainName = (String) request.get("domainName");
        String stage = (String) request.get("stage");

        EndpointConfiguration config = new EndpointConfiguration(
            "https://" + domainName + "/" + stage, Regions.AP_NORTHEAST_1.getName());
        return AmazonApiGatewayManagementApiClientBuilder.standard()
            .withEndpointConfiguration(config).build();
    }

    /**
     * API Gateway に送るリクエストの作成
     */
    private PostToConnectionRequest cratePostRequest(Map<String, Object> request){

        String connectionId = (String) request.get("connectionId");

        // メッセージをバイトデータに変換
        CharsetEncoder encoder = Charset.forName("UTF-8").newEncoder();
        String message = String.valueOf(request.get("body"));
        ByteBuffer buff = encoder.encode(CharBuffer.wrap(message));

        PostToConnectionRequest postRequest = new PostToConnectionRequest();
        // 送信先のコネクションを設定
        postRequest.setConnectionId(connectionId);
        // 送信するデータを設定
        postRequest.setData(buff);

        return postRequest;
    }
}
```

# 動作確認
## 準備
maven でビルドした後、EC2 インスタンスに war ファイルをコピー・展開します。

<details>
<summary>war ファイルを EC2 インスタンス上にコピー</summary><div>
`scp -i 秘密鍵のパス warファイルのパス ユーザ名@インスタンスのパブリックIPアドレス:インスタンス上のディレクトリ`<br/>
例<br/>
`scp -i ~/.ssh/ssh_key.pem ~/Project/target/websocket.war ec2-user@xx.xxx.xxx.xxx:/home/ec2-user`

- 秘密鍵：EC2 インスタンス作成の最後にダウンロードもしくは設定した秘密鍵
- ユーザ名：ec2-user (インスタンスイメージが Amazon Linux 2 の場合)
- インスタンス上のディレクトリ：war ファイルのコピー先ディレクトリを指定

インスタンスのパブリック IP の確認
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/574196/81e202c6-6288-413a-bb67-ca54c2644674.png" width=600px>
</div></details>
<details>
<summary>EC2 インスタンスに ssh でアクセス</summary>
秘密鍵、ユーザ名、パブリック IP アドレスについては先ほどと同じです。<br/>
`ssh -i 秘密鍵のパス ユーザ名@インスタンスのパブリックIPアドレス`
</details>
<details>
<summary>EC2 インスタンスに JDK、JRE (version 11) のインストール</summary>
Amazon Linux 2 に対応した OpenJDKディストリビューションが公開されているのでそちらをインストールします。<br/>
`sudo yum update`
`sudo yum install java-11-amazon-corretto`
</details>
<details>
<summary>コピーした war ファイルの展開</summary>
jar コマンドはカレントディレクトリにファイルを展開するので適当なディレクトリに移動してから実行。<br/>
`jar xvf warファイルのパス`
</details>

以上が完了したら、IAM ユーザの作成で取得した認証キーをシステムプロパティとして設定し、サーブレットを起動してください。

`-Daws.accessKeyId=XXXXXXXXXXXXXXXXXXXX`
`-Daws.secretKey=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx`

## 動作確認
動作確認には chrome の拡張機能 [Simple WebSocket Client](https://chrome.google.com/webstore/detail/simple-websocket-client/pfdhoblngboilpfeibdedpjgfnlcodoo) を使います。
または、[wscat](https://github.com/websockets/wscat) をインストールして使ってください。

Simple WebSocket Client で、API Gateway でデプロイした際にステージに設定された URL にアクセスします。
Status が OPEND となれば接続成功です。ここで接続できなければ、ネットワーク・セキュリティ周りの設定を見直してください。

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/574196/28ffe995-ee07-c68e-4436-1dccd74958b1.png" width=600px>

接続できたら、以下の内容を Request に入力して Send をクリックします。

`{"action":"default", "body":"hello"}`

以下のように body の内容がそのまま表示されれば成功です。
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/574196/9c67e0f7-b75e-d1b1-9a5b-e94ceb8958af.png" width=600px>

さて、今回は API Gateway でリクエスト内容をマッピングしてから EC2 リソースに送信する設定を行いました。そちらも確認します。
CloudWatch で API Gateway のログを見られるように設定するとマッピング後のリクエストが確認できます。

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/574196/b46d3cac-b274-93b9-e4ac-3c746c0f6dc3.png" width=600px>


## おまけ
今回は body の中に "hello" のみがマッピングされる設定になっていますが、テンプレートを少し変えれば他の内容をマッピングすることもできます。試しに、クライアントからの内容をそのままマッピングするようにしてみます。テンプレート選択式を以下のように変更・保存します。

```
{
  "connectionId" : "$context.connectionId",
  "domainName" : "$context.domainName",
  "stage" : "$context.stage",
  "body" : $input.body
}
```

デプロイして再接続後にメッセージを送ってみると、メッセージ全体が body の値として入ります。

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/574196/6f604ed2-ec6f-52b7-b7e2-e0ff37161dbd.png" width=600px>

クライアントもメッセージ全体が返ってくるようになります。

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/574196/64c06626-eb09-daff-744d-43d2ebd6af57.png" width=600px>

# お世話になった記事
ありがとうございました。

**EC2 インスタンスの作成**

- [Amazon VPC のしくみ - インターネットにアクセスする](https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/how-it-works.html#what-is-connectivity)
- [Amazon EC2 Linux インスタンスの開始方法](https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/EC2_GetStarted.html)
- [セキュリティグループのルールのリファレンス - Elastic Load Balancing ルール](https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/security-group-rules-reference.html#sg-rules-elb)
- [ロードバランサーにセキュリティグループをアタッチする方法を教えてください。](https://aws.amazon.com/jp/premiumsupport/knowledge-center/security-group-load-balancer/)

**NLB の作成**

- [Elastic Load Balancing の詳細 - ロードバランサーのスキーム](https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html#load-balancer-scheme)
- [Network Load Balancer のリスナー](https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/network/load-balancer-listeners.html)
- [Network Load Balancer のターゲットグループ](https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/network/load-balancer-target-groups.html)
- [Application Load Balancerで設定する4種類のポート番号の意味を理解しよう](https://dev.classmethod.jp/cloud/aws/aws-alb-port/)

**WebSocket API の作成とデプロイ**

- [API Gateway で WebSocket API 統合リクエストを設定する](https://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/apigateway-websocket-api-integration-requests.html)
- [接続されたユーザーとクライアントアプリの管理: $connect および $disconnect ルート](https://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/apigateway-websocket-api-route-keys-connect-disconnect.html)
- [API Gateway のプライベート統合の設定](https://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/set-up-private-integration.html)
- [VPC エンドポイントサービス (AWS PrivateLink)](https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/endpoint-service.html)
- [チュートリアル: API Gateway プライベート統合で API をビルドする](https://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/getting-started-with-private-integration.html)
- [API Gatewayの「Lambda プロキシ統合の使用」オプション](https://qiita.com/yoshidasts/items/8a31280a6331b6407c73)
- [20190514 AWS Black Belt Online Seminar Amazon API Gateway](https://www.slideshare.net/AmazonWebServicesJapan/20190514-aws-black-belt-online-seminar-amazon-api-gateway)
- [API Gateway WebSocket API のマッピングテンプレートリファレンス](https://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/apigateway-websocket-api-mapping-template-reference.html)
- [API Gateway マッピングテンプレートとアクセスのログ記録の変数リファレンス - $input 変数](https://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/api-gateway-mapping-template-reference.html#input-variable-reference)

**IAM ユーザの作成**

- [AWS アクセスキーを管理するためのベストプラクティス](https://docs.aws.amazon.com/ja_jp/general/latest/gr/aws-access-keys-best-practices.html)
- [Amazon EC2 での IAM ロールを使用した AWS リソースへのアクセス権限の付与](https://docs.aws.amazon.com/ja_jp/sdk-for-java/v1/developer-guide//java-dg-roles.html)
- [java - Java アプリケーション起動ツール](https://docs.oracle.com/javase/jp/1.5.0/tooldocs/solaris/java.html)

**java サーブレットの実装**

- [Amazon API Gateway による WebSocket API の作成](http://penguinitis.g1.xrea.com/computer/programming/AWS/API_Gateway_WebSocket.html)

**動作確認**

- [インスタンスに接続するための一般的な前提条件](https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/connection-prereqs.html)
- [SSH を使用した Linux インスタンスへの接続](https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/AccessingInstancesLinux.html)
- [Amazon Linux 2 における Amazon Corretto 11 のインストール手順](https://docs.aws.amazon.com/ja_jp/corretto/latest/corretto-11-ug/amazon-linux-install.html)

# おわりに
(未来の自分のために) 手順やらメモやら軒並み書いたらだいぶ長くなってしまいました。
今回地味に大変だったのは適切なドキュメントや記事を見つけること (そして理解すること) でした。
また 0 から同じページを探せと言われればなかなかしんどい気がします。
そんな理由から、お世話になった記事には似たようなページが並んでいます。あしからず。

おわり！