はじめに
こんにちは。普段は@niftyトップページの開発運用をしている宮本です。
最近git worktreeで並行して開発していたところ、.terraform や node_modules フォルダが大量に作成され、気づいたらPCのストレージが限界に近づいていました。便利で多用していたのですが、掃除をしないと思わぬ落とし穴がありますね。
さて、今回の記事では自分が開発運用担当している一部のサイトで利用しているAmplifyについて、1年以上運用してみた感想について紹介させていただきます。
AWS Amplify
AWS Amplify（以下Amplify）はフロントからバックエンドまでを一括で管理できるマネージドサービスです。
サイト運用に必要なAWSリソースを裏側で準備してくれるだけでなく、Gitリポジトリと連携することでブランチごとのサイトの状態を確認できたりすることが大きな特徴です。
前提
この記事ではAmplifyを利用してサイトを1年以上運用してきた経験を元に記述していますが、以下のようなサイトを運用しています。
- Astro製SSGのWebサイトの運用がメイン
- Next.jsを用いたSSRは一部サイトのみ利用
- CognitoやDynamoDBなどの各種AWSリソースの利用は無し
- GitHub連携を利用
- AWS Amplify CLIは未利用
特にAmplifyを利用する際に大きな利点となりそうな他のAWSリソースとの組み合わせは試したことがないため、これについては触れません。
便利だった点
- 手軽にサイトを立てることができる
- PRごとに自動でサイトを作ることができる
- ブランチごとに環境変数を設定することができる
- Basic認証が機能として用意されている
手軽にサイトを立てることができる
Amplifyを作成してビルド設定のファイルを用意してリポジトリと接続するだけでサイトを作れるため、特にSSRを用いるサイトだとコンテナ周りの煩雑な準備をせずに済むのが楽でした。
一方で、以下のような条件が重なった場合は必ずしも最も手軽とは言い切れないようにも感じました。
- 単純なs3+CloudFrontのみで事足りるようなSSGサイト
- AWS CDKなどのIaCツールを利用して運用することを前提にしている
特に単純な静的サイト用のIaCコードは簡単にAI生成できるため、リソースの準備は比較的容易です。リソースに加えてサイトのビルド+アップロードの構築もありますが、これもGitHub Actionsを用いることで比較的簡単に準備できると感じました。
PRごとに自動でサイトを作ることができる
Amplifyを使っていて特に便利だった機能です。
コード変更をしてPRを提出した際、PRごとに専用に新しく割り振られたドメインでサイトの確認が可能になります。
マージ前に変更内容を確認するために、ローカルでブランチを切り替えずとも確認できるサイトが自動でデプロイされるのはとてもありがたかったです。
この辺りを自力で作ろうとするのはかなり大変なので、明確にAmplifyの利点だと感じました。
ブランチごとに環境変数を設定することができる
本番・ステージング・開発環境と複数の環境を常に用意していると、環境によってサイト自体の動作を変更したいケースがあります。
担当しているサイトではCMSを用いて運用していたため、一部の環境では本番公開前のデータを取得し、また開発環境では開発環境のCMSからデータを取得したいということがありました。
このときAmplifyアプリそのものを分けずともブランチごとの設定で分けられるのは便利でした。
Basic認証が機能として用意されている
本番環境以外を一般公開しないようにするため、デフォルトでBasic認証を仕掛けることができるのは便利でした。
デフォルトで組み込まれていない場合はWAFを設定したり、前段にCloudFrontを用意した上でCloudFront Functionsで制御する等々が必要になり、またブランチやPRごとに自動で作成されるサイトには追加することができないため一気に扱い辛くなっていたと思います。
詰まった点・もう少し便利だと嬉しい点
- リダイレクトでワイルドカードを利用できる箇所が限られる
- IaC管理しようとするとやや複雑
- ビルド通知を使いやすくしようとするとやや手間がかかる
- ビルド時のログを出力できない
- Git上のブランチに必ず依存する
IaC管理しようとするとやや複雑
基本的にリソースは全てIaCで管理するようにしているのですが、Amplify自体の管理がやや複雑でした。TerraformとAWS CDKどちらも利用して作成したことがありますが、Amplify管理についてはこの二つの差はあまり感じませんでした。
IaCで管理しようとした場合、Amplify本体のリソースとブランチごとの環境を定義する必要があり少々記述量が多くなります。また、GitHubリポジトリとの接続でリソース作成時はPAT認証が必要になるなど、引っかかる点もありました。
この辺り、簡単にリソースを作成して煩わしさを省くためのAmplifyなので、厳格さを求めるIaCとは若干相性が悪いようにも感じました。
ビルド通知を使いやすくしようとすると手間がかかる
Amplifyのビルド通知は、デフォルトではemailのみ対応しています。効率を考えるとslack等に流したいですが、機能としては存在しません。
ビルド自体はEventBridgeをトリガーに検知することができるため、そこからLambdaなどを使うことで通知することはできます。興味がある方は以前書いた記事をご参照ください。
ただ、そもそも必要なリソースを設定一つで用意できるのがAmplifyの利点にもかかわらず、別途細かい仕様を把握しリソースを作る必要があるという点が少々煩わしく感じました。
ビルド時のログをCloudWatchに出力できない
Amplifyは連携されたコードを元に、Amplify上でコードをビルドしたものをサイトとして公開します。ここで厄介なのが、ビルド時のログそのものはAmplifyのコンソール画面でしか確認できない点です。
SSRでアクセス時に出力されるアプリケーションログはCloudWatch Logsに出力することができますが、ビルド時のログはCloudWatch Logsには出力されません。
よってSSGのサイトなどでビルド時にデータ取得に失敗した場合なども、どこで異常が発生したのかコンソールからたどる必要がある点が運用を考えると少々手間です。
もっとも、これについてはGitHub actionsなどでビルドする場合も同じかもしれません。普段AWSを使っているとCloudWatch Logsからアラートを流しているからこそ、少々物足りなく感じた部分もありました。
Git上のブランチに必ず依存する
AmplifyのデプロイはGit上のブランチに紐づいていて便利ですが、このブランチがなくなると環境が消えてしまいます。
本番稼働ブランチなど設定することはできますが、特に保護されているわけでもなく依存しているブランチが消えた場合は該当のブランチの環境は容赦無く削除されます。
よって、本番で動作しているブランチについては確実にGitHubのブランチ保護のルールを仕掛けましょう。初歩的すぎてAmplifyを使わずとも注意すべき当たり前のことではありますが、Amplifyの場合はブランチの誤削除がダイレクトにサイトそのものの存在と直結します。そのためリスクは普段以上に大きく注意が必要です。
特に多くのサイトを管理している場合、うっかり一つでも保護漏れがないか注意しましょう。
まとめ
正直なところAmplifyの機能のさわり程度しかまだ利用していませんが、さわり程度でもPRプレビュー機能などかなり便利に感じる箇所は多いです。ECSで動作させているサイトでPRごとに環境を用意しようとした場合、環境の準備はもちろんデプロイトリガーの用意など考えることは多く、これを設定のチェック一つで実現してしまう点は非常に強力に感じました。
一方で物足りなく感じる点もあり、ビルドログやビルド通知などAmplify内で多くのことを自動的に処理してしまっているからこそ、そこをカスタマイズしようとすると思った以上に手間がかかったり、そもそも対応できないケースなどが出てきます。
この辺りは単にサイトをデプロイするだけでなく運用も踏まえて考えないと後から躓くポイントになりかねないので、少々厄介なポイントだと思います。
とはいえAmplify自体の機能アップデートも続いており、例えば以前はAmplifyにWAFを直接紐づけられなかったのですが、これも2025年にはGAされています。今後も不便に感じていたポイントがアップデートで解消される可能性もあるので、機能アップデートには注視していきたいです。
