はじめに
こんにちは。アメリカ在住で独学エンジニアを目指している Taira です。
ついにMVPが完成し、あとはデプロイするだけ！というところまで来ました。
今回は、独自ドメインを使ってAWSにデプロイする手順を紹介します。
前提条件
- 今回はReact × Rails × Docker × PostgreSQLの構成です
- AWSアカウントを持っていること
- ドメインを取得していること(私はお名前.comで取得しました)
- S3、CloudFront、Route53の基礎知識があること
- 公開リージョンは東京リージョン（ap-northeast-1）
- 著者は2025年10月10日に記事を書いています
現時点で想定している構成図は以下の通りです。なおこれから若干変更する可能性がありますのでご了承ください
1. Route53の設定
Route53を開始する前に東京リージョンであることを確認してください。
Route53を初めて開くと上記のような画面にが表示されます。すでにドメインを取得しているので、以下の手順で初期設定をしてください
- 「ホストゾーンを作成」をクリック
- ドメイン名に 自分の設定したいドメイン(example.comなど) を入力
- タイプは「パブリックホストゾーン」を選択
ここまでで初期設定が完了します
続いて、NSレコードに乗っている4つのネームサーバー(写真の値と書いてある箇所)をドメインを取得したサービス(私はお名前.com)に登録します
お名前ドットコムでドメインを取得していないかたは、各サービスのマニュアルを参考にしてください。
お名前ドットコムの方はざっくり以下の手順で設定できます
- お名前.comのドメインNaviにログイン
- 「ドメイン機能一覧」→「ネームサーバーの変更」をクリック
- 「ネームサーバーの変更」をクリック
- 「その他のネームサーバーを使う」を選択
- 4つのネームサーバーを入力
- 「確認画面へ進む」→「設定する」をクリック
これでRoute53の基本設定は完了です
2. ACMの設定
続いてACMの設定を行います。ACMはSSL証明書を管理するサービスです。
今回私はフロントはCloudFront、バックエンドはALB(Application Load Balancer)で公開するので、2つの証明書を発行します。
CloudFront について知っている方なら説明は飛ばしていただいてよいですが、CloudFrontはグローバルサービスでリージョン自体をもたないが、証明書自体はバージニア北部(us-east-1)で管理される必要があるので、証明書もバージニア北部で発行します。
一方で、ALBは東京リージョン(ap-northeast-1)で作成するので、証明書も東京リージョンで発行します。
フロントエンド用の証明書発行
- Certificate Managerを開き、リージョンが「バージニア北部(us-east-1)」であることを確認
- 「証明書のリクエスト」をクリック
- 「パブリック証明書のリクエスト」を選択し、「次へ」をクリック
- 完全修飾ドメイン名に自分のドメイン(例: www.example.com,example.com)を入力し、「次へ」をクリック
- エクスポートは、AWS外（例：自前サーバーや他クラウド）で同じ証明書を使いたい場合に必要なオプションです。今回はCloudFrontでしか使わないので「いいえ、エクスポートしません」を選択し、「次へ」をクリック
- 暗号化アルゴリズムは「RSA 2048」を選択し、「次へ」をクリック
- 「DNSによる検証」を選択し、「リクエスト」をクリック
- 次の画面にRoute53での設定を促す画面が出るので、「Route53でのレコードの作成」をクリックし、Route53に移動して「レコードの作成」をクリック
- しばらくすると、ステータスが「発行済み」になります
バックエンド用の証明書の発行
上記と違う部分は以下の通りです
- リージョンが「東京(ap-northeast-1)」であることを確認
- 完全修飾ドメイン名に自分のドメイン(api.example.comなど)を入力し、「次へ」をクリック
これで2つの証明書が発行されました
3. S3の設定
続いてS3の設定を行います。リージョンが「東京(ap-northeast-1)」であることを確認してください
- S3を開き、「バケットを作成」をクリック
- バケットタイプは「汎用」を選択
- バケット名に任意の名前(yourappname-frontendなど)を入力
- オブジェクト所有者は「ACLを無効」を選択
- バケットのブロックパブリックアクセス設定は「すべてのパブリックアクセスをブロック」を選択
- バージョニングは「無効」を選択。これは同じ名前のオブジェクトを上書きしても、古いバージョンを自動で残しておく機能。です。例えば
/index.html (v1)
→ 更新して再アップロードすると v2 が作成され、v1 も残る
必要に応じて有効にしてください
7. 暗号化は「Amazon S3管理キー(SSE-S3)」を選択します。CloudFront+S3の組み合わせでは、AWSが完全に管理。設定が簡単・無料であるため、基本的にはこれで問題ありません
8. バケットキーは「無効」を選択(SSE-KMSを使う場合に有効にするオプション)
9. 「バケットを作成」をクリック
4. CloudFrontの設定
続いてCloudFrontの設定を行います
- CloudFrontを開き、「CloudFrontディストリビューションを作成」をクリック
- Distribution nameに任意の名前(yourappname-frontend)を入力
- Distribution type は 「Single website or app」を選択し次へ
- Origin Type は 「Amazon S3 bucket」を選択
- Origin Domain は 先ほど作成したS3バケット(yourappname-frontend)を選択
- Origin Path は 空欄のまま
- Settings の箇所で「Allow private S3 bucket access to CloudFront」にチェックをつける。これはS3バケットをパブリックにせず、CloudFront経由でのみアクセスできるようにする設定
- WAF は 今回は設定しないので「None」を選択。WAFは外部からの不正アクセス（DDoS、SQLインジェクション、XSSなど）をCloudFrontレイヤーでブロックするためのセキュリティ機能ですが費用が掛かるためポートフォリオ時点では設定しないのがいいかもしれません。本番環境では設定を推奨します
- Create Destination をクリック
これでCloudFrontが作成されました。ですが、http アクセスしかできないので、httpsアクセスできるように設定を追加します
- 先ほど作成したCloudFrontを選択し、「ビヘイビア」タブをクリック
- すでに作成されている、Default (*) を選択し、「編集」をクリック
- Viewer Protocol Policy を 「Redirect HTTP to HTTPS」に変更
- 「変更を保存」をクリック
また、この時点ではTLS証明書が設定されていないので、httpsアクセスできるように設定を追加します
- CloudFront の「一般」タブをクリック
- 「編集」をクリック
- Alternative domain names (CNAMEs) に 自分のドメイン(例: www.example.com)を入力
- Custom SSL certificate を選択
- 先ほどACMで発行した証明書(例: www.example.com)を選択
- Security policy は 「TLSv1.2_2025」を選択
- 「変更を保存」をクリック
※ 3の手順でAlternative domain names (CNAMEs) にドメインを追加しないと、CloudFrontがそのドメインを自分のものと認識していないため、httpsアクセスできません
これでhttp にアクセスした場合にhttpsにリダイレクトされるようになりました
次のRoute53の設定で独自ドメインをCloudFrontに紐づけるのですが、その際にディストリビューションドメイン名(例: d123456abcdef8.cloudfront.net)が必要なので控えておきます
5. Route53にCloudFrontの設定を追加
続いて、Route53にCloudFrontの設定を追加します
- Route53を開き、先ほど作成したホストゾーン(example.com)をクリック
- 「レコードを作成」をクリック
- レコード名に「www」など任意のサブドメインを入力
- レコードタイプは「A - IPv4アドレス」を選択
- 値/ルーティング先に「エイリアス」を選択
- トラフィックのルーティング先に「CloudFrontディストリビューションへのエイリアス」を選択
- ルーティングポリシーは「シンプル」を選択
- 「レコードを作成」をクリック
これでRoute53にCloudFrontの設定が追加されました
CloudFrontはIPv6にも対応しているので、必要に応じてAAAAレコードも追加してください
ちなみにTTL(Time to Live)はDNSキャッシュの有効期限を指定する値で、短くすると変更がすぐに反映されるが、アクセスのたびにDNSルックアップが発生するため負荷が高くなる。
長くすると変更の反映に時間がかかるが、アクセスのたびにDNSルックアップが発生しないため負荷が低くなる。
というトレードオフがあります。ポートフォリオのように頻繁に変更しない場合はデフォルトで問題ありません。
6. ここまで設定できているか確認したい場合
ここまでの設定を確認したい場合はまだ少し設定が残っています
- CloudFront のディストリビューションを開き、一般タブをクリック
- 「編集」をクリック
- Default root object に index.html を入力
- 「変更を保存」をクリック
これで、CloudFrontのルートにアクセスしたときにindex.htmlが表示されるようになりました
次に、S3にindex.htmlをアップロードします
- S3を開き、先ほど作成したバケット(yourappname-frontend)をクリック
- 「アップロード」をクリック
- 「ファイルを追加」をクリックし、ローカルのindex.htmlを選択
私は以下のindex.htmlをアップロードしました
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>your app name</title>
</head>
<body>
<h1>Welcome to your app name</h1>
<p>You successfully deployed your html on CloudFront.</p>
</body>
</html>
- 「アップロード」をクリック
これでS3にindex.htmlがアップロードされました
最後に、ブラウザで https://your-domain.com にアクセスして、以下のような画面が表示されれば成功です
7. SPA公開の際の設定
SPA（Single Page Application）特有のルーティング問題を解決するための設定があります。
それは、CloudFrontのエラーページ設定を利用する方法です。
Reactで作ったSPAでは、ルーティング（ページ遷移）はブラウザのJavaScript側で行われます。
たとえば：
https://www.your-domain.com/
https://www.your-domain.com/about
https://www.your-domain.com/settings
これら全部、実際には S3上には1つの index.html しか存在しません。
でもブラウザ側のReact Routerが「URLに応じて表示を切り替える」仕組みで動いています。
そのため、CloudFrontに https://www.your-domain.com/about にアクセスしたとき、CloudFrontはS3に対して「/about」というオブジェクトを探しに行きます。
しかし、S3には /about というオブジェクトは存在しないため、404エラーが発生します。
この問題を解決するために、Custom Error Responses を設定しCloudFrontにこう教えてあげます
「もしS3が 403 や 404 を返したら、本当はファイルがないんじゃなくてSPAルーティングだから、代わりに /index.html を返してね。」
それでは設定方法です
- CloudFrontのディストリビューションを開き、「エラーページ」タブをクリック
- 「カスタムエラーレスポンスの作成」をクリック
- HTTPエラーコードに「404」を選択
- 「最小TTL」は「0」を入力
- 「レスポンスページのパス」に
/index.htmlを入力 - 「HTTPレスポンスコード」は「200: OK」を選択
登録するのは403と404の2つだけで大丈夫です。
500番台のエラーはサーバー側の問題なので、通常通りエラーページを表示させたほうが良いです。
まとめ
Route53、ACM、S3、CloudFrontを使って独自ドメインでポートフォリオを公開する手順を紹介しました。
写真が少なく申し訳ありませんが、何だろうと私が感じた部分は注釈を入れたつもりなので同じ初心者の方なら理解できると思います。
ぜひ参考にしてみてください。