【AWS CLI】S3 + CloudFront + Route 53のハンズオン (静的ウェブサイトホスティング)
はじめに
知人のWebサイトを作る機会がありAWSの静的ウェブサイトホスティングを調べていたのですが、AWS CLIでの作り方を紹介している記事が少なかったので、せっかくなのでハンズオン形式で1本にまとめてみました!
今回のハンズオンでは3つの章で構成しています。S3バケットにアクセスするだけのシンプルな構成に始まり、章が進むにつれて一般公開向きの静的ウェブサイトホスティングの構成が出来上がります。
章単位で区切り良く作成しているのでご自身の必要な範囲で進めたり、またはストップしたりできるので是非お気軽にお試しください🙌
アイコンの意味
👤ユーザー / 🪣S3 / 📡CloudFront / 🪯Route 53 / 🔥WAF
章 | リクエスト先 | 通信経路 |
---|---|---|
【1】 S3の静的ウェブサイトホスティング |
S3のウェブサイトエンドポイント | 👤 → 🪣 |
【2】 CloudFront経由 |
CloudFrontディストリビューションドメイン | 👤 → 📡 → 🪣 |
【3】 Route 53経由 |
独自ドメイン | 👤 → 🪯 → 📡 → 🪣 |
【おまけ】 WAFの設定 |
独自ドメイン | 👤 → 🪯 → 📡🔥 → 🪣 |
※「【3】Route 53経由」まで進める方は事前にドメイン取得が必要です。
進め方のヒント
AWS CLIは入出力がテキストデータです。そのため、コマンドや出力結果のjsonファイルはChatGPTにききながら進めると、ハンズオン以外の設定についても幅広く情報を得られるのでおすすめです。(実データの取り扱いにはお気をつけください)
💡Tips💡
先にAWS CLIの設定やメリットを知りたい方はこちら
前置き
- AWS CLIのバージョンは
v2
です。 - AWS CLIで操作するリソースのリージョンは東京を指定しています。
cat ~/.aws/config
[default]
region = ap-northeast-1
output = json
...
【1】🪣 S3の静的ウェブサイトホスティング
それでは早速S3の静的ウェブサイトホスティングを作っていきましょう!
構成図
リクエスト先 | 通信経路 |
---|---|
S3のウェブサイトエンドポイント | 👤 → 🪣 |
準備
バケット名はsample-app-20250215-s3
です。頻繁に登場するのでプロセスの環境変数に入れておきましょう。
※バケット名はAWSの全リージョンにわたってユニークにする必要があるためバケット名にはご自身のニックネームやプロジェクト固有の文字列などを盛り込んでおくと被りにくいかもしれません。
BUCKET_NAME=sample-app-20250215-s3
echo $BUCKET_NAME
sample-app-20250215-s3
バケットを作成
aws s3 mb s3://$BUCKET_NAME
アプリをアップロード
先に今回ホスティングするウェブサイトをアップロードしておきましょう。今回はReactのアプリをアップロードします。
※ここは本筋でないのでコマンドだけまとめて載せます。
# プロジェクト作成
npm create vite@latest sample_app
# reactとTypeScriptを選択
✔ Select a framework: › React
✔ Select a variant: › TypeScript
# パッケージをインストール
cd sample_app
npm install
# サーバ起動 (ローカルで一度動作確認したい場合)
npm run dev
# ビルド
npm run build
ビルドしたアプリをS3へアップロードします。
aws s3 sync ./dist s3://$BUCKET_NAME/
AWSコンソールで以下の表示になっていればOKです!
パブリックアクセスをブロックする設定をOFF
紛らわしいですが「ブロックする設定を解除する」ため、パブリックアクセスできる状態に切り替わります。
aws s3api put-public-access-block \
--bucket $BUCKET_NAME \
--public-access-block-configuration "BlockPublicAcls=false,IgnorePublicAcls=false,BlockPublicPolicy=false,RestrictPublicBuckets=false"
パブリックアクセスの設定を確認します。
aws s3api get-public-access-block --bucket $BUCKET_NAME
{
"PublicAccessBlockConfiguration": {
"BlockPublicAcls": false,
"IgnorePublicAcls": false,
"BlockPublicPolicy": false,
"RestrictPublicBuckets": false
}
}
以下プロパティの説明です。
プロパティ | 説明 | 効果 |
---|---|---|
BlockPublicAcls | バケットやオブジェクトに設定されたパブリックACLをブロックするかどうか | falseの場合、設定されたACLがそのまま有効となる |
IgnorePublicAcls | オブジェクトのパブリックACLを無視するかどうか | falseの場合、ACLの設定が無視されず、適用される |
BlockPublicPolicy | バケットポリシーによるパブリックアクセスをブロックするかどうか | falseの場合、ポリシーで許可されたアクセスも有効となる |
RestrictPublicBuckets | バケット全体へのパブリックアクセスを厳格に制限するかどうか | falseの場合、アクセス制限が緩くなり、柔軟にアクセス可能となる |
これでパブリックアクセスできるバケットポリシーが適用されるようになったので、まずはバケットポリシー用のjsonファイルを作成していきます。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "PublicReadGetObject",
"Effect": "Allow",
"Principal": "*",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::$BUCKET_NAME/*" //バケット名に置き換えてください
}
]
}
ポリシーを反映します。
aws s3api put-bucket-policy \
--bucket $BUCKET_NAME \
--policy file://bucket-policy.json
AWSコンソールで以下の表示になっていればOKです!
ウェブサイトエンドポイントを割り当て
静的ウェブサイトホスティングの設定を有効化します。
--index-document
には先ほどアップロードしたReactのアプリのルートファイルを指定します。
aws s3 website s3://$BUCKET_NAME/ --index-document index.html
AWSコンソールのウェブサイトエンドポイントにアクセスして、スタート画面が表示されればOKです!
【2】📡 CloudFront経由
前の章で作成したウェブサイトエンドポイントは手軽に公開できる反面、ユーザーへ提供するウェブサイトとしては避けたい特徴もあります。
- HTTPS通信に非対応
- 毎回S3バケットにデータを取得しに行く(キャッシュの機構がない)
そのためこの章では以下2点を対応します。
- CloudFrontディストリビューションの作成
- HTTPS通信できるようになる
- リクエストに近いエッジロケーションにキャッシュして配信するキャッシュ機構ができる
- OAC(Origin Access Control)の設定
- S3のバケットへの通信が特定のCloudFront経由からのみに制限されてセキュアになる
構成図
現在:
リクエスト先 | 通信経路 |
---|---|
S3のウェブサイトエンドポイント | 👤 → 🪣 |
変更後:
リクエスト先 | 通信経路 |
---|---|
CloudFrontディストリビューションドメイン | 👤 → 📡 → 🪣 |
準備
ウェブサイトエンドポイントを削除
前回の章で対応したS3の静的ウェブサイトホスティングの設定を無効化し、ユーザーが直接S3バケットにアクセスできない状態に戻します。
aws s3api delete-bucket-website --bucket $BUCKET_NAME
パブリックアクセスをブロックする設定をON
続いて、パブリックアクセスをブロックする設定をONに戻します。
aws s3api put-public-access-block \
--bucket $BUCKET_NAME \
--public-access-block-configuration BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true
ポリシーも削除しておきます。
aws s3api delete-bucket-policy --bucket $BUCKET_NAME
これでS3バケットの設定は、元のパブリックアクセスをブロックする状態に戻りました。
それでは次のセクションから本格的にCloudFront経由でアクセスする設定にしていきましょう!
CloudFrontディストリビューションを作成
CloudFrontディストリビューションを作成します。
CloudFrontディストリビューションが配信するリソースの元データ(origin)に、S3バケットを指定します。
aws cloudfront create-distribution \
--origin-domain-name $BUCKET_NAME.s3.amazonaws.com \
--default-root-object index.html
AWSコンソールでCloudFrontディストリビューションが作成できれいればOKです!
補足
なぜSSL証明書を発行していないのにHTTPS通信できてるの?
CloudFrontディストリビューションドメイン(例: xxxxxx.cloudfront.net)は、AWSが提供するSSL証明書が設定されているため、新たなSSL証明書の発行は不要でHTTPS通信が可能になっています。
CloudFrontディストリビューションドメインは自由に変えられないの?
CloudFrontディストリビューションドメインはAWS側で提供されるため変更できません。自由に変更したい場合は次の章の「【3】🪯 Route 53経由」の対応が必要です。
OACを作成し、S3のバケットポリシーを更新
作成したOAC(Origin Access Control)をCloudFront側とS3側の両方で設定することで、S3のバケットに対し特定のCloudFrontからのみアクセスできる仕組みになり、S3バケットのデータ保護を強化することができます。
まずは、今回はsample-app-20250215-s3-oac
というOACを作成します。
aws cloudfront create-origin-access-control \
--origin-access-control-config Name="sample-app-20250215-s3-oac",SigningProtocol=sigv4,SigningBehavior=always,OriginAccessControlOriginType=s3 \
--query 'OriginAccessControl.Id' --output text
E10I7FMDP8WWQZ
出力されたOACのidは後で使います。
CloudFrontディストリビューション側の修正
CloudFrontディストリビューションの設定を修正します。
CloudFrontディストリビューションの設定ファイルの修正はローカルで行うため、出力内容をファイルにリダイレクトさせます。
--id
はAWSコンソールから確認できるCloudFrontディストリビューションのidを指定してください。
aws cloudfront get-distribution-config --id E38CJMA44PEL28 > dist-config.json
以下の修正を対応します。
- OACの設定
- HTTPリクエストをhttpsにリダイレクトする設定(ついでに)
{
- "ETag": "E15DVVP1XE3M3S", //更新する際にETagの指定が必要なので控えておく (プロパティとしては不要なので削除)
- "DistributionConfig": { //更新時に不要な階層のため削除しておく
"CallerReference": "cli-1739612759-610898",
"Aliases": {
"Quantity": 0
},
"DefaultRootObject": "index.html",
"Origins": {
"Quantity": 1,
"Items": [
{
"Id": "sample-app-20250215-s3.s3.amazonaws.com-1739612759-135608",
"DomainName": "sample-app-20250215-s3.s3.amazonaws.com",
"OriginPath": "",
"CustomHeaders": {
"Quantity": 0
},
"S3OriginConfig": {
"OriginAccessIdentity": ""
},
"ConnectionAttempts": 3,
"ConnectionTimeout": 10,
"OriginShield": {
"Enabled": false
},
- "OriginAccessControlId": ""
+. "OriginAccessControlId": "E10I7FMDP8WWQZ" //OACのidをセット
}
]
},
"OriginGroups": {
"Quantity": 0
},
"DefaultCacheBehavior": {
"TargetOriginId": "sample-app-20250215-s3.s3.amazonaws.com-1739612759-135608",
"TrustedSigners": {
"Enabled": false,
"Quantity": 0
},
"TrustedKeyGroups": {
"Enabled": false,
"Quantity": 0
},
- "ViewerProtocolPolicy": "",
+ "ViewerProtocolPolicy": "redirect-to-https", //httpsへリダイレクト
"AllowedMethods": {
"Quantity": 2,
"Items": ["HEAD", "GET"],
"CachedMethods": {
"Quantity": 2,
"Items": ["HEAD", "GET"]
}
},
...省略
"PriceClass": "PriceClass_All",
"Enabled": true,
"ViewerCertificate": {
"CloudFrontDefaultCertificate": true,
"SSLSupportMethod": "vip",
"MinimumProtocolVersion": "TLSv1",
"CertificateSource": "cloudfront"
},
"Restrictions": {
"GeoRestriction": {
"RestrictionType": "none",
"Quantity": 0
}
},
"WebACLId": "",
"HttpVersion": "http2",
"IsIPV6Enabled": true,
"ContinuousDeploymentPolicyId": "",
"Staging": false
}
- }
修正した設定を反映します。
aws cloudfront update-distribution \
--id "E38CJMA44PEL28" \
--if-match E15DVVP1XE3M3S \
--distribution-config file://dist-config.json
S3のバケット側の修正
次にS3バケットのポリシーを更新します。
AWSコンソールのCloudFrontページに、S3に設定するバケットポリシーを取得できる導線が表示されているのでコピーしてから、前の章で作成したbucket-policy.json
に貼り付けてください。
S3のポリシーを更新します。
aws s3api put-bucket-policy \
--bucket $BUCKET_NAME \
--policy file://bucket-policy.json
これでこのS3バケットは特定のCloudFront以外からのアクセスを受け付けない状態になり、S3バケットのデータの保護が強化されました。
CloudFrontディストリビューションドメインでアクセスして表示できればOKです!
【3】🪯 Route 53経由
前の章でCloudFrontディストリビューションドメインにHTTPS通信できる状態になりました。
この章では主に以下の対応をします。
- 独自ドメインのDNSの設定を調整
- AWS以外のレジストラ(今回は「お名前.com」)で取得した独自ドメインを使用するため、DNSレコードの設定をします
-
独自ドメイン用のSSL証明書を発行
- CloudFrontディストリビューションドメインの場合はAWS側が用意してくれてましたが、今回は独自ドメイン用のSSL証明書を自分で作成します
構成図
現在:
リクエスト先 | 通信経路 |
---|---|
CloudFrontディストリビューションドメイン | 👤 → 📡 → 🪣 |
変更後:
リクエスト先 | 通信経路 |
---|---|
独自ドメイン | 👤 → 🪯 → 📡 → 🪣 |
準備
環境変数にセット
ドメイン名はsample.com
です(ここは取得したドメインに置き換えてください)。頻繁に登場するのでプロセスの環境変数に入れておきましょう。
DOMAIN_NAME=sample.com
echo $DOMAIN_NAME
sample.com
ドメインのステータスを確認
念のため現在のドメインのステータスを確認しておきましょう。
whois $DOMAIN_NAME | grep status
status: ACTIVE
💡Tips💡
また、以降のセクションでDNSレコードを変更、CNAMEレコードを追加、Aレコードを追加する工程があるので各種レコードについて気になる方はこちら
Route 53のホストゾーンを作成
Route 53のホストゾーンを作成します。
ホストゾーンを作成することで、独自ドメイン用のDNSレコードを変更することができます。また、その独自ドメインをインターネット全体からアクセス可能なドメインとするか(パブリックホストゾーン)、もしくはVPC内部など、限定されたネットワーク内でのみ名前解決を行うか(プライベートホストゾーン)などの選択もできます。
今回は外部に公開するドメインのためパブリックホストゾーンになります。
aws route53 create-hosted-zone \
--name $DOMAIN_NAME \
--caller-reference `date +%Y-%m-%d_%H-%M-%S`
{
"Location": "https://route53.amazonaws.com/2013-04-01/hostedzone/Z10195652RQP2MROZA9G9",
"HostedZone": {
"Id": "/hostedzone/Z10195652RQP2MROZA9G9",
"Name": "sample.com.",
"CallerReference": "2025-02-16_13-42-00",
"Config": {
"PrivateZone": false
},
"ResourceRecordSetCount": 2
},
"ChangeInfo": {
"Id": "/change/C03241392KU1KV9VB31OQ",
"Status": "PENDING",
"SubmittedAt": "2025-02-16T04:42:02.260000+00:00"
},
"DelegationSet": {
"NameServers": [
"ns-***.awsdns-**.net", //この4つの値を控える
"ns-***.awsdns-**.org",
"ns-***.awsdns-**.com",
"ns-***.awsdns-**.co.uk"
]
}
}
NameServers
の値を控えておきましょう。
次のセクションで、お名前.comの管理画面からドメインの名前解決に使うDNSサーバの設定をお名前.comのDNSサーバ
からAWSのDNSサーバ
に変更する際に使用します。
AWSコンソールで以下のように表示されていればOKです!(DNSサーバはこの画面でも確認できます)
DNSサーバを更新
お名前.comの管理画面でこちらの手順でDNSサーバ名を入力し確認ボタンを押下して更新します。
DNSサーバの切り替えには最大72時間[1]ほどかかる場合がありますが、数分で切り替わるケースも多いので数分経過したらDNSサーバが更新されたか確認してみましょう。
nslookup -type=ns $DOMAIN_NAME
...省略
Authoritative answers can be found from:
ns-***.awsdns-**.net internet address = ***.***.***.***
ns-***.awsdns-**.org internet address = ***.***.***.***
ns-***.awsdns-**.co.uk internet address = ***.***.***.***
ns-***.awsdns-**.com internet address = ***.***.***.***
次の「ACMでSSL証明書を発行」セクションに進む前に、DNSサーバの更新されていることを必ず確認してください!(DNSサーバの変更が反映される前だと、ACMで発行されるSSL証明書のDNS検証が通りません)
ACMでSSL証明書を発行
独自ドメインでHTTPS通信できるようにするためにACM(AWS Certificate Manager)で独自ドメイン用のSSL証明書を発行します。
💡Tips💡
前の章に登場した「AWSで発行されるSSL証明書」と「ACMで発行する独自ドメイン用のSSL証明書」の違いについて改めて知りたい方はこちら
オプションの説明
-
--region us-east-1
- CloudFrontにアタッチするACMの発行は、2025年3月時点ではバージニアリージョンで作成する必要があるため
-
--validation-method DNS
- SSL証明書が対応する独自ドメインが合っているかの照合方法としてDNSを指定
- 具体的にはSSL証明書発行時に発行されるトークンをRoute 53のホストゾーンのCNAMEに追加される
- 初回発行時と自動更新時にドメインの所有者があっているか、まだ使われているかなどを確認します
- SSL証明書が対応する独自ドメインが合っているかの照合方法としてDNSを指定
aws acm request-certificate \
--domain-name $DOMAIN_NAME \
--validation-method DNS \
--region us-east-1
{
"CertificateArn": "arn:aws:acm:ap-northeast-1:************:certificate/d22d495f-a022-4a06-b25a-7027e3faf187"
}
💡Tips💡
ACMで発行するSSL証明書のDNS検証についてはこちら
Route 53にDNS検証用のCNAMEレコードを追加
ACMのAWSコンソールからRoute 53でレコードを作成
ボタンを押下してください。
(ACMでSSL証明書を発行すると自動で行われる場合もありますが、操作も簡単ですので手動で行っておくと安心です)
Route 53のAWSコンソールにCNAMEレコードが追加されていればOKです!
これでACMで発行したSSL証明書が独自ドメインの所有権を確認することができるようになりました。しばらくして、作成したACMのステータスが「成功」に切り替わればOKです。
CloudFrontディストリビューションのSSL証明書を変更
現在CloudFrontディストリビューションには、前の章で自動で作成されていたAWSのSSL証明書がアタッチされている状態です。そのため、独自ドメイン用のSSL証明書に変更する対応していきます。
CloudFrontディストリビューションの設定変更
- 代替ドメインの設定
- 「ユーザーがリクエストしたドメイン名」と「SSL証明書のドメイン名」は一致している必要があるため、CloudFrontディストリビューションには、代替ドメインとして独自ドメインを設定します
- SSL証明書(Certificate)の変更
- デフォルトのCloudFrontの証明書からACMで作成した証明書に変更します
💡Tips💡
CloudFrontの代替ドメインの詳細が気になる方はこちら
まずは、CloudFrontディストリビューションの設定を取得します。
aws cloudfront get-distribution-config --id E38CJMA44PEL28 > dist-config.json
設定を変更し、代替ドメインの設定とSSL証明書の差し替えを行います。
{
- "ETag": "E10PV3YI2O3MV7",
- "DistributionConfig": {
"CallerReference": "cli-1739612759-610898",
"Aliases": {
- "Quantity": 0,
+ "Quantity": 1,
+ "Items": [
+ "sample.com"
+ ]
},
"DefaultRootObject": "index.html",
"Origins": {
"Quantity": 1,
"Items": [
{
"Id": "sample-app-20250215-s3.s3.amazonaws.com-1739612759-135608",
"DomainName": "sample-app-20250215-s3.s3.amazonaws.com",
"OriginPath": "",
"CustomHeaders": {
"Quantity": 0
},
"S3OriginConfig": {
"OriginAccessIdentity": ""
},
"ConnectionAttempts": 3,
"ConnectionTimeout": 10,
"OriginShield": {
"Enabled": false
},
"OriginAccessControlId": "E10I7FMDP8WWQZ"
}
]
},
"OriginGroups": {
"Quantity": 0
},
"DefaultCacheBehavior": {
"TargetOriginId": "sample-app-20250215-s3.s3.amazonaws.com-1739612759-135608",
"TrustedSigners": {
"Enabled": false,
"Quantity": 0
},
"TrustedKeyGroups": {
"Enabled": false,
"Quantity": 0
},
"ViewerProtocolPolicy": "redirect-to-https",
"AllowedMethods": {
"Quantity": 2,
"Items": [
"HEAD",
"GET"
],
"CachedMethods": {
"Quantity": 2,
"Items": [
"HEAD",
"GET"
]
}
},
...省略
"PriceClass": "PriceClass_All",
"Enabled": true,
"ViewerCertificate": {
- "CloudFrontDefaultCertificate": true,
+ "CloudFrontDefaultCertificate": false,
+ "ACMCertificateArn": "arn:aws:acm:us-east-1:************:certificate/045d218f-5dd3-4c9e-a58c-c7bda86cd8ee",
- "SSLSupportMethod": "vip",
+ "SSLSupportMethod": "sni-only",
- "MinimumProtocolVersion": "TLSv1",
+ "MinimumProtocolVersion": "TLSv1.2_2021",
+ "Certificate": "arn:aws:acm:us-east-1:************:certificate/045d218f-5dd3-4c9e-a58c-c7bda86cd8ee",
- "CertificateSource": "cloudfront"
+ "CertificateSource": "acm"
},
"Restrictions": {
"GeoRestriction": {
"RestrictionType": "none",
"Quantity": 0
}
},
"WebACLId": "",
"HttpVersion": "http2",
"IsIPV6Enabled": true,
"ContinuousDeploymentPolicyId": "",
"Staging": false
}
- }
設定を更新します。
aws cloudfront update-distribution \
--id "E38CJMA44PEL28" \
--if-match E15DVVP1XE3M3S \
--distribution-config file://dist-config.json
CloudFrontディストリビューションのAWSコンソールで以下になっていればOKです!
これでCloudFrontディストリビューションにACMで発行したSSL証明書の設定を設定できました!
独自ドメインをCloudFrontディストリビューションにルーティング
最後に、ユーザーからの独自ドメインのリクエストをCloudFrontディストリビューションにルーティングされるように、Route 53にAレコードを追加していきます。
aws route53 change-resource-record-sets \
--hosted-zone-id Z10195652RQP2MROZA9G9 \
--change-batch '{
"Comment": "Point sample.com to CloudFront distribution",
"Changes": [
{
"Action": "UPSERT",
"ResourceRecordSet": {
"Name": "sample.com", //独自ドメイン
"Type": "A", //レコードタイプ
"AliasTarget": {
"HostedZoneId": "Z2FDTNDATAQYW2",
"DNSName": "d2bf00g4mnnvjx.cloudfront.net", //対応先のアドレス
"EvaluateTargetHealth": false
}
}
}
]
}'
Route 53のAWSコンソール上でAレコードが追加されていればOKです!
独自ドメインでアクセスして表示できればOKです!
【おまけ】🔥 WAFの設定
現状把握
現時点でユーザーが独自ドメインにアクセスした場合、ざっくりですが以下の経路でアプリを閲覧することができます。
- 👤 ブラウザから独自ドメインでアクセス開始
- 👤 DNSクエリが発行
- 🪯 Route 53で以下の名前解決が行われる
-
sample.com
→xxxxxx.cloudfront.net
→IPアドレス
- TCP/IPパケットのIPヘッダに
IPアドレス
が記述されてユーザーに返される
-
- 👤 HTTPリクエストをする
- 通信先は
IPアドレス
-
hostヘッダに
sample.com
がセットされている
- 通信先は
- 📡 CloudFrontがS3バケットからアプリを取得してユーザーに配信
- 2回目以降はキャッシュデータを返す
課題点
上記の工程自体に問題はないのですが、現時点だと「1. 👤 ブラウザから独自ドメインでアクセス開始」の工程で、ブラウザのアドレスバーにxxxxxx.cloudfront.net
を打ち込んでもアプリを取得できてしまいます。
また、その場合は「3. 👤 HTTPリクエストをする」のhostヘッダーにはxxxxxx.cloudfront.net
が入ります。
方針
今回はWAF(Web Application Firewall)を使用して、HTTPリクエストのヘッダ情報を検査し、「あるルールに一致したHTTPリクエストだけ」ブロックする方針を取ります。
💡Tips💡
WAFとファイアウォールの用途や検査内容の違いはこちら
構成図
Web ACLを作成
それでは、HTTPリクエストのhostヘッダーにcloudfront.net
という文字が含まれていた場合、ブロックするというルールを作成していきます。
{
"Name": "sample-acl",
"Scope": "CLOUDFRONT",
"DefaultAction": { "Allow": {} },
"Description": "Block requests if host header contains cloudfront.net",
"Rules": [
{
"Name": "sample-acl-rule",
"Priority": 0,
"Statement": {
"ByteMatchStatement": {
"SearchString": "Y2xvdWRmcm9udC5uZXQ=", //「cloudfront.net」の文字列をBase64にエンコード
"FieldToMatch": { "SingleHeader": { "Name": "host" } },
"TextTransformations": [
{ "Priority": 0, "Type": "NONE" }
],
"PositionalConstraint": "CONTAINS"
}
},
"Action": { "Block": {} },
"VisibilityConfig": {
"SampledRequestsEnabled": true,
"CloudWatchMetricsEnabled": true,
"MetricName": "sample-acl-metric"
}
}
],
"VisibilityConfig": {
"SampledRequestsEnabled": true,
"CloudWatchMetricsEnabled": true,
"MetricName": "BlockCloudFrontDomainACL"
}
}
aws wafv2 create-web-acl \
--region us-east-1 \
--cli-input-json file://create-web-acl.json
CloudFrontのAWSコンソールからCloudFrontの設定を更新します。
WAFのAWSコンソールを確認し、Web ACLのリソースにCloudFrontが追加されていればOKです!
これでブラウザなどから直接CloudFrontディストリビューションドメインでアクセスしようとしているHTTPリクエストをブロックする仕組みができました!(独自ドメインではアクセスできることも併せてご確認ください)
💡Tips💡
WAFではなくCloudFront Functionsで制御する方法はこちら
ハンズオンの片付け
AWSリソースは関連しているリソースが存在している場合は、削除できない場合があります。そのため、依存先の設定やリソースから削除していきましょう。
AWSコンソール上で以下の順番で設定やリソースの削除をしていくと、スムーズに削除できますので参考にしてください。
- お名前.com (※必要な方のみ)
- お名前.comの管理画面でDNSを戻す
- WAF
- 保護リソースからCloudfrontをデタッチ
- リソース自体を削除
- Route 53
- Aレコードを削除
- Cloudfront
- 代替ドメインを削除
- ACMをデタッチ
- Route 53
- (ACM用の)CNAMEレコードを削除
- ACM
- リソース自体を削除
- S3
- ポリシーを削除
- Cloudfront
- リソース自体を無効化
- 最終変更日がタイムスタンプになるまで待つ
- リソース自体を削除
- OAC(オリジンアクセス)を削除
- リソース自体を無効化
- S3
- バケットの中身を空にする
- リソース自体を削除
- Route 53
- ホストゾーンを削除
まとめ
静的ウェブサイトホスティングの記事は多くありますが、AWS CLIの記事が少なかったので今回は「AWS CLIを使った静的ウェブサイトホスティングのハンズオン」を作成してみました。
リソース同士を関連づける設定などはAWSコンソールで操作するとワンアクションで処理してくれることも多いですが、AWS CLIは各リソースを個別に操作するためリソースを直接操作する感覚に近い気がしました。
AWS CLIで実装すると「あれ?ミニマムだとこの設定無くてもよかったんだ」とか「AWS側ではこの設定を一緒に書き換えていたのか」など小さいけど大切な発見がたくさんあるので、是非このハンズオンを機に積極的に取り入れてみてはどうでしょうか?
次回は、この静的ウェブサイトホスティングで公開しているアプリにフォーム機能を実装し、AWS CLIを使用してAmazon SESとLambdaとAPI Gatewayを構築することで、より実用的なWebアプリに仕上げる予定です✨
最後まで見ていただきありがとうございました。
Discussion