Amplify概要

この章では、AWSのフロントエンドホスティングサービスであるAWS Amplifyについて学びます。これにより、GitHub連携による自動デプロイ・プレビュー環境・ビルド設定など、フロントエンドの配信基盤を使いこなす基本が理解できます。

1. 本章の概要

1.1 本章の目的

フロントエンドアプリケーションのデプロイに、EC2やS3+CloudFrontを組み合わせる方法もありますが、GitHub連携やプレビュー環境などの実務機能を自分で組み立てる手間がかかります。AmplifyはこれらをAWS側でまとめて提供してくれるサービスで、フロントエンドの配信に特化した選択肢です。

1.2 本章で学ぶ内容

Amplify Hostingの仕組みとデプロイの流れ、GitHubとの連携による自動デプロイ、ビルド設定のカスタマイズを扱います。あわせて、プレビュー環境の構築や、EC2・S3+CloudFront・ECS/Fargateといった他のデプロイ方法との使い分けも押さえます。

2. フロントエンドホスティングの選択肢

2.1 フロントエンドのホスティングとは

Webアプリケーションは、大きく分けてフロントエンド（ユーザが操作する画面部分）とバックエンド（データ処理やAPI）で構成されます。

フロントエンドをAWS上にデプロイする方法はいくつかあります。これまでのセクションで学んだ方法と、それぞれの課題を整理してみましょう。

1つ目はEC2に直接デプロイする方法です。EC2インスタンス上にNode.jsをインストールし、Next.jsなどのアプリケーションを起動します。この方法は自由度が高い反面、OSのアップデート、セキュリティパッチの適用、プロセスの監視、スケーリングの設定など、サーバの運用・保守をすべて自分で行う必要があります。フロントエンドのデプロイのためにサーバを管理し続けるのは、運用負荷が大きくなりがちです。

2つ目はS3 + CloudFrontで静的ファイルを配信する方法です。ビルド済みのHTMLやJavaScriptをS3に配置し、CloudFrontで配信する構成は、静的サイトやSPA（Single Page Application）には適しています。しかし、ページにアクセスするたびにサーバ側でHTMLを生成するような、サーバサイドの処理を伴うアプリケーションには対応できません。

こうした課題を解決し、フロントエンドアプリケーションを手軽にデプロイ・ホスティングするためのサービスがAWS Amplifyです。サーバの管理が不要で、SSRにも対応し、GitHubとの連携で自動デプロイまで実現できます。

2.2 AWS Amplifyとは

AWS Amplifyは、フロントエンドアプリケーションの開発・デプロイ・ホスティングを支援するAWSのサービスです。

Amplifyには複数の機能がありますが、本セクションではAmplify Hostingに焦点を当てて学びます。Amplify Hostingは、GitHubなどのリポジトリと連携し、コードをプッシュするだけでビルドとデプロイが自動で実行されるホスティングサービスです。

2.3 Amplify Hostingの特徴

Amplify Hostingには、以下のような特徴があります。

GitHubとの連携による自動デプロイ

Amplify Hostingの最大の特徴は、GitHubなどのGitリポジトリと連携し、コードをプッシュするだけで自動的にビルド・デプロイが実行される点です。

例えば、S3 + CloudFrontでフロントエンドを配信している場合、コードを更新するたびに以下のような手順を踏む必要があります。

1. ローカルでコードを修正し、GitHubにプッシュする
2. ローカルで npm run build を実行し、ビルド済みファイルを生成する
3. AWS CLIで aws s3 sync を実行し、ビルド済みファイルをS3にアップロードする
4. CloudFrontのキャッシュを無効化（Invalidation）して、最新のファイルが配信されるようにする

Amplify Hostingでは、これらの手順がすべて不要です。GitHubリポジトリを接続しておくだけで、コードをプッシュした瞬間にAmplifyが変更を検知し、ビルドからデプロイまでを自動で実行します。CI/CDパイプラインを自分で構築する必要がなく、リポジトリを接続するだけで継続的デプロイの仕組みが整います。

また、Amplifyはリポジトリの内容から使用しているフレームワーク（Next.js、React、Vue.js、Nuxt.jsなど）を自動検出し、そのフレームワークに適したビルド設定を自動で生成します。開発者がビルドコマンドや出力先を手動で調べて設定する必要がなく、すぐにデプロイを開始できます。

SSR（サーバサイドレンダリング）対応

Next.jsなどのフレームワークに対応しています。S3 + CloudFrontでは静的ファイルの配信しかできませんが、Amplify HostingではSSR（サーバサイドレンダリング）を伴うアプリケーションもデプロイできます。

EC2でSSRアプリケーションを動かす場合は、Node.jsのサーバプロセスを自分で起動し、プロセスが異常終了した場合の自動再起動や、アクセス増加時のスケーリングも自分で設定する必要があります。Amplify Hostingではこれらの処理を裏側で自動的にハンドリングしてくれるため、開発者はアプリケーションのコードに集中できます。

3. Amplify Hostingの仕組み

3.1 デプロイの流れ

Amplify Hostingでアプリケーションをデプロイする際の流れは以下のとおりです。

graph LR
    A[GitHubにプッシュ] --> B[Amplifyが検知]
    B --> C[ソースコードの取得]
    C --> D[ビルド実行]
    D --> E[デプロイ]
    E --> F[公開]

1. GitHubへのプッシュ

開発者がローカルでコードを修正し、GitHubリポジトリにプッシュします。これがデプロイのトリガーとなります。通常の開発フローと同じ git push コマンドを実行するだけで、特別な操作は必要ありません。

2. プッシュの検知

Amplifyは接続されたGitHubリポジトリを常に監視しています。プッシュが行われると、Amplifyが自動的にそれを検知し、ビルドプロセスを開始します。Amplifyコンソール上では、ビルドのステータスがリアルタイムで表示されます。

3. ソースコードの取得

Amplifyがリポジトリから最新のソースコードを取得します。指定されたブランチ（例：main）のコードがAmplifyのビルド環境にダウンロードされます。

4. ビルドの実行

amplify.yml に定義されたビルド設定（または自動検出されたデフォルト設定）に基づいて、ビルドが実行されます。依存関係のインストール（npm ci）、アプリケーションのビルド（npm run build）などが順番に実行されます。ビルド中にエラーが発生した場合はここで中断され、デプロイは行われません。

5. デプロイ

ビルドが成功すると、生成された成果物がAmplifyのインフラに自動でデプロイされます。SSRアプリケーションの場合は、サーバサイドの処理を実行する環境も自動で構成されます。

6. 公開

デプロイが完了すると、アプリケーションが公開され、ユーザがアクセスできる状態になります。カスタムドメインが設定されている場合は、そのドメインで最新のアプリケーションが配信されます。

この一連の流れがすべて自動で行われるため、開発者はコードを書いてプッシュするだけで、最新のアプリケーションが公開されます。

3.2 ビルド設定（amplify.yml）

Amplify Hostingのビルドプロセスは、amplify.ymlという設定ファイルによって制御されます。

前のセクションで説明したとおり、AmplifyはGitHubリポジトリを接続する際にフレームワークを自動検出し、そのフレームワークに適したビルド設定を自動で生成します。つまり、通常は開発者が amplify.yml を手動で作成する必要はありません。次のハンズオンセクションでも体験しますが、GitHubリポジトリを連携するだけで、Amplifyが適切なビルド設定を用意してくれます。

ただし、プロジェクト固有の要件がある場合（ビルド前にテストを実行したい、キャッシュの設定を調整したいなど）には、amplify.yml をリポジトリのルートに配置するか、Amplifyコンソールから編集することで、ビルドプロセスをきめ細かく制御できます。

以下は、Amplifyが自動生成するNext.jsアプリケーション向けのビルド設定の例です。

version: 1
frontend:
  phases:
    preBuild:
      commands:
        - npm ci
    build:
      commands:
        - npm run build
  artifacts:
    baseDirectory: .next
    files:
      - '**/*'
  cache:
    paths:
      - .next/cache/**/*
      - node_modules/**/*

この設定ファイルの各セクションの役割は以下のとおりです。

• preBuild … ビルド前に実行するコマンド。依存関係のインストールなどを行う
• build … アプリケーションのビルドコマンドを実行する
• artifacts … ビルド成果物の出力先を指定する
• cache … ビルドを高速化するためにキャッシュするファイルを指定する

ビルド設定のカスタマイズ

通常はデフォルトのビルド設定のままで問題ありませんが、プロジェクトの要件に合わせてカスタマイズしたい場合は、amplify.yml をリポジトリに配置して上書きできます。

例えば、ビルド前にテストを実行したい場合は、preBuildフェーズにテストコマンドを追加します。

version: 1
frontend:
  phases:
    preBuild:
      commands:
        - npm ci
        - npm run test
    build:
      commands:
        - npm run build
  artifacts:
    baseDirectory: .next
    files:
      - '**/*'

この設定により、テストが失敗した場合はビルドが中断され、問題のあるコードがデプロイされるのを防ぐことができます。S3 + CloudFrontの構成では、こうしたビルド前のチェックを自動化するにはGitHub Actionsなどを使って自分でCI/CDパイプラインを構築する必要がありますが、Amplifyでは amplify.yml に記述するだけで実現できます。

4. Amplifyの応用機能

Amplify Hostingには、基本的なデプロイ機能に加えて、実務で役立つさまざまな応用機能が用意されています。

4.1 環境変数

Amplify Hostingでは、ビルド時やランタイムで使用する環境変数をコンソールから設定できます。APIのエンドポイントURLや認証情報など、コードに直接書きたくない値を安全に管理するために使用します。

環境変数は、Amplifyコンソールの「環境変数」セクションから設定します。ブランチごとに異なる値を設定することもできるため、本番環境と開発環境で異なるAPIエンドポイントを指定するといった使い分けが可能です。

4.2 カスタムドメインとHTTPS

Amplify Hostingでは、カスタムドメインの設定とSSL/TLS証明書の管理が提供されます。Amplifyが自動で発行・管理するマネージド証明書を利用するか、ACMにインポートした自前の証明書を利用するかを選択できます。Route 53でドメインを管理している場合は、数クリックでドメインの設定が完了します。サードパーティのDNSプロバイダを使用している場合は、DNSレコードを手動で追加する必要があります。

S3 + CloudFrontでカスタムドメインとHTTPSを設定する場合は、「コンテンツ配信をしよう」のセクションで体験したように、ACMでの証明書発行、CloudFrontのディストリビューション設定、Route 53でのDNSレコード設定と、複数のサービスを組み合わせて手動で構築する必要がありました。Amplify Hostingではマネージド証明書を選択すれば証明書の発行と更新がすべて自動化されるため、運用の手間が大幅に軽減されます。

4.3 ビルド通知

Amplify Hostingでは、ビルドの成功・失敗をメールで通知する機能が標準で提供されています。Amplifyコンソールの「通知」セクションからメールアドレスを登録するだけで、ビルドが完了するたびに結果がメールで届きます。

通知はブランチごとに設定することもできるため、例えば本番ブランチ（main）のビルド結果だけを通知するといった使い分けも可能です。

Slackなどのチャットツールへの通知を行いたい場合は、Amazon SNSとAWS Lambdaを組み合わせて構築する方法があります。

4.4 Basic認証（アクセス制限）

Amplify Hostingでは、ブランチごとにBasic認証（ユーザ名とパスワードによるアクセス制限）を設定できます。

例えば、開発環境（developブランチ）のプレビューURLを外部に公開したくない場合に、Basic認証を有効にしておけば、ユーザ名とパスワードを知っている人だけがアクセスできます。Amplifyコンソールの「アクセスコントロール」セクションから、ブランチを選択してユーザ名・パスワードを設定するだけで有効になります。

EC2やS3 + CloudFrontでBasic認証を実現しようとすると、Webサーバの設定ファイルを編集したり、CloudFront Functionsでリクエストヘッダーを検証する仕組みを構築したりする必要がありますが、Amplifyでは数クリックで設定できます。

4.5 WAFとの連携

Amplify HostingはAWS WAF（Web Application Firewall）と連携して、アプリケーションをWebベースの攻撃から保護できます。

WAFを有効にすると、SQLインジェクションやクロスサイトスクリプティング（XSS）といった一般的な攻撃パターンをブロックしたり、特定のIPアドレスからのアクセスを制限したりするルールを適用できます。Amplifyコンソールの「ファイアウォール」セクションから設定が可能です。

S3 + CloudFrontの構成でWAFを利用する場合は、CloudFrontのディストリビューションにWAFを手動で関連付ける必要がありますが、Amplifyではコンソールから直接設定できるため、より手軽にセキュリティ対策を導入できます。

4.6 カスタムヘッダー

Amplify Hostingでは、アプリケーションのレスポンスにカスタムHTTPヘッダーを追加できます。

HTTPヘッダーは、ブラウザとサーバ間の通信に付加される制御情報です。カスタムヘッダーを設定することで、セキュリティの強化やキャッシュの制御が行えます。

例えば、自分のサイトが他のサイトに埋め込まれるのを防いだり、画像やCSSをブラウザにキャッシュさせる時間を指定したりできます。

設定はAmplifyコンソールの「カスタムヘッダー」セクションから行うか、リポジトリのルートに customHttp.yml ファイルを配置することで管理できます。

4.7 リライトとリダイレクト

Amplify Hostingでは、URLのリライト（書き換え）とリダイレクト（転送）のルールを設定できます。

リダイレクトは、古いURLへのアクセスを新しいURLに転送する仕組みです。例えば、サイトのURL構造を変更した際に、古いURLでアクセスしたユーザを新しいページに案内できます。リライトは、URLはそのままに内部的に別のリソースを返す仕組みで、例えばSPA（Single Page Application）で存在しないパスへのアクセスをすべて index.html に転送する場合などに使用します。

Amplifyコンソールの「リライトとリダイレクト」セクションから、ソースURL、ターゲットURL、リダイレクトの種類（301永続的リダイレクト、302一時的リダイレクト、200リライトなど）を指定してルールを追加できます。

4.8 シークレット

Amplify Hostingでは、APIキーやデータベースのパスワードなど、機密性の高い値をシークレットとして安全に管理できます。

シークレットは環境変数と似ていますが、以下の点が異なります。

• 値が暗号化されて保存され、コンソール上でもマスクされる
• サーバサイドのコードからのみ参照でき、クライアントサイドには公開されない
• SSRのランタイムやビルド時のスクリプトなど、サーバ側の処理でのみ利用できる

例えば、外部APIの認証キーをフロントエンドのコードに含めてしまうと、ブラウザの開発者ツールから誰でも確認できてしまいます。こうした値はシークレットとして管理し、サーバサイドの処理でのみ使用することで、漏洩リスクを防ぐことができます。

4.9 ブランチごとのプレビュー環境

Amplify Hostingの便利な機能のひとつが、Gitのブランチごとに独立した環境を自動作成できるブランチデプロイです。

例えば、mainブランチを本番環境、developブランチを開発環境として運用する場合を考えてみましょう。S3 + CloudFrontの構成では、本番用と開発用で別々のS3バケットとCloudFrontディストリビューションを用意し、それぞれにデプロイする仕組みを個別に構築する必要があります。Amplify Hostingでは、コンソールからブランチを追加するだけで、ブランチごとに専用のURL（例：https://develop.<app-id>.amplifyapp.com）が自動生成され、そのブランチのコードが自動でデプロイされます。

さらに、プルリクエストごとのプレビュー環境を作成することもできます。チームメンバーがプルリクエストを作成すると、そのコードが反映された一時的な環境が自動で立ち上がり、レビュー時に実際の動作を確認できます。マージされると自動的に削除されるため、不要なリソースが残ることもありません。

このように、Amplify Hostingではブランチ戦略に応じた環境管理を手軽に実現でき、チーム開発において非常に有用な機能です。

5. 他のデプロイ方法との使い分け

フロントエンドアプリケーションのデプロイ先として、Amplify Hosting、EC2、S3 + CloudFront、ECS/Fargateにはそれぞれ得意分野があります。ここでは、どのようなケースにどのサービスが適しているかを整理します。

5.1 Amplify Hostingが適しているケース

以下のようなケースでは、Amplify Hostingが最も力を発揮します。

フロントエンドアプリケーションを手軽にホスティングしたい場合

React、Next.js、Vue.jsなどのフロントエンドフレームワークで構築されたアプリケーションをホスティングする場合、Amplify Hostingが最も手軽な選択肢です。フレームワークの自動検出、ビルド設定の自動生成、SSR対応など、フロントエンド開発に必要な機能がひとつのサービスにまとまっているため、インフラの知識が少なくてもすぐにデプロイを始めることができます。

インフラの管理を減らし、開発に集中したい場合

EC2やS3 + CloudFrontでフロントエンドをホスティングする場合は、サーバの管理やデプロイの仕組みを自分で構築・運用する必要があります。Amplify Hostingではこれらがすべてマネージドで提供されるため、インフラの管理に時間を取られることなく、アプリケーションのコードに集中できます。少人数のチームやスタートアップなど、インフラ専任のエンジニアがいない場合にも適しています。

GitHubと連携した自動デプロイを実現したい場合

コードをプッシュするだけで自動的にビルド・デプロイが実行される仕組みを、追加のツールなしで実現できます。S3 + CloudFrontの場合はGitHub Actionsなどを使って自分でCI/CDパイプラインを構築する必要がありますが、Amplify HostingではGitHubリポジトリを接続するだけで完了します。

チーム開発でプレビュー環境を活用したい場合

ブランチごとの独立した環境やプルリクエストごとのプレビュー環境を手軽に利用できるのは、Amplify Hostingならではの強みです。レビュー時に実際の動作を確認できるため、チーム開発の品質とスピードを両立できます。EC2やS3 + CloudFrontでこれを実現しようとすると、環境ごとにリソースを個別に構築・管理する必要があり、大きな手間がかかります。

5.2 Amplify Hostingが適さないケース

一方で、すべてのケースにAmplify Hostingが最適というわけではありません。以下のようなケースでは、他のサービスの方が適している場合があります。

バックエンドAPIをホスティングしたい場合

Amplify Hostingはフロントエンド向けのサービスであり、FastAPIやExpress.jsなどのバックエンドAPIのホスティングには対応していません。バックエンドAPIをAWS上にデプロイする場合は、ECS/Fargateが適しています。

実務では「フロントエンドはAmplify、バックエンドはECS/Fargate」という構成がよく採用されます。それぞれのサービスの得意分野を活かすことで、開発効率とインフラの管理負荷のバランスを取ることができます。

CloudFrontの配信設定を細かく制御したい場合

SSRが不要な静的サイトやSPA（Single Page Application）の場合、Amplify Hostingでも問題なくホスティングできます。ただし、CloudFrontのキャッシュ動作やオリジン設定をきめ細かく制御したい場合は、S3 + CloudFrontを直接構成する方が柔軟に対応できます。Amplify Hostingは手軽さと引き換えに、配信の細かなチューニングはAmplifyの管理下に委ねる形になるため、パフォーマンスの最適化に強いこだわりがある場合はS3 + CloudFrontの構成が適しています。

サーバの構成を完全にコントロールしたい場合

特殊なミドルウェアやライブラリのインストールが必要な場合や、OSレベルでの細かな設定が求められる場合は、EC2が適しています。EC2はサーバの構成を自由にカスタマイズできるため、Amplifyやその他のマネージドサービスでは対応できない要件にも柔軟に対応できます。

ただし、EC2はサーバの管理（OSのアップデート、セキュリティパッチの適用、プロセスの監視など）をすべて自分で行う必要があります。フロントエンドのホスティングのためだけにEC2を運用するのは運用負荷が大きいため、AmplifyやS3 + CloudFrontで対応できるのであれば、そちらを選ぶ方が効率的です。

高い可用性が求められ、障害時に自分で対応したい場合

Amplify Hostingはインフラがフルマネージドであるため、デプロイやホスティングの仕組みは完全にブラックボックスです。通常はこれが大きなメリットですが、裏を返すと、Amplifyのサービス側で障害やバグが発生した場合に、自分たちで原因を調査したり復旧作業を行ったりすることができません。AWSサポートに問い合わせて対応を待つしかなく、サポートの契約プランによっては対応に時間がかかることもあります。

少しの停止も許されないミッションクリティカルなシステムでは、ECS/FargateやEC2でインフラを自分たちで構築し、複数のアベイラビリティゾーンにまたがる冗長構成を組む方が、障害時のコントロール性が高くなります。ロードバランサによるヘルスチェック、オートスケーリング、フェイルオーバーの仕組みを自分たちで設計・管理できるため、障害の影響を最小限に抑えることが可能です。

インフラをコードで統一管理したい場合

フロントエンドとバックエンドのインフラをTerraformなどで一元管理したい場合は、ECS/Fargateでフロントエンドもコンテナとしてデプロイする方が適しています。Amplify HostingはTerraformでの管理も可能ですが、ECSの方がインフラ全体を統一的に管理しやすい面があります。

6. Amplify Backend

ここまではAmplify Hostingについて学んできましたが、AWS Amplifyにはもうひとつ、Amplify Backendという機能があります。

DevOps Campでは Amplify Backendについては詳しく扱いませんが、Amplifyの全体像を理解するために、ここでは概要を紹介しておきます。

6.1 Amplify Backendとは

Amplify Backendは、フロントエンドアプリケーションに必要なバックエンドの機能を、少ないコードで素早く構築できる仕組みです。

認証（Authentication）

ユーザのサインアップ・ログイン機能を提供します。裏側ではAmazon Cognitoが使われており、メールアドレスやパスワードによる認証、Googleアカウントでのソーシャルログインなどを、Amplifyの設定を数行書くだけで実現できます。通常、認証機能を一から構築するにはCognitoの設定、トークンの管理、セッション処理など多くの作業が必要ですが、Amplify Backendではこれらが大幅に簡略化されます。

データベース（Data）

データの保存・取得機能を提供します。裏側ではAWS AppSync（GraphQL API）とAmazon DynamoDBが使われており、例えば「タスク管理アプリケーションでタスクの一覧を取得する」「新しいタスクを追加する」といったデータ操作を、TypeScriptでデータモデルを定義するだけで行えます。データモデルの定義をAmplifyの設定ファイルに記述すると、GraphQL APIとデータベースが自動的に作成されます。

ストレージ（Storage）

画像やファイルのアップロード・管理機能を提供します。裏側ではAmazon S3が使われており、例えば「ユーザのプロフィール画像をアップロードする」「投稿に添付されたファイルをダウンロードする」といった機能を手軽に実装できます。アクセス制御（自分がアップロードしたファイルだけを閲覧可能にする等）もAmplifyの設定で定義できます。

関数（Functions）

サーバサイドのビジネスロジックを実行する機能を提供します。裏側ではAWS Lambdaが使われており、例えば「新しいユーザが登録されたときにウェルカムメールを送信する」「注文が作成されたときに在庫を更新する」といった処理を定義できます。

これらの機能を組み合わせることで、バックエンドのインフラを意識せずに、フロントエンドのコードだけでフルスタックなアプリケーションを構築できます。

7. まとめ

この章では、AWS Amplifyの概要と特徴、Amplify Hostingの仕組みについて学びました。

• AWS Amplifyは、フロントエンドアプリケーションの開発・デプロイ・ホスティングを支援するサービスである
• Amplify HostingはGitHubと連携し、プッシュするだけで自動ビルド・デプロイが実行される
• フレームワークの自動検出により、ビルド設定を手動で作成する必要がない
• Next.jsなどのSSR（サーバサイドレンダリング）に対応している
• 応用機能として、環境変数・カスタムドメインとHTTPS・ビルド通知・Basic認証・WAF連携・カスタムヘッダー・リライトとリダイレクト・シークレットが利用できる
• ブランチごとのプレビュー環境やプルリクエストプレビューにより、チーム開発を効率化できる
• 実務では、フロントエンドをAmplify、バックエンドをECS/Fargateで構成するパターンがよく使われる
• Amplify Backendというバックエンド機能もあるが、実務ではECS/FargateやAPI Gateway + Lambdaを使うケースが一般的である

次の章では、Next.jsアプリケーションをAmplify Hostingにデプロイする流れをハンズオン形式で体験します。