Zenn
🌸

人生初LTに向けて実践：CloudFront VPC origins

に公開
AWS
CloudFront
alb
CDN
vpcorigins
tech

はじめに

CloudFront、試験にでるけど一生使うことがなさそうなサービス。re:invent前に「VPCオリジン」という新機能がリリースされてから気になっていました。
また、近々社内でLTをする予定なのでそのためのネタとして今回さわってみました。
ちなみにLTは人生初です。来年度はLTの一年にしたいと思ってます。

アーキテクチャ

まずはHTTPでワンパス通します。その後、ドメイン取得や証明書発行を行い、HTTPSで通信できるよう設定を変更していきます。

準備

VPCオリジンを作成する前に、public ALB + EC2を構築して確実に動くバックエンドを整えます。
VPCオリジンを構築する際、ALBとEC2の設定に不備があるとトラブルシューティングが面倒だと思ったためです。
EC2にはapacheをインストールし、Webサーバとして稼働させます。
ターゲットグループに登録したEC2のヘルスチェックに失敗していますが、ALBのエンドポイントにアクセスするとapacheが正常に稼働しているように見えます。

これはドキュメントルートにindex.htmlが存在しないため、welcomeページが表示されている状態のようです。
セッションマネージャーでEC2に接続し、apacheの設定ファイル（/etc/httpd/conf/httpd.conf）を確認しました。
自前でindex.htmlを作成したところ、ヘルスチェックが通るようになりました。
ちなみに「ドキュメントルートにindex.htmlがない場合、welcomeページを表示する」という設定は/etc/httpd/conf.d/welcome.confに書かれています。
これで事前準備完了です。
ここで作成したEC2のAMIを作成し、内部ALBに紐づけます（手順は割愛します）。

// 設定ファイルの存在を確認
sh-5.2$ ls -la
total 28
drwxr-xr-x. 2 root root    37 Mar 15 12:58 .
drwxr-xr-x. 5 root root   105 Mar 15 12:58 ..
-rw-r--r--. 1 root root 12005 Jul 30  2024 httpd.conf
-rw-r--r--. 1 root root 13430 Jul 30  2024 magic

// ドキュメントルートの置き場所が指定されている箇所を発見
DocumentRoot "/var/www/html"

// ドキュメントルートを確認→apacheをインストールしただけではindex.htmlは配置されない
sh-5.2$ ls -la /var/www/html
total 0
drwxr-xr-x. 2 root root  6 Jul 30  2024 .
drwxr-xr-x. 4 root root 33 Mar 15 12:58 ..

// ドキュメントルートにindex.htmlを作成
sh-5.2$ echo "Hello World" | sudo tee /var/www/html/index.html

CloudFront

CloudFront VPC Originsの作成

内部ALB + EC2が作成済みという前提で作業を進めます。
「Name」には任意の名前を、「オリジンARN」には内部ALBを指定します。

VPCオリジンの作成が完了すると2つのENIと1つのSGが作成されます。SGのインバウンド/アウトバウンドルールはデフォルトのままで問題ありません。

CloudFront ディストリビューションの作成

「Origin domain」には先ほど作成したVPCオリジンを指定します。Elastic Load Balancerではないので注意です（私はここでミスって解決まで時間を要しました）。

内部ALBのSGにインバウンドルールを追加

CloudFront-VPCOrigins-Service-SGからのTCPポート80（HTTP）を許可します。
ここまでの手順でユーザ→CloudFront→ALB→EC2の一連のトラフィックルートが完成しました。
以降は通信の暗号化（HTTPS化）に必要な設定を進めていきます。

通信暗号化

独自ドメインの取得

「お名前.com」は利用歴があるので、今回はRoute53でドメインを取得してみようと思います。
必要事項を入力し、ドメインをリクエストすると、「Amazon Registrar サインアップの確認」という件名のメールが飛んできます。
内容をみると、アクセスキーを提供する必要があるようです。いまいち対処法が分からないで、とりあえずいつものIAMユーザでアクセスキーを発行しました。
すると、ステータスが「成功」に変わり、リクエストしたドメインと同じ名前のパブリックホストゾーンが作成されました。
※白塗りで分かりくいですが、ドメイン名は「example.com」に読み替えてください。

（メール本文）
SDK、コマンドラインインターフェイス (CLI)、または API を使用して Amazon Web Services をプログラムで使用するには、
お客様の本人確認を行い、お客様がリクエストしているリソースへのアクセス許可を有しているかを検証させていただくため、
アクセスキーをご提供いただく必要がございます。アカウントのアクセスキーを管理するには、
https://console.aws.amazon.com/iam/home?#security_credential にアクセスしてください。

証明書の作成

バージニア北部リージョンでCloudFront用の証明書を、東京リージョンでALB用の証明書を作成します。
ワイルドカードも利用可能です。
ただし、ALBの証明書はCloudFrontと同じドメイン名で作成する必要があります。

ディストリビューションの設定変更

「Alternative domain name (CNAMES)」に証明書のドメイン名を、「Custom SSL Certificate」にバージニア北部リージョンで作成した証明書を設定します。

ビューワープロトコルポリシーを「HTTPS only」に変更します。

エイリアスレコードの作成

パブリックホストゾーンにエイリアスレコードを作成します。
これで「example.com」へのアクセスがディストリビューションにルーティングされるようになります。
ここまででユーザ→CloudFront間の通信をHTTPSで行うための設定が完了しました。

ALBに証明書を設定

最後にCloudFront→ALB間の通信を暗号化するための設定を行います。
リスナーのプロトコルを「HTTPS」に変更します。

東京リージョンで作成した証明書を設定します。

さいごに忘れてはいけないのがSGです。
ALBのSGのインバウンドルールにTCPポート443（HTTPS）を追加します。TCPポート80（HTTP）は削除します。

考察＆コメント

  • ユーザ→CloudFrontはインターネット通信なので、暗号化する価値が十分あります。CloudFrontから後ろ通信はAWS内に閉じられるため要件に応じて暗号化する/しないを決めるものと考えています。
  • ALB→EC2間の通信が暗号化されていることを確認するにはどうすればいいのか分からず、検証できませんでした。
  • オリジンやALBに障害があったと時、ソーリーページを表示させる仕組みを実装したい。
    • S3にソーリーページ（html）を配置
    • OACを作成
    • ビヘイビア(/sorry)に挙動を追加
  • ALBのヘルスチェックに失敗したときアラートを上げる仕組みを実装したい。
    • CloudWatchメトリクス>HealthyHostCountが0になったときアラート→SNS→メール等
    • EventBridgeは必要なさそう
  • ユーザ目線のモニタリングはCloudWatch Synthetics
  • ALB→EC2間のHTTPS化はいつかやる。

さいごに

久しぶりのプライベートハンズオン、重い腰を上げてやってみたら面白かった！
CloudFront以外にもつまずいた箇所はありますが完走できました。これでLTの準備は万端です！！！

Aレコード、CNAMEレコード、証明書などDNSについて無知なのであとでちゃんと調べようと思います。

参考

Discussion