メモ）EFSとLambdaの調査

AWS公式に謳われてるようにEFSはCMSやサーバレス環境で特に有用だと思います。今後利用する機会が増えそうなので幾つか気になっていたことを調査しました。

Terraformコード

リソース単位で書いていたのを1ファイルに転記したので多少抜けてる所はあるかもですがGistに記述。

gist.github.com

Lambda（NodeJS）のEFS接続確認

マネジメントコンソールのLambda→テストでサクッと確認。パーミッション、セキュリティグループ、VPCなどなどエラーになりそうなポイントが多くて意外と詰まります。

const fs = require('fs');

async function testRead(){
    return new Promise((resolve) => {
        fs.readdir('/mnt/efs', 'UTF-8', (result, error) => {
            console.log(error)
            resolve()
        })
    })
}
async function testWrite(){
    return new Promise((resolve) => {
        fs.writeFile('/mnt/efs/test.txt', 'hello', (error) => {
            resolve()
        })
    })
}
exports.handler = async (event, context) => {
    await testRead()
    await testWrite()
    await testRead()
    return {}
}

バックアップ取得

AWS Backupからオンデマンドバックアップを取ろうとした所なぜか下記のエラーが出ました。

does not have sufficient permissions to execute the backup.

EFSの画面に戻って自動バックアップを有効にすると解消しました🤔

バックアップから復元

まず、「完全な復元」→「ソースファイルシステムのディレクトリに復元する」を選択。データがほぼないせいか2分くらいで復元が完了。

続いて「ファイルシステムを新たに復元する」を選択し実行。復元完了後にEFSの方を見ると新しいファイルシステムが作成されており、VPCやアクセスポイントは空っぽのままだったので再設定が必要のようです。

障害発生からの復旧を目的とするようなケースではバックアップ≒スナップショットと考えて「完全な復元」→「ソースファイルシステムのディレクトリに復元する」の方がベターかもしれません。

まとめ

フルマネージドなファイルシステムと言いつつもLambdaとかCMSのライトな用途に使えるのが嬉しい。

ちなみにEC2のインスタンス作成時にEFSマウントが手軽に設定できるようになってるので確認環境は手軽に作れます。