CloudFrontとLightsail

今回紹介する『CloudFrontとLightsail』は、Drupalで構築し構造を含めてhtml化したWebサイトを『公開』する為の要になっています。『CloudFrontとLightsail』を使いhtml化したWebサイトを公開する方法をまとめてみました。

実際の作業として行った、Lightsail Binamiで運営中のDrupalから、静的配信用に新たにLightsailで構築したサーバーに載せ替えを行う過程をまとめています。

Notice

AWSの細かな設定情報は、セキュリティに関わるので今回紹介を見送りました。

昨今AIを使用し量産されていると考えられる攻撃ツールが増えています。AWSに限らず、私が書いた設定情報をAIが学習し、AIの学習自体に悪意はなくても、利用者の悪意に使用される可能性を考慮する必要があると考えています。

ここで述べた善意の情報公開が悪意に利用されるということは、その影響は当サイトだけではないのでは？と考えての対応になります。

現実問題として、私の設定記事程度（基本は公開情報の延長）ではあるので、学習という観点であればそれほどの価値はありませんが、私が書いた使い方の知見といった具体的な要素をAIが学習する可能性は十分あります。

その知見で述べた、セキュリテイの基本である防御に関わる情報をAIが学習し、逆となる攻撃に関わる質問に対する回答のヒントとなり得ることも、現在の確率論で形成されるLLMの推論の開発からは否定できないということが、実際の設定情報を記事に載せない方が良いのではという今回の対応の結論になっています。

今回Jamstack化に必要なAWSの構成と設定をまとめています。

今回は、旧BitnamiのDrupalを動かしながら、新たにJamstack化したサイトを構築し、切り替えしていますので、その過程をまとめています。

CloudFrontを利用するにはSSL証明書をACMから取得する必要があります。

実際の手順は以下になります。

1. AWSコンソール → Certificate Manager → リージョンを us-east-1に切り替え
2. 証明書をリクエスト → パブリック証明書
3. ドメイン名を追加 : inter-est01.com、*.inter-est01.com
4. 検証方法: DNS検証
5. 発行されたCNAMEレコードをLightsail DNSに登録（Route 53設定後はRoute53に登録します）
6. ステータスが「発行済み」になれば完了

CloudFrontで利用するSSL証明書の発行が完了しました。

CloudFrontはAWSが提供するCDN(コンテンツ配信ネットワーク)であり、キャッシュと世界規模のエッジロケーションを使い、高度に最適化された配信ネットワークを持っています。標準でファイアウォールが搭載され、WAFもオプションで無料から選べますので、高いセキュリティでオリジンサーバーを保護します。

Bitnami Drupalでは使用していなかったのですが、今回、静的化での配信に切り替えるので、CDNを利用するメリットが大きいと考え導入しました。本来、大規模なサイトで使用する高機能なCDNであり、クラスタリングなども柔軟に行えるCDNですが、全てAWSで構成される親和性の高さから、私のような小規模なサイトでも使い勝手が良いのがAWSの特徴でもあります。

CloudFrontディストリビューション作成します。

• AWSコンソール → CloudFront → ディストリビューションを作成

オリジン設定 

• Origin type : Custom originOrigin domain : (任意のサブドメインを選択).inter-est01.com
• Lightsail DNSにAレコード作成: (任意のサブドメインを選択).inter-est01.com → 111.222.333.444 (Lightsialの静的IP）
• プロトコル : HTTPのみ

Notice : CloudFrontコンソールはベアIPアドレスを受け付けないためDNS名が必要です。

キャッシュ設定

• Cache policy : CachingDisabled（TTL=0、オリジンから毎回取得）
• Origin request policy : AllViewer（全ヘッダーをオリジンに転送）

WAF設定

• WAF有効化（無料プランで基本的な保護＋レート制限）

HTTPS設定

• Viewer protocol policy : Redirect HTTP to HTTPS
• SSL証明書 : #1で発行したACM証明書を選択

CNAME設定

• inter-est01.com
• www.inter-est01.com

以上でCloudFrontの基本的な設定が完了します。

Lightsail DNSはApexドメインをCloudFrontにALIASできないためRoute 53に移行します。Route53の設定が完了しDNSが切り替わるとBitnami Drupalは#2で設定したCloudFront経由での配信に切り替わります。

Route 53でホストゾーン作成

• Route 53 → ホストゾーンを作成 → inter-est01.com

レコードを作成

• inter-est01.com | A（ALIAS） | (提示された英数字).cloudfront.net
• www.inter-est01.com | CNAME | (提示された英数字).cloudfront.net
• (任意のサブドメイン).inter-est01.com | A | 111.222.333.444（旧BitnamiのIP)
• メール関連 | MX/TXT/CNAME | 旧DNSから転記します。

Route 53のNSレコード（4件）をドメインレジストラに設定します。DNS反映を待ちます（数分〜数時間）。

DNSが切り替わると、Bitnami DrupalがCloudFront経由で配信されます。

私はDrupalのログインに自作モジュールでIP制限をかけています。CloudFront経由になるとDrupalのIPアクセス制限モジュールが実クライアントIPを見られなくなりログイン不可となるので、settings.phpに以下を追記して修正します。

Drupal reverse proxy設定をします。

# sudo nano /opt/bitnami/drupal/sites/default/settings.php
以下を追加します。
if (PHP_SAPI !== 'cli') {
  $settings['reverse_proxy'] = TRUE;
  $settings['reverse_proxy_addresses'] = [$_SERVER['REMOTE_ADDR']];
}
追加し保存したら
# drush cr

以上で、Bitnami DrupalがCloudFront経由で配信されます。載せ替えるJamstack用のLightsailの設定とコンテンツのアップロードが完了したら、Route53でLightsailのIPアドレスを変更するだけで、切り替えが完了する設定になっています。

静的ファイルを置く新サーバーをLightsailに構築します。

インスタンスを作成します。

• リージョン : 任意（実際のリージョンの公開は控えます）
• Blueprint : Ubuntu 24.04 LTS（OSのみ）
• プラン : $12/月（2GB RAM / 2vCPU / 60GB SSD）
• SSHキー : 既存のキーを使用
• 作成後、静的IPを割り当て（111.222.333.444）

初期セットアップ

# ログイン
ssh -i ~/.ssh/(Any name).pem ubuntu@111.222.333.444

# システム更新
sudo apt update && sudo apt upgrade -y

# カーネル更新があった場合は再起動
sudo reboot

続けて、Apcheの設定とドキュメントルートの設定、バーチャルホストの設定、セキュリティ設定、内部ルーティングの設定を行いますが、文初に書いたセキュリティ面を考慮しここに掲載するのを控えています。

Lightsailの設定が完了したら、Tomeで作成したhtml化したコンテンツをアップロードします。

ローカル環境でDrupalを使い構築しTomeで静的化したコンテンツをCloudFrontで実際に配信します。

これまでの作業で、Bitnami DrupalをCloudFrontで配信しておりRoute53でDNSの管理をしていますので、切り替えは、Route53の『オリジンサーバーに設定したAレコードを新サーバーのIPに変更』するだけで、切り替えが完了します。

#3 Route53の項で説明した

(任意のサブドメイン).inter-est01.com | A | 111.222.333.444（旧BitnamiのIP)

を

(任意のサブドメイン).inter-est01.com | A | 555.666.777.888（新LightsailのIP)

に切り替えるだけで、CloudFront > Bitnami Drupal が、CloudFront > Lightsailに設置した静的ファイルに切り替わりJamstack化が完了します。

TTLを0秒（変更を都度確認）にしてありますので、更新は自動で行われますが、CloudFrontはエッジ化されたグローバルなキャッシュサーバーでもありますので、切り替えのタイミングで旧コンテンツの配信が混ざってしまわないよう、念の為キャッシュをクリアします。

CloudFrontコンソール → ディストリビューション → Invalidations → Create invalidation → /*(コンテンツ全て)の操作で全てのキャッシュがクリアされ、新サーバーもコンテンツが確実にキャッシュされます。

前回の記事で書いた、ローカル上でDrupalを使いTomeで構築した静的ファイルを、新しく立ち上げ、sshとApacheのみを解放し、CloudFrontとの内部ルーティングを設定した Lightsailにアップロードすると、 Jamstackが完了します。

一つ一つのプロセスや、設定が面倒に感じますが、非常に簡単に作業が完了します。

AIの表裏

今回記事を書くうえで、悩んだのが、私の書いた記事が、必要としている方のガイドになると考えこれまで情報公開していましたが、今年に入り、AIの悪意の利用(安易な攻撃ツールの量産など)が増えています。

大小様々なAIプロジェクトが立ち上がり、AIBotが大量にWebサイトにアクセスし、LLMの学習をしています。通常の利用であれば私も学習に協力したいと考えていましたが、現時点のLLMは、利用者の善悪までは、考慮されていない状況であり、残念ながら、悪意の利用が目立つ状況であり、善意の情報公開をAIが学習し、悪意の利用に使われるという状況に対しては対策を考える必要があると考えています。

そのような状況であるので、記事の内容をどうするか考えることに時間を取られているような状況であり、実際の公開内容も実例をもとにしたチュートリアル的な内容の公開が難しくなっています。

私の書いた記事が直接攻撃ツールのヒントになるとは考え難いのですが、サーバー設定の実例などは、攻撃ツールを構成するヒントや要素の一つになり得るとも言えます。

私自身もAIは、思考の整理や翻訳、私が知らなかった技術的な視野を広げたり、サイト構築の実験の相棒といった有機的なツールとして重宝しています。

視野を広げてみると、そうではない利用が世間に溢れています。一例としてDrupalのコミュニティで起きた、今年5月のPostgresqlのセキュリティ対応から11.4.xのアップデート、広範囲な不具合発生などは、急速に増えているAIによる攻撃ツールの普及(高度な攻撃の一般化)による影響でもあると考えています。

今回、Web上のDrupal(CMS)を物理的に無くし、静的ファイルで配信するJamstackに切り替えたのは、AWSのブルーポイントのサポート終了という直接の理由がありますが、昨今のCMSやフレームワークのセキュリティ対応が、過去に比べ頻繁になり、アップデートによる不具合の顛末を考えると、静的化による攻撃の無効化とアップデートの不具合のリスクを極力減らすという一つの選択種が私が急遽Jamstackに切り替えた理由にもなっています。

新しい技術には表裏の要素が必ずあります。表だけでなく裏も考え、Webサイトによる情報公開という一見AIには関係なさそうなものにおいても、AIの利用や、AIの学習といった目の前で起きている状況を正確に把握し、対応する必要があると考えています。