
## サイト

<https://sharing-text.com>

## 開発経緯

何番煎じかわからないけど、テキスト共有 Web サービスをリリースしました。
とにかく登録不要で期限付きのテキストページが欲しかった。
時々開発経験のない友達などから以下のような相談を受ける時がありました。
・「個人事業用の HP 作成してるんだけどこの JQuery のプラグインどうやったら動くの？」
・「こうゆうデータを取得したいんだけど、どんな SQL 書けばいいの？」
・「この処理でエラーが発生するんだけどどうすればいいの？」
同業者等なら Zoom で画面共有したり、Slack やらなんやら何かしら使っているツールでファイル共有できたりしますが、相談してくる友達などはそうゆうツール類とは無縁だし、開発ツールが Dreamweaver だったりと自分に縁のないツールを使っている状況のため、色々と不便を感じていました。
かといって、Zoom や Slack といったそうゆうツールをわざわざ入れさせて、自分の Slack のワークスペースに招待したり、されたりするのもめんどいので勧めたりはしたくありませんでした。
ただ、やはりどんなことしたいのか、どんな処理をしているのか一々ファイルをメールやらなんやらで、送ってもらったり、それを修正してまた送るのがめんどくさかった。
そんな悩みを解決するために、本サービスを作成することにしました。

## 技術スタック

- 言語: TypeScript
- フロントエンド & バックエンド: [Remix](https://remix.run/)
  - React ベースのフルスタック Web フレームワーク
  - 直近の仕事やプライベートでも SPA で開発していたが、MPA の方が今回のようなサービスを個人開発する時は楽じゃない？と思うこともあって使ってみましたが、比較的楽しく開発できて正解でした。
- インフラ: AWS
- 環境構築: Terraform
  - Remix には AWS にデプロイするために [architect/architect](https://github.com/architect/architect) を使っているのですが、構築されるリソースが個人的にアレだったので、[architect/architect](https://github.com/architect/architect) を使わずに、Terraform にリソースを全て構築しています。
- ライブラリ
  - [Monaco Editor](https://microsoft.github.io/monaco-editor/)
    - ハイライトや比較/差分表示機能が欲しかったので、オーバースペック気味ではあるがこちらのエディターを採用しました。
    - モバイルブラウザなどはサポートされていないとのこと。
  - [Chakra UI](https://chakra-ui.com/)

## 機能

- 言語指定
  - エディターに monaco-editor を使ってるので、取り敢えずそれがサポートしている言語全て選択可能にしてます。
- 有効期限設定(日単位 or 時単位 or 分単位)
  - 日単位: 直近 1 ヶ月分の日にちを選択できます
  - 時単位: 1 ~ 24 時間後を選択できます
  - 分単位: 5 ~ 60 の範囲で 5 分単位できます
- 比較/差分表示
  - 比較しながら修正したかったのもあって、個人的に地味に気にいっている機能。
  - 仕事で似たようなサービスに課題が記載されて、答えを書いていたときに元の課題見ながらできたらいいなと思ったのがきっかけ。
  - 個人的に問題とかを複数人に共有して、解答者は新規作成(コピー)してリンクを提出してもらうというのをやってみた際にもこの機能は便利だった。
- ファイルダウンロード
- コピー(URL or 本文 or 有効期限)

### 新規作成画面

![新規作成画面その 1](/images/posts/tech-posts/1656602928/index.png)

### 閲覧画面

![閲覧画面その 1](/images/posts/tech-posts/1656602928/view.png)

### 新規作成(コピー)画面

コピー元のテキストを参照しながら新規作成が可能です。
比較/差分自体はデフォルトでオフになっています。
また、画面下部の警告にあるように、この新規作成(コピー)機能を使って新規作成した場合、閲覧画面でコピー元のデータを参照することができます。
もし、コピー元のデータを参照・維持させる必要がない場合は、チェックボックスにチェックを入れる必要があります。

![新規作成画面その 2](/images/posts/tech-posts/1656602928/copy_and_create.png)

### 閲覧画面(新規作成(コピー)で作成した場合)

![閲覧画面その 2](/images/posts/tech-posts/1656602928/copy_view.png)

## まとめ

仕事柄今はプロダクト開発をしてませんが、改めて開発の楽しさを実感できました。
今回採用した Remix や Chakra UI などを使って開発できただけでも満足でした。


何番煎じ？ テキスト共有 Web サービスをリリースしました


## Transfer Family を使って EFS に SFTP クライアントからアクセスする

例えば、Lambda しか使わない EFS に必要なリソースを格納する際に、一々 EC2 を立ててマウントしたりするのはめんどくさいです。
Transfer Family を使えば、よくある SFTP クライアント (WinSCP や FileZilla、Cyberduck など)を使って、GUI で手軽に EFS ファイルシステム内にファイル転送などができます。

## Transfer Family を使って EFS に SFTP クライアントからアクセスする際の前提

EFS を作成済みとします。
EFS の作成に関しては以下の記事をご参照ください。

<https://blog.grasswake.me/tech-posts/1649084868>

また、仮背景として EFS は Lambda で利用するため、以下のような Lambda 用のアクセスポイントを作成済みと仮定します。

![アクセスポイント作成 1](/images/posts/tech-posts/1649770909/create_accesspoint_1.png)

![アクセスポイント作成 2](/images/posts/tech-posts/1649770909/create_accesspoint_2.png)

## Transfer Family を使って EFS に SFTP クライアントからアクセスする手順

### Transfer Family 用の IAM ポリシーの作成

[Transfer Family のドキュメント](https://docs.aws.amazon.com/ja_jp/transfer/latest/userguide/read-write-access.html)を参考に、読み取りと書き込みアクセスポリシーを作成します。
`region-id` には、EFS ファイルシステムを作成したリージョン (例: `ap-northeast-1`) を入力します。
`account-id` には、EFS ファイルシステムの AWS アカウント ID を入力します。
`file-system-id` には、EFS ファイルシステムのファイルシステム ID (例: `fs-xxxxxx`) を入力します。

```json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "RootFileSystemAccess",
      "Effect": "Allow",
      "Action": [
        "elasticfilesystem:ClientRootAccess",
        "elasticfilesystem:ClientMount",
        "elasticfilesystem:ClientWrite"
      ],
      "Resource": "arn:aws:elasticfilesystem:region-id:account-id:file-system/file-system-id"
    }
  ]
}
```

### Transfer Family 用の IAM ロールの作成

先ほど作成した IAM ポリシーを適用した IAM ロールを作成します。

また、`transfer.amazonaws.com` を信頼関係として設定しておきます。

```json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "transfer.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
```

### Transfer Family サーバーの作成

Transfer Family コンソールからサーバーを作成します。

今回は Transfer Family 内でユーザーを作成及び管理するので、[ID プロバイダー] は [サービスマネージド] を選択します。
![Transfer Family 作成 1](/images/posts/tech-posts/1649854873/create_transfer_family_1.png)

[プロトコル] は [SFTP] を選択します。
![Transfer Family 作成 2](/images/posts/tech-posts/1649854873/create_transfer_family_2.png)

[エンドポイント] は [パブリックアクセス可能] を選択します。
![Transfer Family 作成 3](/images/posts/tech-posts/1649854873/create_transfer_family_3.png)

[ドメイン] は今回のアクセス先である [Amazon EFS] を選択します。
![Transfer Family 作成 4](/images/posts/tech-posts/1649854873/create_transfer_family_4.png)

他の設定はデフォルトのままでいきます。
![Transfer Family 作成 5](/images/posts/tech-posts/1649854873/create_transfer_family_5.png)

作成するとサーバー一覧で確認できます。
作成には時間がかかるので、状態がオンラインになるまで待ちましょう。
![サーバー一覧](/images/posts/tech-posts/1649854873/list_transfer_falily.png)

### ユーザーの追加

[サーバー一覧] からサーバーを選択し、サーバーの詳細から [ユーザー追加] を行います。
なお、サーバーの詳細にあるエンドポイントは SFTP クライアントで使うため、メモしておきましょう。

![サーバー詳細](/images/posts/tech-posts/1649854873/transfer_falily.png)

[ロール] には先ほど作成した IAM ロールを選択します。
[ホームディレクトリ] には Lambda 用に作成したアクセスポイントのルートディレクトリパスと同じにします。

![ユーザー追加 1](/images/posts/tech-posts/1649854873/add_user_1.png)

[SSH パブリックキー] に任意の SSH パブリックキーを入力します。
SSH キーの作成方法がわからない場合は、[こちらの AWS ドキュメント](https://docs.aws.amazon.com/ja_jp/transfer/latest/userguide/key-management.html)を参考にして下さい。

![ユーザー追加 2](/images/posts/tech-posts/1649854873/add_user_2.png)

### SFTP クライアントを使って EFS へアクセス

SFTP クライアントから実際に EFS にアクセスしてみましょう。

#### Cyberduck の場合

[SFTP (SSH による暗号化 FTP)] を選択します。
[サーバー] には、Transfer Family サーバーのエンドポイント (例: `s-xxxxxxxxxxxxxx`) を入力します。
[ユーザ名] には、作成したユーザー名 (例: `sample`) を入力します。
[SSH Private Key] には、作成した SSH キーのプライベートキーを選択します。

![cyberduck](/images/posts/tech-posts/1649854873/cyberduck.png)

#### FileZilla の場合

[プロトコル] には、[SFTP - SSH File Transfer Protocol] を選択します。
[ホスト] には、Transfer Family サーバーのエンドポイント (例: `s-xxxxxxxxxxxxxx`) を入力します。
[ユーザー] には、作成したユーザー名 (例: `sample`) を入力します。
[鍵ファイル] には、作成した SSH キーのプライベートキーを選択します。

![filezilla](/images/posts/tech-posts/1649854873/filezilla.png)

## EC2 を使わずにホームディレクトリの作成からパーミッションや所有者、所有者グループを変更する方法

ホームディレクトリが作成されていない場合、SFTP クライアントを使って EFS へアクセスした際にエラーが発生します。
本記事ではアクセスポイント作成時に [ルートディレクトリ作成のアクセス許可] の設定により自動で作成されるの問題ありませんが、アクセスポイントを使用しない、名前通りユーザー毎にホームディレクトリを用意したいなどの場合もあるかと思います。
その場合は、EC2 を使わず SFTP で作成することもできます。

まず、ルートユーザーを作成します。
作成方法はユーザー追加時に [ユーザー ID] と [グループ ID] の両方に `0` ( ゼロ ) を入力します。

FileZilla や Cyberduck はディレクトリは作成できても、ディレクトリの所有者や所有者グループの変更はできません。
一方で、以下の Transfer Family のドキュメントに記載されている通り、EFS では `mkdir` や `chown`、`chgrp`、`chmod` などのコマンドが使えます。
[Amazon EFS ファイルシステムを作成します。 \- AWS Transfer Family](https://docs.aws.amazon.com/ja_jp/transfer/latest/userguide/requirements-efs.html#efs-commands)

> 以下のコマンドが Amazon EFS でサポートされています。AWS Transfer Family。
> ・cd
> ・ls/dir
> ・pwd
> ・put
> ・get
> ・rename
> ・chown: root (つまり uid=0 のユーザー) だけがファイルとディレクトリの所有権と権限を変更できます。
> ・chmod: ファイルとディレクトリの所有権と権限を変更できるのは root だけです。
> ・chgrp: ルートまたはファイルの所有者がファイルのグループをセカンダリグループの 1 つに変更することしかできないファイルの所有者に対してサポートされています。
> ・ln -s/symlink
> ・mkdir
> ・rm/delete
> ・rmdir
> ・chmtime

そのため、`sftp` コマンドで Transfer Family サーバー経由で EFS にアクセスして、ディレクトリの作成からパーミッションや所有者、所有者グループの変更を行います。
実際に `sftp` コマンドで Transfer Family サーバー経由で EFS にアクセスして `sample` ディレクトリを作成してみます。
[ssh_private_key] には、作成した SSH キーのプライベートキーのパス (例: `~/.ssh/transfer_key`) を入力します。
[user_name] には、作成したルートユーザーのユーザー名 (例: `sample`) を入力します。
[endpoint] には、Transfer Family サーバーのエンドポイント (例: `s-xxxxxxxxxxxxxx`) を入力します。

```bash
sftp -i ssh_private_key user_name@endpoint
sftp> ls -la
drwxr-xr-x   2       1001     1001     6144 Apr 11 15:23 lambda
sftp> mkdir sample
sftp> chmod 755 sample
sftp> chown 1001 sample
sftp> chgrp 1001 sample
sftp> ls -la
drwxr-xr-x   2       1001     1001     6144 Apr 11 15:23 lambda
drwxr-xr-x   2       1001     1001     6144 Apr 12 00:21 sample
```


Transfer Family を使って EFS に SFTP クライアントからアクセスする


AWS マネジメントコンソールで Amazon EFS のアクセスポイントを作成して AWS Lambda から使用する手順をまとめました。

## EFS を Lambda で使用する際の前提

以下の記事で作成した Amazon EFS を前提にした手順となります。
「ファイルシステムポリシー」は、特に何も設定してません。

<https://blog.grasswake.me/tech-posts/1649084868>

## EFS を Lambda で使用する手順

### Lambda 関数用のセキュリティーグループ作成

- インバウンドルール
  - EFS を使用する上で特に設定する必要はありません。未設定でも大丈夫です。
- アウトバンドルール
  - デフォルトのアウトバウンドルールを使用し、すべてのトラフィックを許可しておきます。

### マウントターゲット用のセキュリティーグループの更新

- インバウンドルール
  |タイプ | プロトコル | ポート範囲 | ソース |
  | --- | --- | ---- | -------------------------------- |
  | NFS | TCP | 2049 | Lambda 関数用に作成したセキュリティーグループ |

### アクセスポイント作成

アクセスポイントを作成します。

[ユーザー ID] や [グループ ID] は Lambda のドキュメント[^1] を参考に `1001` にしています。

[^1]: [Lambda 関数のファイルシステムアクセスの設定 \- AWS Lambda](https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/configuration-filesystem.html#configuration-filesystem-setup)

![アクセスポイント作成 1](/images/posts/tech-posts/1649770909/create_accesspoint_1.png)

![アクセスポイント作成 2](/images/posts/tech-posts/1649770909/create_accesspoint_2.png)

### Lambda 関数の作成

EFS に アクセスするため、Lambda 関数は VPC に設置します。
設置する VPC は EFS を設置した VPC を選択します。
サブネットは EFS のマウントターゲットと同じサブネットを選択します。
セキュリティーグループは先ほど Lambda 関数用に作成したセキュリティーグループを選択します。
因みに、今回サンプルとして使用している EFS は「ファイルシステムポリシー」は未設定のため、[こちらのドキュメント](https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/configuration-filesystem.html#configuration-filesystem-permissions)に書かれている `elasticfilesystem:ClientMount` などのアクセス許可は必要ありません。

![Lambda 関数の作成](/images/posts/tech-posts/1649770909/create_lambda.png)

### ファイルシステムの追加

EFS をファイルシステムとして追加します。

![ファイルシステム](/images/posts/tech-posts/1649770909/lambda_filesystem.png)

先ほど作成したアクセスポイントを選択します。
ローカルマウントパスは `/mnt/efs/` とします。

![ファイルシステムの追加](/images/posts/tech-posts/1649770909/add_filesystem.png)

### 動作確認

ローカルマウントパスとして指定した `/mnt/efs/` にファイルを作成してみます。
特にエラーが発生せず、実行結果のログに作成したファイル名が表示されていれば成功です。

```python
import json
import os

def lambda_handler(event, context):

    f = open('/mnt/efs/sample.txt', 'w')
    f.write('test')
    f.close()
    filenames = [f.name for f in os.scandir("/mnt/efs")]
    print(filenames)
```

![実行結果](/images/posts/tech-posts/1649770909/lambda_log.png)


EFS を Lambda で使用する


## 概要

Lambda の Python ランタイムから OpenCV モジュールを利用できるようにするため、Lambda レイヤーに OpenCV を追加します。

## 構築環境

```bash
$ python -V
Python 3.9.12
$ pip -V
pip 22.0.4 from /home/ec2-user/.anyenv/envs/pyenv/versions/3.9.12/lib/python3.9/site-packages/pip (python 3.9)
```

## Lambda レイヤーに OpenCV モジュールを追加する手順

### 作業用ディレクトリとレイヤーパスの作成

```bash
mkdir -p ~/opencv_layer/python
```

### OpenCV 　(opencv-python) のインストール

`python` ディレクトリに `opencv-python` をインストールします。

```bash
$ cd ~/opencv_layer
$ pip install opencv-python -t python
Collecting opencv-python
  Using cached opencv_python-4.5.5.64-cp36-abi3-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (60.5 MB)
Collecting numpy>=1.17.3
  Using cached numpy-1.22.3-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (16.8 MB)
Installing collected packages: numpy, opencv-python
Successfully installed numpy-1.22.3 opencv-python-4.5.5.64
```

### mesa-libGL のインストール

現状、`opencv-python` をインストールしたディレクトリをプロイパッケージ化 (zip ファイルアーカイブ) して、Lambda レイヤーを作成して `cv2` を `import` すると以下のようなエラーが発生します。

```text
[ERROR] Runtime.ImportModuleError: Unable to import module 'lambda_function': libGL.so.1: cannot open shared object file: No such file or directory
```

既知の問題みたいで以下のサイトを参考に対応していきます。

<https://stackoverflow.com/questions/64016819/cant-use-opencv-python-in-aws-lambda>

まず、`mesa-libGL` をインストールします。

```bash
sudo yum install -y mesa-libGL
```

`mesa-libGL` をインストール後に、必要なライブラリを `python` ディレクトリに追加します。

```bash
cd ~/opencv_layer
cp -v /usr/lib64/libGL.so.1 ./python/opencv_python.libs/
cp -v /usr/lib64/libgthread-2.0.so.0 ./python/opencv_python.libs/
cp -v /usr/lib64/libglib-2.0.so.0 ./python/opencv_python.libs/
cp -v /usr/lib64/libGLX.so.0 ./python/opencv_python.libs/
cp -v /usr/lib64/libX11.so.6 ./python/opencv_python.libs/
cp -v /usr/lib64/libXext.so.6 ./python/opencv_python.libs/
cp -v /usr/lib64/libGLdispatch.so.0 ./python/opencv_python.libs/
cp -v /usr/lib64/libGLX_mesa.so.0.0.0 ./python/opencv_python.libs/
cp -v /usr/lib64/libxcb.so.1 ./python/opencv_python.libs/
cp -v /usr/lib64/libXau.so.6 ./python/opencv_python.libs/
cp -v /lib64/libGLdispatch.so.0.0.0 ./python/opencv_python.libs/
```

### 軽量化のために不要なファイルを削除する

そのままだと、236 MB もあるので不要なファイルを削除して少しでも軽くします。

```bash
$ du -sh python/
236M    python/
```

`Serverless Framework` の [Slim Package][^1] を参考に `dist-info`、`__pycache__`、`pyc`、`pyo` を削除します。

[^1]: [Serverless Framework: Plugins](https://www.serverless.com/plugins/serverless-python-requirements)

```bash
find ./python -type d -regextype posix-basic -regex ".*dist-info.*" | xargs rm -rf
find ./python -type d -regextype posix-basic -regex ".*__pycache__.*" | xargs rm -rf
find ./python -type f -regextype posix-basic -regex ".*\.py[c|o]" | xargs rm -rf
```

8 MB だけ軽くなりました。。。

```bash
$ du -sh python/
228M    python/
```

:::warning
軽量化とは別ですが、オブジェクトファイルからのシンボルテーブルなどを削除する `strip` コマンドを実行したデプロイパッケージを使用すると以下のようなエラーが発生しますので、やらないようにしましょう。

```bash
[ERROR] Runtime.ImportModuleError: Unable to import module 'lambda_function': /opt/python/cv2/cv2.abi3.so: ELF load command address/offset not properly aligned
```

:::

### デプロイパッケージ化 (zip ファイルアーカイブ)

```bash
cd ~/opencv_layer
zip -r9 opencv_layer.zip python
```

### 不要なファイルを削除して軽量化する

### Lambda レイヤーの作成

デプロイパッケージを使用した Lambda レイヤーの作成手順はこちらにまとめてあります。

<https://blog.grasswake.me/tech-posts/1640005577>

## 動作確認

作成した Lambda レイヤーを使用する Lambda 関数を作成し、テスト実行してみます。
特にエラーが発生せず、実行結果のログに `cv2` モジュール内で定義されている関数、属性などの一覧が表示されていれば成功です。

```python
import cv2

def lambda_handler(event, context):
        print(dir(cv2))
```

## Lambda レイヤーに ライブラリを追加する ( OpenCV 編)　まとめ

`opencv-python` をインストールしただけでも 236 MB にもなります。
2022/04 時点では、Lambda デプロイパッケージ (zip ファイルアーカイブ) の上限サイズは 250 MB (解凍後)[^2] です。
かなりギリギリで、`opencv-python` 以外のモジュールを追加するのも難しいです。
`opencv-contrib-python` なんて入りません。
どうしても Lambda で `opencv` を使用する場合は、コードパッケージサイズの上限が 10 GB[^2] もあるコンテナイメージを使用することを検討した方良いかなと思います。

[^2]: [Lambda クォータ \- AWS Lambda](https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/gettingstarted-limits.html#function-configuration-deployment-and-execution)


Lambda レイヤーにライブラリを追加する ( OpenCV 編)


AWS マネジメントコンソールで Amazon EFS を作成して EC2 (Amazon Linux 2) からマウントする手順をまとめました。

## 完成構成図

![完成構成図](/images/posts/tech-posts/1649084868/architecture.svg)

## EFS を作成して EC2 (Amazon Linux 2) からマウントする際の事前準備

- EC2 インスタンス(Amazon Linux 2) を作成しておきます。
- EC2 インスタンスの VPC の [DNS 解決] と [DNS ホスト名] 設定が有効になっている確認して、無効になっている場合は、有効化しておきます。
  以下の EFS のドキュメントに記載されている通り、EFS に接続する EC2 インスタンスの VPC の [DNS 解決] と [DNS ホスト名] の利用が有効になっている必要があります。
  [DNS 名を使用して Amazon EC2 にマウントする \- Amazon Elastic File System](https://docs.aws.amazon.com/ja_jp/efs/latest/ug/mounting-fs-mount-cmd-dns-name.html)

> 接続する EC2 インスタンスの VPC で DNS 解決と DNS ホスト名の利用が有効になっている必要があります。詳細については、Amazon VPC ユーザーガイド の「EC2 インスタンスの DNS ホスト名を確認する」を参照してください。

![VPC の DNS 設定確認](/images/posts/tech-posts/1649084868/setting_dns.png)

## EFS を作成して EC2 (Amazon Linux 2) からマウントする手順

### マウントターゲット用のセキュリティーグループ作成

EFS のドキュメントではマウントターゲットに設定するセキュリティーグループについて以下のように記載しています。

[セキュリティグループの作成 \- Amazon Elastic File System](https://docs.aws.amazon.com/ja_jp/efs/latest/ug/accessing-fs-create-security-groups.html)

> ただし、EC2 インスタンスとマウントターゲット (したがって、ファイルシステム) の間のトラフィックを有効にするには、これらのセキュリティグループに次のルールを設定する必要があります。
> ・マウントターゲットに関連付けるセキュリティグループは、ファイルシステムをマウントするすべての EC2 インスタンスから、NFS ポート上の TCP プロトコルへのインバウンドアクセスを許可する必要があります。
> ・ファイルシステムをマウントする各 EC2 インスタンスには、NFS ポート上のマウントターゲットへのアウトバウンドアクセスを許可するセキュリティグループが必要です。

上記の記述を参考に以下のようなセキュリティーグループを作成します。

- インバウンドルール
  |タイプ | プロトコル | ポート範囲 | ソース |
  | --- | --- | ---- | -------------------------------- |
  | NFS | TCP | 2049 | EC2 インスタンスに設定したセキュリティーグループ |

- アウトバンドルール
  - 以下の EFS のドキュメントに記載れているように、デフォルトのアウトバウンドルールを使用し、すべてのトラフィックを許可しておきます。
    [セキュリティグループの作成 \- Amazon Elastic File System](https://docs.aws.amazon.com/ja_jp/efs/latest/ug/accessing-fs-create-security-groups.html)
    > デフォルトのアウトバウンドルールですべてのトラフィックを残すことができるため、アウトバウンドルールを追加する必要はありません (それ以外の場合は、アウトバウンドルールを追加して、NFS ポートで TCP 接続を開き、マウントターゲットのセキュリティグループを送信先として識別する必要があります)。

### EFS の作成

では、EFS を作成していきます。
EFS コンソールから [ファイルシステムの作成] をクリックすると、以下のモーダルが表示されます。
マウントターゲットに先ほど作成したマウントターゲット用のセキュリティーグループを指定したいため、ここでは [カスタマイズ] をクリックします。

![EFS 作成](/images/posts/tech-posts/1649084868/create_efs_1.png)

「ファイルシステムの設定」はデフォルトのままでいきます。

![ファイルシステムの設定 1](/images/posts/tech-posts/1649084868/create_efs_2.png)
![ファイルシステムの設定 2](/images/posts/tech-posts/1649084868/create_efs_3.png)

「ネットワークシステム」では、マウントターゲットに先ほど作成したマウントターゲット用のセキュリティーグループを指定します。

![ネットワークシステム](/images/posts/tech-posts/1649084868/create_efs_4.png)

「ファイルシステムポリシー」は、今回アクセス制御まではやらないため、特に何も設定しません。

![ファイルシステムポリシー](/images/posts/tech-posts/1649084868/create_efs_3.png)

EFS の作成が完了すると、ファイルシステム一覧に表示されるので、「ファイルシステム ID」をメモしておきます。

![ファイルシステム一覧](/images/posts/tech-posts/1649084868/efs_list.png)

### EC2 インスタンスに Amazon EFS クライアント (amazon-efs-utils) をインストール

EC2 インスタンスに Amazon EFS クライアント (`amazon-efs-utils`) をインストールします。

```bash
sudo yum -y install amazon-efs-utils
```

`amazon-efs-utils` は EFS ファイルシステムのマウントが簡素化され、ファイルシステムのパフォーマンスが向上することに加え、転送データを TLS で暗号化できます。
`amazon-efs-utils` を使用せずともマウントはできますが、以下に記載されている通り、公式で推奨されたツールなので特に理由がなければ、`amazon-efs-utils` を使うのが良いと思います。

[概要 \- Amazon Elastic File System](https://docs.aws.amazon.com/ja_jp/efs/latest/ug/overview-amazon-efs-utils.html)

> Amazon EFS クライアントには、マウントヘルパーおよび Amazon EFS ファイルシステムの転送時のデータ暗号化の実行を容易にするツールが用意されています。
> マウントヘルパーは、特定のタイプのファイルシステムのマウント時に使用するプログラムです。
> Amazon EFS ファイルシステムをマウントするために、Amazon EFS に含まれているマウントヘルパーを使用することをお勧めします。

また、以下に記載されている通り、本記事では紹介しませんが、IAM 認証による EFS のマウントを行う場合は `amazon-efs-utils` を使用する必要があります。

[IAM 認証を使用してマウントする \- Amazon Elastic File System](https://docs.aws.amazon.com/ja_jp/efs/latest/ug/mounting-IAM-option.html)

> AWS Identity and Access Management ()IAM 認証を使用して Linux インスタンスに Amazon EFS ファイルシステムをマウントするには、EFS マウントヘルパーを使用する必要があります。

### EC2 インスタンスから EFS ファイルシステムをマウントターゲットを介してマウントする

まず、マウントポイントとなるディレクトリ（`efs`）を作成し、`mount` コマンドを実行して EFS ファイルシステムをマウントします。
`file-system-id` には、作成したファイルシステムのファイルシステム ID (例: fs-xxxxxx) を入力します。

```bash
cd ~
mkdir efs
sudo mount -t efs file-system-id efs/
```

`df` コマンドで EFS ファイルシステムがマウントされていることを確認します。

```basn
$ df
ファイルシス        1K-ブロック    使用           使用可 使用% マウント位置
devtmpfs                 485344       0           485344    0% /dev
tmpfs                    494336       0           494336    0% /dev/shm
tmpfs                    494336     464           493872    1% /run
tmpfs                    494336       0           494336    0% /sys/fs/cgroup
/dev/xvda1              8376300 1588764          6787536   19% /
tmpfs                     98868       0            98868    0% /run/user/1000
127.0.0.1:/    9007199254739968       0 9007199254739968    0% /home/ec2-user/efs
```

再起動後にも自動でマウントされるようにするには、`/etc/fstab` に以下の 1 行を追加してください。
`file-system-id` には、作成したファイルシステムのファイルシステム ID (例: `fs-xxxxxx`) を入力します。
`efs-mount-point` には、マウントポイントとして作成したディレクトリの完全パス(例: `/home/ec2-user/efs`)を入力します。

```bash
file-system-id:/ efs-mount-point efs _netdev,noresvport,tls 0 0
```

### 動作確認その 1

マウントポイントとして指定したディレクトリに移動して、ファイルを作成した後、ディレクトリ内を表示して、ファイルが作成されていることを確認できれば成功です。

```bash
$ cd ~/efs
$ sudo touch sample.txt
$ ls
sample.txt
```

因みに、上記のようにファイル作成に `sudo` コマンドを使っています。
これは、マウント後にマウントポイントとして指定したディレクトリのパーミッション及び所有者が変わるためです。
`ec2-user` でマウントポイントとして作成したディレクトリは作成時は以下のようにパーミッションが `774` で所有者と所有者グループは `ec2-user` になっています。

```bash
drwxrwxr-x 2 ec2-user ec2-user   6  3月 30 08:25 efs
```

しかし、`sudo` コマンドによるマウント後は、以下のようにパーミッションが `755` で所有者と所有者グループは `root` になっています。

```bash
drwxr-xr-x 2 root     root     6144  3月 30 08:13 efs
```

そのため、以下のようにマウントポイントして作成したディレクトリに `chmod` コマンドで書き込み権限を付与することで `sudo` なしでファイル作成などが可能です。
また、この時変更したパーミッションは別の EC2 インスタンスからマウントした時も引き継がれていました。

```bash
cd /home/ec2-user/efs
sudo chmod go+w .
mkdir sample.txt
```

### アクセスポイント作成

ここからはアクセスポイントを利用した EFS ファイルシステムのマウントの手順を紹介します。
先に紹介したマウントターゲットを介したマウントと挙動が異なります。
アクセスポイントを使用すると、アクセスポイントを介したすべての操作は指定したユーザー ID 及び グループ ID で実行されます。
また、ファイルシステムに対して別のルートディレクトリを設定でき、このディレクトリまたはそのサブディレクトリ内のデータに対してのみ、アクセスを許可することもできます。
これにより、複雑なファイルパスのマウントや権限の切り分けが容易になります。
アクセスポイントの詳細については[こちらを](https://docs.aws.amazon.com/ja_jp/efs/latest/ug/efs-access-points.html)参照してください。

まず、アクセスポイントを作成します。

[ユーザー ID] や [グループ ID] は `ec2-user` と同じ `1000` にしています。

![アクセスポイント作成 1](/images/posts/tech-posts/1649084868/create_accesspoint_1.png)

![アクセスポイント作成 2](/images/posts/tech-posts/1649084868/create_accesspoint_2.png)

### EC2 インスタンスから EFS ファイルシステムをアクセスポイントを介してマウントする

まず、マウントポイントとなるディレクトリ（`/mnt/efs`）を作成し、`mount` コマンドを実行して EFS ファイルシステムをマウントします。
`file-system-id` には、作成したファイルシステムのファイルシステム ID (例: `fs-xxxxxx`) を入力します。
`access-point-id` には、作成したアクセスポイントのアクセスポイント ID (例: `fsap-xxxxxx`) を入力します。

```bash
cd ~
mkdir ap-efs
sudo mount -t efs -o tls,accesspoint=access-point-id file-system-id:/ ap-efs
```

`df` コマンドで EFS ファイルシステムがマウントされていることを確認します。

```bash
$ df
ファイルシス        1K-ブロック    使用           使用可 使用% マウント位置
devtmpfs                 485344       0           485344    0% /dev
tmpfs                    494336       0           494336    0% /dev/shm
tmpfs                    494336     464           493872    1% /run
tmpfs                    494336       0           494336    0% /sys/fs/cgroup
/dev/xvda1              8376300 1588764          6787536   19% /
tmpfs                     98868       0            98868    0% /run/user/1000
127.0.0.1:/    9007199254739968       0 9007199254739968    0% /home/ec2-user/ap-efs
```

再起動後にも自動でマウントされるようにするには、`/etc/fstab` に以下の 1 行を追加してください。
`file-system-id` には、作成したファイルシステムのファイルシステム ID (例: fs-xxxxxx) を入力します。
`efs-mount-point` には、マウントポイントとして作成したディレクトリの完全パス(例: `/home/ec2-user/ap-efs`)を入力します。
`access-point-id` には、作成したアクセスポイントのアクセスポイント ID (例: `fsap-xxxxxx`) を入力します。

```bash
file-system-id efs-mount-point efs _netdev,tls,accesspoint=access-point-id 0 0
```

### 動作確認その 2

マウントポイントとして指定したディレクトリに移動して、ファイルを作成した後、ディレクトリ内を表示して、ファイルが作成されていることを確認できれば成功です。

```bash
$ cd ~/ap-efs
$ touch sample.txt
$ ls
sample.txt
```

先に紹介したマウントターゲットを介したマウント時と違いファイル作成に `sudo` コマンドを使っていません。
これは、先ほど紹介したアクセスポイントの特徴の一つである、「アクセスポイントを介したすべての操作は指定したユーザー ID 及び グループ ID で実行されます。」によるものです。
`ec2-user` でマウントポイントとして作成したディレクトリは作成時は以下のようにパーミッションが `774` で所有者と所有者グループは `ec2-user` になっています。

```bash
drwxrwxr-x 2 ec2-user ec2-user 6 3 月 30 08:25 ap-efs
```

しかし、アクセスポイントを介したマウント後は、以下のようにパーミッションがアクセスポイント作成時の [ルートディレクトリ作成のアクセス許可] で指定した `755` となっています。
また、所有者と所有者グループは [ルートディレクトリ作成のアクセス許可] で指定した ID = `1000` = `ec2-user` になっています。

```bash
drwxr-xr-x 2 ec2-user ec2-user 6144 3 月 30 14:29 ap-efs
```

また、作成したファイルの所有者情報を確認してみると、所有者と所有者グループは [POSIX ユーザー] で指定した ID = `1000` = `ec2-user` になっているのが確認できます。

```bash
ls -la
total 12
drwxr-xr-x 2 ec2-user ec2-user 6144 Mar 30 14:29 .
drwxr-xr-x 20 ec2-user ec2-user 4096 Mar 27 14:43 ..
-rw-rw-r-- 1 ec2-user ec2-user 0 Mar 30 14:29 sample.txt
```

## EFS を作成して EC2 (Amazon Linux 2) からマウントしてみる　おまけ

### EFS ファイルシステムのアンマウント

マウントした EFS ファイルシステムをアンマウントしたい場合は、`umount` コマンドを使用します。
`efs-mount-point` には、マウントポイントとして作成したディレクトリの完全パス(例: `/home/ec2-user/ap-efs`)を入力します。

```bash
umount efs-mount-point
```

### 「mount: /home/ec2-user/efs: 未知のファイルシステムタイプ 'efs' です.」 というエラーが表示された

Amazon EFS クライアント (`amazon-efs-utils`) をインストールしていない場合、発生します。
(`amazon-efs-utils` をインストールしましょう。

### 「b'mount.nfs4: Connection reset by peer'」 というエラーが表示された

マウントターゲットのセキュリティーグループの設定に問題がある場合に表示されます。
[完成構成図](/tech-posts/1649084868#完成構成図)で示すマウントターゲットに設定しているセキュリティーグループは EC2 インスタンスからの NFS 通信(ポート番号: 2029)を正しく許可されている必要があります。
そのため、マウントターゲットに設定したセキュリティーグループの設定を確認しましょう。

### 「Failed to resolve ~ 」 というエラーが表示された

以下のようなエラーが表示された場合、EC2 インスタンスが所属する VPC の DNS 設定に問題がある場合に表示されます。
EFS に接続する EC2 インスタンスの VPC の [DNS 解決] と [DNS ホスト名] の利用が有効になっている確認しましょう。

```bash
Failed to resolve "fs-xxxxxxxxx.efs.ap-northeast-1.amazonaws.com". The file system mount target ip address cannot be found, please pass mount target ip address via mount options.
User: arn:aws:sts::yyyyyyyyyyyyyy:assumed-role/sample/i-zzzzzzzzzzzzzz is not authorized to perform: elasticfilesystem:DescribeMountTargets on the specified resource
```


EFS を作成して EC2 (Amazon Linux 2) からマウントしてみる


Java での Lambda レイヤーを作成手順をまとめました。

## Java + Gradle で Lambda レイヤー用のデプロイパッケージを作成する環境

- macOS: Catalina (10.15.7)
- JDK: Amazon Corretto 11 (Java 11 JDK)
- Gradle: 7.4.1

## Java + Gradle で Lambda レイヤー用のデプロイパッケージを作成する際の前提

こちらの[記事](https://blog.grasswake.me/tech-posts/1647962624)で実装した Lambda 関数をサンプルとして使います。
またこれから紹介する手順は以下の 2 つに分けて説明します。

- 外部の依存関係ライブラリを Lambda レイヤーに追加する手順
- 独自ライブラリを Lambda レイヤーに追加する手順

<https://blog.grasswake.me/tech-posts/1647962624>

## Java + Gradle で外部の依存関係ライブラリを追加した Lambda レイヤー用のデプロイパッケージを作成する手順

この手順では[サンプル](https://blog.grasswake.me/tech-posts/1647962624)で使用している以下の外部ライブラリを Lambda レイヤーに追加します。

- com.google.code.gson:gson:2.9.0
- com.amazonaws:aws-lambda-java-core:1.2.1

### 作業用ディレクトリの作成とプロジェクトの初期化

作業ディレクトリを作成して、`gradle init` コマンドを実行します。
`gradle init` コマンド実行時の各設問は最初の 2 つ以外はデフォルト値にしています。

```bash
$ mkdir ~/java-layer
$ cd ~/java-layer
$ gradle init
Starting a Gradle Daemon (subsequent builds will be faster)

Select type of project to generate:
  1: basic
  2: application
  3: library
  4: Gradle plugin
Enter selection (default: basic) [1..4] 1

Select build script DSL:
  1: Groovy
  2: Kotlin
Enter selection (default: Groovy) [1..2] 1

Generate build using new APIs and behavior (some features may change in the next minor release)? (default: no) [yes, no]

Project name (default: java-layer):

> Task :init
Get more help with your project: Learn more about Gradle by exploring our samples at https://docs.gradle.org/7.4.1/samples

BUILD SUCCESSFUL in 16s
2 actionable tasks: 2 executed
```

`gradle init` コマンド実行後、ディレクトリ構成は以下のようになります。

```text
.
├── build.gradle
├── gradle
│   └── wrapper
│       ├── gradle-wrapper.jar
│       └── gradle-wrapper.properties
├── gradlew
├── gradlew.bat
└── settings.gradle
```

### 外部ライブラリの定義とデプロイパッケージ作成タスクの定義

`build.gradle` ファイルを修正します。
`dependencies` に Lambda レイヤーに追加する外部ライブラリを定義します。
また、`task` でデプロイパッケージ(.zip ファイルアーカイブ)を作成するタスクを定義します。

外部ライブラリを保存するパスに注意してください。
Lambda のドキュメントでは以下のように記載しています。

[Lambda レイヤーの作成と共有 \- AWS Lambda](https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/configuration-layers.html#configuration-layers-path)

> ライブラリの依存関係をレイヤーに含める
> Lambda ランタイムごとに、PATH 変数に /opt ディレクトリ内の特定のフォルダが含まれます。レイヤー .zip ファイルアーカイブに同じフォルダ構造を定義すると、関数コードはパスを指定しなくても、レイヤーコンテンツにアクセスできます。
> ...
> 各 Lambda ランタイムのレイヤーパス
> Java java/lib (CLASSPATH)

上記の記述のように、Lambda レイヤーにアップロードする zip ファイルアーカイブに特定のディレクトリにライブラリなどの依存関係を含めておくだけで、パスを指定しなくてもそれを利用することができます。
今回は Java なので、`java/lib` ディレクトリに外部ライブラリを保存するよう必要があります。

```groovy fn=java-layer/build.gradle
plugins {
    id 'java'
}

repositories {
    mavenCentral()
}

dependencies {
    implementation 'com.google.code.gson:gson:2.9.0'
    implementation 'com.amazonaws:aws-lambda-java-core:1.2.1'
}

task buildZip(type: Zip) {
    into('java/lib') {
        from configurations.runtimeClasspath
    }
}

build.dependsOn buildZip
```

### デプロイパッケージの作成その 1

`gradle build` コマンドを実行してデプロイパッケージを作成します。

```bash
gradle build
```

`build/distributions` ディレクトリに zip 形式のデプロイパッケージが作成されます。
作成されたデプロイパッケージには以下のように `java/lib/` ディレクトリと外部ライブラリが格納されます。

```bash
$ unzip -l build/distributions/java-layer.zip
Archive:  build/distributions/java-layer.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
        0  03-21-2022 23:02   java/
        0  03-21-2022 23:02   java/lib/
   249277  03-20-2022 23:20   java/lib/gson-2.9.0.jar
     7515  03-20-2022 22:45   java/lib/aws-lambda-java-core-1.2.1.jar
---------                     -------
   256792                     4 files
```

### Lambda レイヤーの作成と Lambda 関数への紐付け 1

作成したデプロイパッケージを使って AWS マネジメントコンソールから Lambda レイヤーを作成と Lambda 関数への紐付けすることもできますが、今回は AWS CLI を使っていきます。
まず、`publish-layer-version` コマンドで Lambda レイヤーを作成します。
次の手順で使用するので、`publish-layer-version` コマンド実行結果から `LayerVersionArn` をメモしておきましょう。

```bash
$ aws lambda publish-layer-version --layer-name java-basic-layer \
--zip-file fileb://build/distributions/java-layer.zip --compatible-runtimes java11
{
    "Content": {
        "Location": "https://awslambda-ap-ne-1-layers.s3.ap-northeast-1.amazonaws.com/xxxxxxxxxxxxx"
        "CodeSha256": "V9RhiYR2QpTQEq7mKcl3pQnn+TTvMVyUKL9pbTi7Gd4=",
        "CodeSize": 227065
    },
    "LayerArn": "arn:aws:lambda:ap-northeast-1:zzzzzzzzzzzzzz:layer:java-basic-layer",
    "LayerVersionArn": "arn:aws:lambda:ap-northeast-1:zzzzzzzzzzzzzz:layer:java-basic-layer:1",
    "Description": "",
    "CreatedDate": "2022-03-21T14:04:36.472+0000",
    "Version": 1,
    "CompatibleRuntimes": [
        "java11"
    ]
}
```

次に、作成した Lambda レイヤーを[サンプルの Lambda 関数](https://blog.grasswake.me/tech-posts/1647962624)へ紐付けします。
`--layers` オプションに先ほどメモした `LayerVersionArn` を指定します。

```bash
aws lambda update-function-configuration --function-name java-sample \
 --layers arn:aws:lambda:ap-northeast-1:zzzzzzzzzzzzzz:layer:java-basic-layer:1
```

### Lambda 関数から外部ライブラリを排除する

[サンプルの Lambda 関数](https://blog.grasswake.me/tech-posts/1647962624)のデプロイパッケージに外部ライブラリを含める必要がなくなるので、含めないように修正します。
`build.gradle` ファイルを修正します。
`task` でデプロイパッケージ(.zip ファイルアーカイブ)を作成するタスクから外部ライブラリに関連する定義を削除します。

```groovy fn=java-sample/build.gradle
plugins {
    id 'java'
}

repositories {
    mavenCentral()
}

dependencies {
    implementation 'com.google.code.gson:gson:2.9.0'
    implementation 'com.amazonaws:aws-lambda-java-core:1.2.1'
}

task buildZip(type: Zip) {
    from compileJava
    from processResources
    // 以下の定義が不要になります。
    // into('lib') {
    //     from configurations.runtimeClasspath
    // }
}

build.dependsOn buildZip
```

### デプロイパッケージの作成その 2

`gradle build` コマンドを実行してデプロイパッケージを作成します。

```bash
gradle build
```

`build/distributions` ディレクトリに zip 形式のデプロイパッケージが作成されます。
作成されたデプロイパッケージには以下のように外部ライブラリがなくなり、クラスファイルのみが格納されます。

```bash
$ unzip -l build/distributions/java-sample.zip
Archive:  build/distributions/java-sample.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
        0  03-21-2022 22:51   sample/
     2686  03-21-2022 22:51   sample/App.class
     1381  03-21-2022 22:51   previous-compilation-data.bin
---------                     -------
     4067                     3 files
```

### Lambda 関数の更新と実行その 1

作成したデプロイパッケージを使って AWS マネジメントコンソールから Lambda 関数を更新することもできますが、今回は AWS CLI を使って Lambda 関数の更新をします。

```bash
aws lambda update-function-code --function-name java-sample --zip-file fileb://build/distributions/java-sample.zip
```

Lambda 関数を実行して、エラーが出ず以下のように出力されれば成功です。
また、Lambda 関数の CloudWatch Logs のロググループに `payload` の値などが出力されているはずです。

```bash
$ aws lambda invoke --function-name java-sample  \
--payload '{"text":"Hello"}' response.txt --cli-binary-format raw-in-base64-out
{
    "StatusCode": 200,
    "ExecutedVersion": "$LATEST"
}
```

## Java + Gradle で独自ライブラリを追加した Lambda レイヤー用のデプロイパッケージを作成する手順

この手順では[サンプル](https://blog.grasswake.me/tech-posts/1647962624)内のログ処理を独自ライブラリとして Lambda レイヤーに追加します。

```java fn=java-sample/src/main/java/sample/App.java
package sample;

import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.RequestHandler;
import com.amazonaws.services.lambda.runtime.LambdaLogger;

import com.google.gson.Gson;
import com.google.gson.GsonBuilder;

import java.util.Map;

public class App implements RequestHandler<Map<String, String>, String> {
  Gson gson = new GsonBuilder().setPrettyPrinting().create();

  @Override
  public String handleRequest(Map<String, String> event, Context context) {
    String response = new String("200 OK");
    // ---ここから---
    LambdaLogger logger = context.getLogger();
    // log execution details
    logger.log("ENVIRONMENT VARIABLES: " + gson.toJson(System.getenv()));
    logger.log("CONTEXT: " + gson.toJson(context));
    // process event
    logger.log("EVENT: " + gson.toJson(event));
    logger.log("EVENT TYPE: " + event.getClass().toString());
    // ---ここまでの処理を独自ライブラリ化します。---
    return response;
  }
}
```

### 独自ライブラリ処理の実装

まず、独自ライブラリ処理を実装するためのファイルを作成します。

```bash
cd ~/java-layer
mkdir src/main/java/sample_lib
touch src/main/java/sample_lib/Util.java
```

[サンプル](https://blog.grasswake.me/tech-posts/1647962624)内のログ処理を参考にというかほぼそのまま持ってきます。

```java fn=java-layer/src/main/java/sample_lib/Util.java
package sample_lib;

import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.LambdaLogger;

import com.google.gson.Gson;
import com.google.gson.GsonBuilder;

import java.util.Map;

public class Util {
  public static void log(Map<String, String> event, Context context) {
    Gson gson = new GsonBuilder().setPrettyPrinting().create();
    LambdaLogger logger = context.getLogger();
    // log execution details
    logger.log("ENVIRONMENT VARIABLES: " + gson.toJson(System.getenv()));
    logger.log("CONTEXT: " + gson.toJson(context));
    // process event
    logger.log("EVENT: " + gson.toJson(event));
    logger.log("EVENT TYPE: " + event.getClass().toString());
  }
}
```

### デプロイパッケージ作成タスクに独自ライブラリを追加するように定義する

`build.gradle` ファイルを修正します。
`buildZip` タスクで外部ライブラリ(`configurations.runtimeClasspath`)に加えコンパイルした独自ライブラリ(`jar`)も Lambda レイヤーに追加するように定義します。

```groovy fn=java-layer/build.gradle
plugins {
    id 'java'
}

repositories {
    mavenCentral()
}

dependencies {
    implementation 'com.google.code.gson:gson:2.9.0'
    implementation 'com.amazonaws:aws-lambda-java-core:1.2.1'
}

task buildZip(type: Zip) {
    into('java/lib') {
        from jar, configurations.runtimeClasspath
    }
}

build.dependsOn buildZip
```

### デプロイパッケージの作成その 3

`gradle build` コマンドを実行してデプロイパッケージを作成します。

```bash
gradle build
```

`build/distributions` ディレクトリに zip 形式のデプロイパッケージが作成されます。
作成されたデプロイパッケージには以下のように `java/lib/` ディレクトリと独自ライブラリ(`java-layer.jar`)と外部ライブラリが格納されます。

```bash
$ unzip -l build/distributions/java-layer.zip
Archive:  build/distributions/java-layer.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
        0  03-21-2022 23:17   java/
        0  03-21-2022 23:17   java/lib/
     1446  03-21-2022 23:17   java/lib/java-layer.jar
   249277  03-20-2022 23:20   java/lib/gson-2.9.0.jar
     7515  03-20-2022 22:45   java/lib/aws-lambda-java-core-1.2.1.jar
---------                     -------
   258238                     5 files
```

### Lambda レイヤーの更新と Lambda 関数への紐付け 2

作成したデプロイパッケージを使って AWS マネジメントコンソールから Lambda レイヤーの更新と Lambda 関数への紐付けすることもできますが、今回は AWS CLI を使っていきます。
まず、`publish-layer-version` コマンドで Lambda レイヤーを更新します。
次の手順で使用するので、`publish-layer-version` コマンド実行結果から `LayerVersionArn` をメモしておきましょう。

```bash
$ aws lambda publish-layer-version --layer-name java-basic-layer \
--zip-file fileb://build/distributions/java-layer.zip --compatible-runtimes java11
{
    "Content": {
        "Location": "https://awslambda-ap-ne-1-layers.s3.ap-northeast-1.amazonaws.com/xxxxxxxxxxxxx"
        "CodeSha256": "V9RhiYR2QpTQEq7mKcl3pQnn+TTvMVyUKL9pbTi7Gd4=",
        "CodeSize": 227065
    },
    "LayerArn": "arn:aws:lambda:ap-northeast-1:zzzzzzzzzzzzzz:layer:java-basic-layer",
    "LayerVersionArn": "arn:aws:lambda:ap-northeast-1:zzzzzzzzzzzzzz:layer:java-basic-layer:2",
    "Description": "",
    "CreatedDate": "2022-03-21T14:04:36.472+0000",
    "Version": 1,
    "CompatibleRuntimes": [
        "java11"
    ]
}
```

次に、作成した Lambda レイヤーを[サンプルの Lambda 関数](https://blog.grasswake.me/tech-posts/1647962624)へ紐付けします。
`--layers` オプションに先ほどメモした `LayerVersionArn` を指定します。

```bash
aws lambda update-function-configuration --function-name java-sample \
 --layers arn:aws:lambda:ap-northeast-1:zzzzzzzzzzzzzz:layer:java-basic-layer:2
```

### 独自ライブラリの取り込みと Lambda 関数から独自ライブラリの処理を呼び出す

まず、`libs` ディレクトリを作成し、独自ライブラリの jar ファイルをコピーします。

```bash
mkdir ~/java-sample/libs
cp ~/java-layer/build/libs/java-layer.jar ~/java-sample/libs
```

次に、[サンプルの Lambda 関数](https://blog.grasswake.me/tech-posts/1647962624)の `build.gradle` ファイルを修正します。
独自ライブラリを使用するために `dependencies` に `libs` ディレクトリないの jar ファイルを依存関係ライブラリとして定義します。

```groovy fn=java-sample/build.gradle
plugins {
    id 'java'
}

repositories {
    mavenCentral()
}

dependencies {
    implementation 'com.google.code.gson:gson:2.9.0'
    implementation 'com.amazonaws:aws-lambda-java-core:1.2.1'
    implementation fileTree(dir: 'libs', include: '*.jar')
}

task buildZip(type: Zip) {
    from compileJava
    from processResources
}

build.dependsOn buildZip
```

最後に、[サンプルの Lambda 関数](https://blog.grasswake.me/tech-posts/1647962624)から独自ライブラリの処理を呼び出すように修正します。

```java fn=java-sample/src/main/java/sample/App.java
package sample;

import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.RequestHandler;

// 独自ライブラリのインポート
import sample_lib.Util;

import java.util.Map;

public class App implements RequestHandler<Map<String, String>, String> {
  @Override
  public String handleRequest(Map<String, String> event, Context context) {
    // 独自ライブラリの処理の呼び出し
    Util.log(event, context);
    String response = new String("200 OK");
    return response;
  }
}
```

### デプロイパッケージの作成その 4

`gradle build` コマンドを実行してデプロイパッケージを作成します。

```bash
gradle build
```

`build/distributions` ディレクトリに zip 形式のデプロイパッケージが作成されます。
作成されたデプロイパッケージの中身は以下のように外部ライブラリがなくなり、クラスファイルのみになります。

```bash
$ unzip -l build/distributions/java-sample.zip
Archive:  build/distributions/java-sample.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
        0  03-21-2022 23:23   sample/
     1392  03-21-2022 23:23   sample/App.class
      528  03-21-2022 23:23   previous-compilation-data.bin
---------                     -------
     1920                     3 files
```

### Lambda 関数の更新と実行その 2

作成したデプロイパッケージを使って AWS マネジメントコンソールから Lambda 関数を更新することもできますが、今回は AWS CLI を使って Lambda 関数の更新をします。

```bash
aws lambda update-function-code --function-name java-sample --zip-file fileb://build/distributions/java-sample.zip
```

Lambda 関数を実行して、エラーが出ず以下のように出力されれば成功です。
また、Lambda 関数の CloudWatch Logs のロググループに `payload` の値などが出力されているはずです。

```bash
$ aws lambda invoke --function-name java-sample  \
--payload '{"text":"Hello"}' response.txt --cli-binary-format raw-in-base64-out
{
    "StatusCode": 200,
    "ExecutedVersion": "$LATEST"
}
```

## 参考情報

<https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/java-handler.html>

<https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/java-package.html>


Java + Gradle で Lambda レイヤー用のデプロイパッケージを作成する


Java は新卒時以降全く使っていなかったのですが、最近 Java で Lambda を作成する時色々ハマったので、作成手順をまとめました。

## Java + Gradle で Lambda 関数用のデプロイパッケージを作成する環境

- macOS: Catalina (10.15.7)
- JDK: Amazon Corretto 11 (Java 11 JDK)
- Gradle: 7.4.1

## Java + Gradle で Lambda 関数用のデプロイパッケージを作成する手順

### 作業用ディレクトリの作成とプロジェクトの初期化

作業ディレクトリを作成して、`gradle init` コマンドを実行します。
`gradle init` コマンド実行時の各設問は最初の 2 つ以外はデフォルト値にしています。

```bash
$ mkdir ~/java-sample
$ cd ~/java-sample
$ gradle init
Starting a Gradle Daemon (subsequent builds will be faster)

Select type of project to generate:
  1: basic
  2: application
  3: library
  4: Gradle plugin
Enter selection (default: basic) [1..4] 1

Select build script DSL:
  1: Groovy
  2: Kotlin
Enter selection (default: Groovy) [1..2] 1

Generate build using new APIs and behavior (some features may change in the next minor release)? (default: no) [yes, no]

Project name (default: java-sample):

> Task :init
Get more help with your project: Learn more about Gradle by exploring our samples at https://docs.gradle.org/7.4.1/samples

BUILD SUCCESSFUL in 16s
2 actionable tasks: 2 executed
```

`gradle init` コマンド実行後、ディレクトリ構成は以下のようになります。

```text
.
├── build.gradle
├── gradle
│   └── wrapper
│       ├── gradle-wrapper.jar
│       └── gradle-wrapper.properties
├── gradlew
├── gradlew.bat
└── settings.gradle
```

### Lambda 関数ハンドラーの作成

今回は、[Lambda のドキュメント](https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/java-handler.html)に記載されている[こちらのサンプル](https://github.com/awsdocs/aws-lambda-developer-guide/blob/main/sample-apps/java-basic/src/main/java/example/Handler.java)を実装してみます。

まず、`build.gradle` ファイルを以下のように修正します。
`dependencies` に今回使用するライブラリを定義します。
また、`task` でデプロイパッケージ(.zip ファイルアーカイブ)を作成するタスクを定義します。

```groovy
plugins {
    id 'java'
}

repositories {
    mavenCentral()
}

dependencies {
    implementation 'com.google.code.gson:gson:2.9.0'

    implementation 'com.amazonaws:aws-lambda-java-core:1.2.1'
}

task buildZip(type: Zip) {
    from compileJava
    from processResources
    into('lib') {
        from configurations.runtimeClasspath
    }
}

build.dependsOn buildZip
```

次に、Lambda ハンドラー関数用の Java ファイルを作成して[こちらのサンプル](https://github.com/awsdocs/aws-lambda-developer-guide/blob/main/sample-apps/java-basic/src/main/java/example/Handler.java)を作成します。

```bash
mkdir src/main/java/sample
touch src/main/java/sample/App.java
```

```java fn=src/main/java/sample/App.java
package sample;

import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.RequestHandler;
import com.amazonaws.services.lambda.runtime.LambdaLogger;

import com.google.gson.Gson;
import com.google.gson.GsonBuilder;

import java.util.Map;

public class App implements RequestHandler<Map<String, String>, String> {
  Gson gson = new GsonBuilder().setPrettyPrinting().create();

  @Override
  public String handleRequest(Map<String, String> event, Context context) {
    String response = new String("200 OK");
    LambdaLogger logger = context.getLogger();
    // log execution details
    logger.log("ENVIRONMENT VARIABLES: " + gson.toJson(System.getenv()));
    logger.log("CONTEXT: " + gson.toJson(context));
    // process event
    logger.log("EVENT: " + gson.toJson(event));
    logger.log("EVENT TYPE: " + event.getClass().toString());
    return response;
  }
}
```

### デプロイパッケージの作成

`gradle build` コマンドを実行してデプロイパッケージを作成します。

```bash
gradle build
```

`build/distributions` ディレクトリに zip 形式のデプロイパッケージが作成されます。
作成されたデプロイパッケージの中身は以下のようになっているかと思います。

```bash
$ unzip -l build/distributions/java-sample.zip
Archive:  build/distributions/java-sample.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
        0  03-21-2022 22:51   sample/
     2686  03-21-2022 22:51   sample/App.class
     1381  03-21-2022 22:51   previous-compilation-data.bin
        0  03-21-2022 22:51   lib/
   249277  03-20-2022 23:20   lib/gson-2.9.0.jar
     7515  03-20-2022 22:45   lib/aws-lambda-java-core-1.2.1.jar
---------                     -------
   260859                     6 files
```

## Lambda 関数の作成と実行

作成したデプロイパッケージを使って AWS マネジメントコンソールから Lambda 関数を作成することもできますが、今回は AWS CLI を使って Lambda 関数の作成をします。

```bash
aws lambda create-function --function-name java-sample \
--zip-file fileb://build/distributions/java-sample.zip --handler sample.App::handleRequest --runtime java11 \
--role <IAM ロール arn>
```

Lambda 関数を実行して、エラーが出ず以下のように出力されれば成功です。
また、Lambda 関数の CloudWatch Logs のロググループに `payload` の値などが出力されているはずです。

```bash
$ aws lambda invoke --function-name java-sample  \
--payload '{"text":"Hello"}' response.txt --cli-binary-format raw-in-base64-out
{
    "StatusCode": 200,
    "ExecutedVersion": "$LATEST"
}
```

## 参考情報

<https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/java-handler.html>

<https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/java-package.html>


Java + Gradle で Lambda 関数用のデプロイパッケージを作成する


Amazon Corretto 8 (Java 8 JDK) から Amazon Corretto 11 (Java 11 JDK) に移行した際のメモです。

## Amazon Corretto 11 (Java 11 JDK) をインストールする環境

- macOS: Catalina (10.15.7)
- JDK: Amazon Corretto 8 (Java 8 JDK)

```bash
$ java -version
openjdk version "1.8.0_322"
OpenJDK Runtime Environment Corretto-8.322.06.1 (build 1.8.0_322-b06)
OpenJDK 64-Bit Server VM Corretto-8.322.06.1 (build 25.322-b06, mixed mode)
```

## macOS に Amazon Corretto 11 (Java 11 JDK) をインストールする手順

### Amazon Corretto 11 (Java 11 JDK) のダウンロードとインストール

[ダウンロードページ](https://docs.aws.amazon.com/ja_jp/corretto/latest/corretto-11-ug/downloads-list.html)から macOS x64 用の pkg ファイルをダウンロードしてきます。
ダウンロードした pkg ファイルをダブルクリックしてインストールウィザードを開始し、ウィザードの手順に従ってインストールします。

<https://docs.aws.amazon.com/ja_jp/corretto/latest/corretto-11-ug/downloads-list.html>

### Amazon Corretto 11 (Java 11 JDK) の有効化

Amazon Corretto 11 (Java 11 JDK) は `/Library/Java/JavaVirtualMachines/` にインストールされます。
ターミナルで `/usr/libexec/java_home -V` を実行するとインストール済みの JDK 及び、インストールパスが一覧で確認できます。

```bash
$ /usr/libexec/java_home -V
Matching Java Virtual Machines (2):
    11.0.14.1, x86_64: "Amazon Corretto 11" /Library/Java/JavaVirtualMachines/amazon-corretto-11.jdk/Contents/Home
    1.8.0_322, x86_64: "Amazon Corretto 8" /Library/Java/JavaVirtualMachines/amazon-corretto-8.jdk/Contents/Home

/Library/Java/JavaVirtualMachines/amazon-corretto-11.jdk/Contents/Home
```

環境変数の `JAVA_HOME` に Amazon Corretto 11 (Java 11 JDK) のインストールパスを設定します。
お使いの shell の設定ファイルに定義しておくのが良いと思います。
自分は zsh を使っているので、以下を .zshrc に書いておきます。

```bash
export JAVA_HOME=/Library/Java/JavaVirtualMachines/amazon-corretto-11.jdk/Contents/Home
```

シェルをリセットします。

```bash
exec $SHELL -l
```

Amazon Corretto 11 (Java 11 JDK) がデフォルトで使われることを確認できたら終わりです。

```bash
$ java -version
openjdk version "11.0.14.1" 2022-02-08 LTS
OpenJDK Runtime Environment Corretto-11.0.14.10.1 (build 11.0.14.1+10-LTS)
OpenJDK 64-Bit Server VM Corretto-11.0.14.10.1 (build 11.0.14.1+10-LTS, mixed mode)
```

### Amazon Corretto 11 (Java 11 JDK) のアンインストールについて

Amazon Corretto 11 (Java 11 JDK) をアンインストールするには、以下のコマンドを実行します。

```bash
cd /Library/Java/JavaVirtualMachines/
sudo rm -rf amazon-corretto-11.jdk
```


macOS に Amazon Corretto 11 (Java 11 JDK) をインストールする


## API Gateway のアクセス元を CloudFront のみに許可したい

Cloudfront の オリジンとして API Gateway を使用する構成において、API Gateway 側で CloudFront からのアクセスのみを許可したい場合に、どんな方法があるか調べてみた。

## API Gateway(REST API) のアクセス元を CloudFront のみに許可する 2 つの方法

### 方法その 1: API Gateway の API キー認証を使う

API Gateway にて API の実行に API キーを必須に設定し、CloudFront のカスタムヘッダーとして API キーを送信するように設定することで、特定の CloudFront ディストリビューションからのアクセスのみ許可する方法となります。[^1]

[^1]: [カスタム CloudFront ディストリビューションで API Gateway をセットアップする](https://aws.amazon.com/jp/premiumsupport/knowledge-center/api-gateway-cloudfront-distribution/)

### 方法その 2: API Gateway のリソースポリシーと AWS\:Referer を使う

API Gateway のリソースポリシーにて API の実行に AWS:Referer 値が特定の文字列であることを条件に設定し、CloudFront のカスタムヘッダーとして Referer リクエストヘッダーをオリジン(API Gateway)に送信するように設定することで、特定の CloudFront ディストリビューションからのアクセスのみ許可する方法となります。

## API Gateway(REST API) のアクセス元を CloudFront のみに許可する 2 つの方法の留意点

### 方法その 1 (API Gateway の API キー認証を使う)の留意点

- API キーは API Gateway のリソースとメソッドの組み合わせ毎に設定する必要があります。
  自分が調べた限り、現時点(2022/09)時点で全てのリソースとメソッドの組み合わせに一括で API キーを必須にすることはできません。
  そのため、リソースとメソッドの組み合わせが追加されるたびに、都度その　 API キーの設定を有効にする必要があります。
- 使用できない一例: API キーを複数発行し、顧客に配布し、顧客はその API キーを使って API を実行するといった API キー及び使用量プランの本来の使い方?をする場合

### 方法その 2 (API Gateway のリソースポリシーと AWS\:Referer を使う)の留意点

- API キー認証の時と違い、こちらの方法では、API 全体に対して制限をかけることが可能なため、リソースとメソッドの組み合わせが追加される度に設定を行う必要がありません。
  一方で、特定のリソースとメソッドの組み合わせに対してアクセス制限を適用したくないなどの場合は、リソースポリシーの変更が必要となります。
- 使用できない一例: オリジンリクエストポリシーにて Referer リクエストヘッダーをオリジン(API Gateway)へ送信し、Lambda などのバックエンド側でクライアント側で設定された Referer リクエストヘッダーを参照する必要がある場合

## 事前準備

### API Gateway の作成

API タイプは REST API で API Gateway を作成します。
リソース設定は、ルートパスに GET メソッドを作成します。
統合リクエストは、統合タイプとして [**Mock**] 選択して作成します。

![リソース設定](/images/posts/tech-posts/1646529783/get_method.png)

API を任意のステージにデプロイします。
デプロイ後、 ステージエディター画面の上部にある `Invoke URL`(API Gateway API を呼び出すための URL) をメモしておきます。

![API ステージ](/images/posts/tech-posts/1646529783/api_stage.png)

ここまでの設定に問題がなければ API が実行できるはずです。
一旦、curl など API が **200 OK** レスポンスを返すことを確認しておきます。

```bash
$ curl -X GET -I  https://xxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/prod
HTTP/2 200
date: Sun, 06 Mar 2022 02:39:23 GMT
content-type: application/json
content-length: 0
x-amzn-requestid: 46533423-7524-481e-9b47-9a48a83e9aa4
x-amz-apigw-id: OinCTHqDNjMFftQ=
```

### CloudFront の作成とカスタムヘッダー(Referer)の設定

オリジンリクエストポリシーを作成後、CloudFront ウェブディストリビューションを作成します。
[オリジンドメイン]は API の `invoke URL` を指定します。
因みに、選択肢として `invoke URL` は表示されないので、直接入力する必要があります。

[オリジンパス]は省略可能です。
ここでは、API のステージ名(prod)を指定しています。
これは、API 呼び出し時にステージ名を指定したいか否かで変わります。
API を呼び出すときにステージ名を自分で入力する場合は、[オリジンパス]を入力する必要はありません。

![CloudFront 作成 1](/images/posts/tech-posts/1646529783/create_cloudfront_1.png)
![CloudFront 作成 2](/images/posts/tech-posts/1646529783/create_cloudfront_2.png)

## API キーを使って API Gateway のアクセス元を CloudFront のみに許可する手順

### API キー必須化

事前準備の API Gateway で作成した GET メソッドの[**メソッドリクエスト**]で [**API キーの必要性**] を `true` に設定し、API キーの使用を有効化しておきます。

![API キー必須化](/images/posts/tech-posts/1646529783/require_api_key.png)

### 使用量プランの設定と API キーの作成

使用量プランを作成します。
スロットリング[^2]とクォータ[^2]それぞれの制限はデフォルトで有効化されていますが、顧客に API を公開して制限をかけるなどの要件がなく、特に制限する必要がなければ無効化することもできます。

[^2]: [API キーを使用した使用量プランの作成と使用 \- Amazon API Gateway](https://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/api-gateway-api-usage-plans.html)

![使用量プラン作成](/images/posts/tech-posts/1646529783/usage_plan.png)

[**API ステージの追加**]ボタンをクリックして、API キーの作成と使用量プランへの紐付けを行います。

![API キー追加後](/images/posts/tech-posts/1646529783/add_api_key.png)

設定完了後に作成した API キーの画面で [表示] をクリックして表示される API キー値をメモしておきます。

![API キー確認](/images/posts/tech-posts/1646529783/show_api_key.png)

一旦ここで設定がうまくいっているか動作確認してみます。
まず、API キーをしているパターンを実行し、**200 OK** レスポンスを返すことを確認します。
API キーは HTTP ヘッダーに `x-api-key` というヘッダー名で付与します。

```bash
$ curl -I -X GET  https://xxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/prod -H 'x-api-key: <API キー値>'
HTTP/2 200
date: Sun, 06 Mar 2022 04:06:26 GMT
content-type: text/html
content-length: 1310
x-amzn-requestid: 27cf9c40-a378-48c4-aa42-a293ac5e5f99
x-amz-apigw-id: OizyaHnGNjMFSxQ=
```

因みに、`x-api-key` ヘッダーを付与していない場合、ステータスコードが `403` の `ForbiddenException` エラーを返します。

```bash
$ curl -I -X GET  https://xxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/prod
HTTP/2 403
date: Sun, 06 Mar 2022 04:06:24 GMT
content-type: application/json
content-length: 23
x-amzn-requestid: 7fca17f5-f15c-4c7b-98aa-a6e802f91ed4
x-amzn-errortype: ForbiddenException
x-amz-apigw-id: OizyLF_LtjMF30w=
```

### CloudFront のカスタムヘッダー(x-api-key)の設定

[カスタムヘッダーを追加]で `x-api-key` というヘッダー名で API キー値を追加します。

![x_api_key の設定](/images/posts/tech-posts/1646529783/api_setting.png)

### API キーの動作確認

動作確認してみます。
CloudFront の URL で API を呼び、**200 OK** レスポンスを返ってくれば成功です。

```bash
$ curl -I -X GET  https://xxxxxxxxxxxxx.cloudfront.net -H 'x-api-key: <API キー値>'
HTTP/2 200
content-type: text/html
content-length: 1310
vary: Accept-Encoding
date: Sun, 06 Mar 2022 05:12:30 GMT
x-amzn-requestid: bd9d0322-ba24-44ed-9553-de4858ec9536
x-amz-apigw-id: Oi9duGUWtjMFm8g=
x-cache: Miss from cloudfront
via: 1.1 fcdc790e9970e122cf39adadda463c14.cloudfront.net (CloudFront)
x-amz-cf-pop: NRT20-C4
x-amz-cf-id: 4z_1D1-ecgMQKc7plvtbL-c1e0Vx9dosRbklBpr3HRmWoqdGLoA1uw==
```

## API Gateway のリソースポリシーと AWS:Referer を使って API Gateway のアクセス元を CloudFront のみに許可する手順

### リソースポリシーの設定

API Gateway のリソースポリシーを以下のように設定します。
コンソール上から入力せいて保存すると `Resouce` の部分が自動的に以下のような `arn` に変換してくれます。
`arn:aws:execute-api:<Region>:<AWS アカウント ID>:<API ID>/*`

```json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Principal": "*",
      "Action": "execute-api:Invoke",
      "Resource": "execute-api:/*",
      "Condition": {
        "StringNotEquals": {
          "aws:Referer": "<適当な文字列>"
        }
      }
    },
    {
      "Effect": "Allow",
      "Principal": "*",
      "Action": "execute-api:Invoke",
      "Resource": "execute-api:/*"
    }
  ]
}
```

一旦ここで設定がうまくいっているか動作確認してみます。
まず、Referer リクエストヘッダーを設定しているパターンを実行し、200 OK レスポンスを返すことを確認します。

```bash
$ curl -I -X GET https://xxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/prod -H 'referer: <リソースポリシーに設定した適当な文字列>'
HTTP/2 200
date: Tue, 20 Sep 2022 08:46:56 GMT
content-type: application/json
content-length: 0
x-amzn-requestid: 53309964-1549-48c9-8e5f-512a282f03a8
x-amz-apigw-id: YwCgFGHVtjMFieg=
```

因みに、Referer ヘッダーを付与していない場合、ステータスコードが 403 の ForbiddenException エラーを返します。

```bash
$ curl -I -X GET https://xxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/prod
HTTP/2 403
date: Tue, 20 Sep 2022 08:47:16 GMT
content-type: application/json
content-length: 182
x-amzn-requestid: 0e2809c8-2295-44f0-b3b5-6db8fdca4b1f
x-amzn-errortype: AccessDeniedException
x-amz-apigw-id: YwCjKF8jNjMFTfg=
```

### CloudFront のカスタムヘッダー(Referer)の設定

[カスタムヘッダーを追加]で `Referer` というヘッダー名でリソースポリシーに設定した適当な文字列値を追加します。

![refere の設定](/images/posts/tech-posts/1646529783/referer_setting.png)

なお、オリジンリクエストポリシーにて Referer リクエストヘッダーを設定している場合、以下のようなエラーが発生します。
`The paramater Header Name with value Referer is not allowed as both as origin custom header and a forward header`

![refere の設定エラー](/images/posts/tech-posts/1646529783/referer_setting_error.png)

### Referer の動作確認

動作確認してみます。
CloudFront の URL で API を呼び、**200 OK** レスポンスを返ってくれば成功です。

```bash
$ curl -I -X GET https://xxxxxxxxxxxxx.cloudfront.net/
HTTP/2 200
content-type: application/json
content-length: 0
date: Tue, 20 Sep 2022 08:49:51 GMT
x-amzn-requestid: e4752a73-95b0-462a-b643-512198da6475
x-amz-apigw-id: YwC7dGMCNjMFS-w=
x-cache: Hit from cloudfront
via: 1.1 1ec5c4b165968f8e5c872b374a497e8e.cloudfront.net (CloudFront)
x-amz-cf-pop: NRT57-P2
x-amz-cf-id: TjTMUnRNKNCro-IifX67z5YnW3L0CcinXiTr0UAEMt6FPhDWXpKU_Q==
age: 46
```


API Gateway(REST API) のアクセス元を CloudFront のみに許可するには


## Amplify CLI でカスタムリソースとして Lambda をトリガーする SQS キューを作成する

Amplify CLI では `amplify add function` のような SQS を追加するコマンドは存在しません。
また、 `amplify add function` 実行時に、Lambda 関数のトリガー設定に関する以下のような質問が出ますが選択肢として SQS はありません。

```bash
$ amplify add function
? Choose the function template that you want to use: Lambda trigger
? What event source do you want to associate with Lambda trigger? (Use arrow keys)
❯ Amazon DynamoDB Stream
  Amazon Kinesis Stream
```

SQS のような Amplify CLI ではサポートされていない他のリソースを作成する場合は、「カスタム」機能を利用する必要があります。[^1]
この「カスタム」機能では、カスタムリソースの定義方法として AWS CDK[^2] と CloudFormation[^3] の 2 種類がありますがそれぞれの方法で Lambda 関数をトリガーする SQS キューの作成と設定をしてみます。

[^1]: [AWS CDK または CloudFormation を使用し、カスタム AWS リソースで Amplify バックエンドを拡張する新機能「カスタム」のご紹介 \| Amazon Web Services ブログ](https://aws.amazon.com/jp/blogs/news/extend-amplify-backend-with-custom-aws-resource-using-aws-cdk-or-cloudformation/)
[^2]: [Custom AWS resources \- Use CDK to add custom AWS resources \- AWS Amplify Docs](https://docs.amplify.aws/cli/custom/cdk/)
[^3]: [Custom AWS resources \- Use CloudFormation to add custom AWS resources \- AWS Amplify Docs](https://docs.amplify.aws/cli/custom/cloudformation/)

## Amplify CLI でカスタムリソースとして Lambda をトリガーする SQS キューを作成する手順

### 開発環境

- Amplify CLI: 7.6.22

### 作業ディレクトリの作成と初期化

まず、作業ディレクトリを作成し、Amplify プロジェクトを初期化します。

```bash
mkdir ~/sqs-lambda
cd ~/sqs-lambda
amplify init -y
```

### Lambda 関数の作成と SQS へのアクセス許可の付与

`amplify add function` コマンドで Lambda 関数を作成します。
取り敢えずここでは実行できればいいの、Hello World テンプレートを使用します。

```bash
$ cd ~/sqs-lambda
$ amplify add function
? Select which capability you want to add: Lambda function (serverless function)
? Provide an AWS Lambda function name: handleNotifySQS
? Choose the runtime that you want to use: NodeJS
? Choose the function template that you want to use: Hello World

Available advanced settings:
- Resource access permissions
- Scheduled recurring invocation
- Lambda layers configuration
- Environment variables configuration
- Secret values configuration

? Do you want to configure advanced settings? No
? Do you want to edit the local lambda function now? No
```

`amplify/backend` ディレクトリに Lambda 関数(`handleNotifySQS`)が追加されます。

```text
.
└── amplify
    └── backend
        └── function
            └── handleNotifySQS
                ├── amplify.state
                ├── custom-policies.json
                ├── dist
                │   └── latest-build.zip
                ├── function-parameters.json
                ├── handleNotifySQS-cloudformation-template.json
                └── src
                    ├── event.json
                    ├── index.js
                    ├── node_modules
                    ├── package.json
                    └── yarn.lock
```

Lambda 関数には SQS キューからメッセージを読み取るためのアクセス許可が必要です。
付与するアクセス許可は AWS マネージドポリシーの AWSLambdasqsqueueExecutionRole[^4] を参考にします。
CloudWatch Logs に関するアクセス許可はすでに定義済みなので、残りの以下の 3 つのアクションのアクセス許可を追加します。

- `sqs:ReceiveMessage`
- `sqs:DeleteMessage`
- `sqs:GetQueueAttributes`

[^4]: [AWS Lambda 実行ロール \- AWS Lambda](https://docs.aws.amazon.com/ja_jp/ja_jp/lambda/latest/dg/lambda-intro-execution-role.html#permissions-executionrole-features)

```yaml fn=amplify/backend/function/handleNotifySQS/handleNotifySQS-cloudformation-template.json
'lambdaexecutionpolicy':
  {
    'DependsOn': ['LambdaExecutionRole'],
    'Type': 'AWS::IAM::Policy',
    'Properties':
      {
        'PolicyName': 'lambda-execution-policy',
        'Roles': [{ 'Ref': 'LambdaExecutionRole' }],
        'PolicyDocument':
          {
            'Version': '2012-10-17',
            'Statement':
              [
                {
                  'Effect': 'Allow',
                  'Action':
                    [
                      'logs:CreateLogGroup',
                      'logs:CreateLogStream',
                      'logs:PutLogEvents',
                    ],
                  'Resource':
                    {
                      'Fn::Sub':
                        [
                          'arn:aws:logs:${region}:${account}:log-group:/aws/lambda/${lambda}:log-stream:*',
                          {
                            'region': { 'Ref': 'AWS::Region' },
                            'account': { 'Ref': 'AWS::AccountId' },
                            'lambda': { 'Ref': 'LambdaFunction' },
                          },
                        ],
                    },
                },
                {
                  'Effect': 'Allow',
                  'Action':
                    [
                      'sqs:ReceiveMessage',
                      'sqs:DeleteMessage',
                      'sqs:GetQueueAttributes',
                    ],
                  'Resource': '*',
                },
              ],
          },
      },
  }
```

### CloudFormation で SQS をカスタムリソースとして作成する方法

`amplify add custom` コマンドでカスタムリソースを作成します。
カスタムリソースの定義方法として AWS CloudFormation を選択してください。

```bash
$ cd ~/sqs-lambda
$ amplify add custom
✔ How do you want to define this custom resource? · AWS CloudFormation
✔ Provide a name for your custom resource · notifySQSByCfn
✔ Do you want to access Amplify generated resources in your custom CloudFormation file? (y/N) · yes
? Select the categories you want this custom resource to have access to. function
✅ Created skeleton CloudFormation stack in amplify/backend/custom/notifySQSByCfn directory
✔ Do you want to edit the CloudFormation stack now? (Y/n) · no
```

`amplify/backend/custorm` ディレクトリにカスタムリソース(`notifySQSByCfn`)が追加されます。

```text
.
└── amplify
    └── backend
        └── custom
            └── notifySQSByCfn
                └── notifySQSByCfn-cloudformation-template.json
```

json 形式の CloudFormation テンプレートで SQS キューと Lambda のイベントソースマッピングを定義します。

```json fn=amplify/custom/notifySQSByCfn/notifySQSByCfn-cloudformation-template.json
{
  "AWSTemplateFormatVersion": "2010-09-09",
  "Parameters": {
    "env": {
      "Type": "String"
    },
    "functionhandleNotifySQSName": {
      "Type": "String",
      "Description": "Input parameter describing Name attribute for function/handleNotifySQS resource"
    },
    "functionhandleNotifySQSArn": {
      "Type": "String",
      "Description": "Input parameter describing Arn attribute for function/handleNotifySQS resource"
    },
    "functionhandleNotifySQSRegion": {
      "Type": "String",
      "Description": "Input parameter describing Region attribute for function/handleNotifySQS resource"
    },
    "functionhandleNotifySQSLambdaExecutionRole": {
      "Type": "String",
      "Description": "Input parameter describing LambdaExecutionRole attribute for function/handleNotifySQS resource"
    }
  },
  "Resources": {
    "NotifySQSByCfn": {
      "Type": "AWS::SQS::Queue"
    },
    "LambdaFunctionEventSourceMapping": {
      "Type": "AWS::Lambda::EventSourceMapping",
      "Properties": {
        "BatchSize": 10,
        "Enabled": true,
        "EventSourceArn": {
          "Fn::GetAtt": ["NotifySQSByCfn", "Arn"]
        },
        "FunctionName": {
          "Ref": "functionhandleNotifySQSArn"
        }
      }
    }
  },
  "Outputs": {}
}
```

### AWS SDK で SQS をカスタムリソースとして作成する方法

`amplify add custom` コマンドでカスタムリソースを作成します。
カスタムリソースの定義方法として AWS CDK を選択してください。

```bash
$ cd ~/sqs-lambda
$ amplify add custom
✔ How do you want to define this custom resource? · AWS CDK
✔ Provide a name for your custom resource · notifySQSByCDK
✅ Created skeleton CDK stack in amplify/backend/custom/notifySQSByCDK directory
✔ Do you want to edit the CDK stack now? (Y/n) · no
```

`amplify/backend/custorm` ディレクトリにカスタムリソース(`notifySQSByCDK`)が追加されます。

```text
.
└── amplify
    └── backend
        └── custom
            └── notifySQSByCDK
                ├── build
                │   ├── cdk-stack.js
                │   └── notifySQSByCDK-cloudformation-template.json
                ├── cdk-stack.ts
                ├── node_modules
                ├── package.json
                ├── tsconfig.json
                └── yarn.lock
```

`package.json` を編集して、必要なパッケージを追加してついでに使わないパッケージを削除します。
`aws-sdk` のバージョンが `1.124` と古いですが、今回やることには支障がないのでそのままで行きます。

```json fn=amplify/custom/notifySQSByCDK/package.json
{
  "name": "custom-resource",
  "version": "1.0.0",
  "description": "",
  "scripts": {
    "build": "tsc",
    "watch": "tsc -w",
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "dependencies": {
    "@aws-amplify/cli-extensibility-helper": "^2.0.0",
    "@aws-cdk/core": "~1.124.0",
    "@aws-cdk/aws-sqs": "~1.124.0",
    "@aws-cdk/aws-lambda": "~1.124.0"
  },
  "devDependencies": {
    "typescript": "^4.2.4"
  }
}
```

`package.json` を編集したら、パッケージを再インストールします。

```bash
cd ~/sqs-lambda/amplify/custom/notifySQSByCDK
yarn install --check-files
```

スタックファイル(`cdk-stack.ts`)に SQS キューと Lambda のイベントソースマッピングを定義します。

```typescript fn=amplify/custom/notifySQSByCDK/cdk-stack.ts
import * as cdk from '@aws-cdk/core'
import * as AmplifyHelpers from '@aws-amplify/cli-extensibility-helper'
import { AmplifyDependentResourcesAttributes } from '../../types/amplify-dependent-resources-ref'
import { Queue } from '@aws-cdk/aws-sqs'
import { Function, EventSourceMapping } from '@aws-cdk/aws-lambda'

export class cdkStack extends cdk.Stack {
  constructor(
    scope: cdk.Construct,
    id: string,
    props?: cdk.StackProps,
    amplifyResourceProps?: AmplifyHelpers.AmplifyResourceProps
  ) {
    super(scope, id, props)
    /* Do not remove - Amplify CLI automatically injects the current deployment environment in this input parameter */
    new cdk.CfnParameter(this, 'env', {
      type: 'String',
      description: 'Current Amplify CLI env name',
    })

    const queue = new Queue(this, 'notifySQSByCDK', {})

    const dependencies: AmplifyDependentResourcesAttributes =
      AmplifyHelpers.addResourceDependency(
        this,
        amplifyResourceProps.category,
        amplifyResourceProps.resourceName,
        [{ category: 'function', resourceName: 'handleNotifySQS' }]
      )

    const lambdaArn = cdk.Fn.ref(dependencies.function.handleNotifySQS.Arn)
    const target = Function.fromFunctionArn(this, 'handleNotifySQS', lambdaArn)
    const eventSourceMapping = new EventSourceMapping(
      this,
      'NotifySQSByCDKEventSourceMapping',
      {
        target,

        // the properties below are optional
        batchSize: 10,
        enabled: true,
        eventSourceArn: queue.queueArn,
      }
    )
  }
}
```

スタックファイル(`cdk-stack.ts`) を編集したら、`amplify build` コマンドでビルドを実行します。

```bash
cd ~/sqs-lambda
amplify build
```

### Lambda 関数と SQS のデプロイ

`amplify push` コマンドでデプロイを実行します。

```bash
cd ~/sqs-lambda
amplify push
```

AWS マネジメントコンソールで Lambda 関数と SQS キューが作成されていることを確認します。

![Lambda 一覧](/images/posts/tech-posts/1645975738/lambda_list.png)

![SQS 一覧](/images/posts/tech-posts/1645975738/sqs_list.png)

### 動作確認

動作確認してみます。
まず、各 SQS キューからテストメッセージを送信します。

![テストメッセージ1](/images/posts/tech-posts/1645975738/test_from_notify_sqs_by_cfn.png)

![テストメッセージ2](/images/posts/tech-posts/1645975738/test_from_notify_sqs_by_cdk.png)

テストメッセージ送信後、Lambda 関数の CloudWatch Logs で送信したメッセージが確認できれば動作確認完了です。

![テスト結果1](/images/posts/tech-posts/1645975738/cw_from_notify_sqs_by_cfn.png)

![テスト結果2](/images/posts/tech-posts/1645975738/cw_from_notify_sqs_by_cdk.png)
