1. はじめに
「生成AIを活用して過去の写真の情報をもとに旅行プランを生成する」仕組みの実現に関する記事の第5回です。記事は参加したメンバと分担して作成しており、今回は私が担当します。
前回の記事までで旅行プランの生成・htmlファイルとしての出力までが実現できました。今回の記事ではWebコンテンツを公開する仕組み作りにチャレンジします。
構成のベースも生成AIに考えてもらい、生成AIの回答は正しいとは限らないという前提のもと生成AIに提示された構成を参考にして調査して環境を作り上げていきます。生成AIに大枠を考えてもらい、AWS認定資格の学習で身に着けた知識で良し悪しを判断する形で進めます。
関連記事
生成AIを使った仕組みを考えてみた 第1回：アイデア出し編
生成AIを使った仕組みを考えてみた 第2回：写真の内容を解析しデータを貯める仕組み
生成AIを使った仕組みを考えてみた 第3回：蓄積されたデータを基に旅行プランを生成する（蓄積データの活用編）
生成AIを使った仕組みを考えてみた 第4回：蓄積されたデータを基に旅行プランを生成する（音声ファイル編）
要件・構成の検討
今回作りたい仕組みは、記事の第3回、4回でS3バケットに出力したhtmlをコンテンツとしたWebページをインターネットに公開する仕組みです。この部分にフォーカスして検討を行います。
構成を検討するにあたり極力AWSサービスのサービス名を指定しない形で生成AIに問い合わせてみました。ポイントとして生成AIによる「もっともらしい嘘」に惑わされないよう「細かい解説は不要」の一文を入れています。
AWSでWEBコンテンツを公開する仕組みを作りたいです。
極力少ないAWSサービスで実現する方法を教えてください。細かい解説は不要です。
要件
１．HTTPSでWEBブラウザからアクセスできます。
２．このコンテンツはAWS環境にアップロードすることで公開されます。
３．このコンテンツにはユーザID及びパスワードでのアクセス制限を行います。
４．このコンテンツは、特定の拠点からのアクセスの場合認証なしで閲覧できます。
５．このシステムは、独自のドメインを使用しAWSで管理します。
生成AIの回答
以下の構成をお勧めします：
Amazon S3: コンテンツのホスティング。
Amazon CloudFront: HTTPSアクセスの提供とコンテンツ配信。
AWS Certificate Manager (ACM): SSL/TLS証明書の管理。
Amazon Route 53: 独自ドメインのDNS管理。
Lambda@Edge: ユーザー認証の実装と特定の拠点からのアクセス制御。
この構成により、最小限のAWSサービスで要件を満たすことができます。
今回使用するサービスは、上記の5つであるという回答でした。
なるほど、見た感じ全体構成として考えたものとほぼ同じですね。
構成イメージ
文章だけだと想像しにくいので、構成のイメージを作成しました。
今回作る範囲は以下の黄色い枠の範囲です。
2. 仕組みの構築
作成したイメージをもとにそれぞれのサービスの設定を行います。
2.1 ドメインの準備
この仕組みはインターネットから使用するシステムとしたいため、Route 53のパブリックホストゾーンを使用します。今回は既存のRoute 53で管理しているドメインを使用しています。新規取得ではないため、こちらの記事ではRoute 53への移管については割愛します。
2.2 SSL/TLS証明書の取得と設定
HTTPSアクセスする際に使用される証明書を、AWSが提供する証明書管理サービスであるAWS Certificate Manager (ACM) で発行します。ACMではパブリック証明書を無料で発行できます。
AWS Certificate Manager (ACM) で証明書を取得
※今回取得する証明書は、CloudFront用となります。CloudFrontで使用する証明書は米国東部 (バージニア北部) リージョン (us-east-1) の証明書である必要があるので注意しましょう。
ACMコンソールへ遷移しバージニア北部リージョンであることを確認できたら、「リクエスト」を押下します。
「証明書をリクエスト」の画面で、「パブリック証明書をリクエスト」を選択し次へを押下します。
今回のサイトで使用するドメイン名を入力して、その他項目はデフォルト値のままリクエストを押下します。
証明書の発行リクエストにより証明書が作成されますが、この段階ではステータスが「保留中の検証」となります。今回はDNSを用いてドメインの所有者であることの検証を行います。
「Route 53でレコードを作成」を押下します。
画面が遷移しますが、この画面だと検証が成功したかが分かりません。
再度、作成した証明書の画面に遷移しましょう。ステータスが発行済となっているはずです。無事、DNSによる検証が終わり証明書の発行ができました。
2.3 Amazon CloudFront の設定
この仕組みでは、前回の記事で作成したS3バケットを参照するようにCloudFrontの設定を行います。S3単体でもWebホスティング機能はあるのですが、S3に格納したコンテンツをHTTPSで公開するにはCloudFrontを使用する必要があります。この設定により、インターネットから作成したコンテンツを参照できるようにできます。
CloudFrontディストリビューションの作成
CloudFrontコンソールより、ディストリビューションを作成を押下します。
オリジンに、前回の記事で作成したS3バケットを指定します。
オリジンアクセスには「Origin access control settings」を指定します。この設定により一般公開していないS3バケットのコンテンツを今回使用したCloudFrontから参照できるようにします。
「Create new OAC」を押下し、任意の名前で作成します。
「設定」の「代替ドメイン名（CNAME）」へ証明書取得時に設定したドメイン名を指定し、「Custom SSL certificate」で取得した証明書を指定しましょう。
S3に格納されているファイルは現時点では見られたら困る内容でないため、動作確認しやすいようアクセス制限の設定は後から行うこととします。S3バケットの指定、オリジンアクセス、ドメインの設定、証明書の指定以外はデフォルト設定のまま「ディストリビューションの作成」を押下するとCloudFrontディストリビューションが作成されます。
画面上部にメッセージが出ていますが、S3のバケットポリシーを更新する必要があります。S3バケットに対して、CloudFrontからのアクセスを許可するポリシーの設定を行いましょう。「ポリシーをコピー」を押下すると、設定すべきポリシーがクリップボードにコピーされます。
コピーされるポリシーは以下のもので、今回作成したCloudFrontからのみ当該S3バケットのオブジェクトを取得することを許可するようなものとなっているようですね。
S3コンソールより今回使用するS3バケット指定し、コピーしたポリシーの設定を行います。
json形式でのポリシー作成は難しそうですが、今回はコピーしたものをペーストするだけです。恐れずに「編集」を押下しましょう。
ポリシーエディタにペーストして、「変更の保存」を押下します。
これだけでS3側の設定は完了となります。
動作確認
この時点でアクセスできるか確認してみましょう。「ディストリビューションドメイン名」に記載されているドメイン名をWebブラウザに入力して、前回出力したhtmlを指定すると以下のようにインターネット経由でhtmlファイルを参照することができます。
続いてCloudFrontで指定した代替ドメイン名を指定してアクセスをしてみましょう。
ページに到達できませんね。現時点で実施したCloudFrontの代替ドメイン名の設定だけでは、ドメインとCloudFrontの紐づけが出来ていない状態となっているようです。
2.4 Amazon CloudFront へのドメイン名の紐づけ
指定したドメインを使用して作成したCloudFrontディストリビューションにアクセスするための設定を行います。
CNAMEレコードの作成
CloduFrontへアクセスする際に利用するカスタムドメインの設定を行います。先ほど画面確認したCloudFrontディストリビューションの「ディストリビューションドメイン名」を控えておきましょう。
Route 53コンソールより、今回使用するホストゾーンを指定した後「レコードを作成」を押下します。
レコードタイプを「CNAME」とし、値には控えておいたCloudFrontディストリビューションの「ディストリビューションドメイン名」を設定しレコードを作成しましょう。
動作確認
Webブラウザより、設定したドメインを使用してアクセスしてみましょう。
想定通りアクセスすることが出来ました。ACMで発行した証明書が適用されていることも確認できますね！
ここまででS3に格納したhtmlファイルをインターネット経由でアクセスできる仕組みを作ることが出来ました。インターネットへの情報公開は難しいものにも思いがちですが、結構簡単に実現できました。
2.5 認証設定
今のままでは、インターネットアクセスができる人であれば誰でもアクセスできてしまいます。今回の仕組みで公開する情報は自分向けの旅行プランなので、他の人に見られると自分の趣向がバレて恥ずかしいかもしれません。そこでアクセスできる人を限定する仕組みを設定します。
CloudFront利用時に認証の設定をする方法としてはCognitoの利用、Lambda@Edge、CloudFront Functionなどの方法があります。今回は、生成AIに推奨されたLambda@Edgeという機能を使用して実現していきます。
Lambda@Edge ファンクションを作成
マネジメントコンソールの検索窓よりLambdaを検索し、Lambda管理画面へ遷移します。
今回作成するLambda関数はCloudFrontに紐づけるものであるため、バージニアで作る必要があります。マネジメントコンソールでバージニアリージョンとなっていることを確認したうえで、関数を作成を押下します。
任意の関数名を設定し、ランタイムはPythonを指定します。実行ロールは新規のロールを作成する設定とし、「関数の作成」を押下します。
ユーザーIDとパスワードによる認証ロジックの実装
今回使用するロジックは生成AIが生成してくれた以下のものです。コメントで記載されている認証情報を設定する箇所を書き換えれば対応できそうです。
import base64
def lambda_handler(event, context):
request = event['Records'][0]['cf']['request']
headers = request['headers']
# 認証情報を設定
auth_user = 'username'
auth_pass = 'password'
auth_string = f'{auth_user}:{auth_pass}'
auth_string_enc = base64.b64encode(auth_string.encode()).decode()
if 'authorization' in headers:
auth_header = headers['authorization'][0]['value']
encoded = auth_header.split(' ')[1]
if encoded == auth_string_enc:
return request
else:
return _response_403('Invalid credentials')
else:
return _response_401()
def _response_401():
return {
'status': '401',
'statusDescription': 'Unauthorized',
'headers': {
'www-authenticate': [{
'key': 'WWW-Authenticate',
'value': 'Basic'
}]
}
}
def _response_403(message):
return {
'status': '403',
'statusDescription': 'Forbidden',
'body': message
}
認証情報を任意のものに書き換え、Lambdaのエディタ部分に貼りつけDeployを押下します。CloudFrontと関連づけるため、トリガーを追加を押下します。
トリガーにCloudFrontを指定し、Lambda@Edgeへのデプロイを押下します。
今回作成したCloudFrontディストリビューションを指定してデプロイしたところ、エラーとなりました。
Lambda@Edgeを使用するためには、Lambdaに割り当てたロールの修正が必要となるようです。
今回作成したLambda関数に割り当てたロールに対し、上記ページに記載のある信頼ポリシーの設定を行いポリシーを更新します。
再度Lambda@Edgeへデプロイしたところ、エラーなくデプロイできました。
認証の動作確認
割り当てたカスタムドメインを使用してサイトにアクセスをしてみたところ、想定通りに認証を求められました！コードに記載したユーザ名、パスワードを入力したところ無事htmlが表示されました。想定通り動いていますね！
念のため誤ったユーザID/パスワードを入力し、正しい認証情報出ない場合は閲覧できないことも確認します。認証機能を導入する際は、誤った情報の場合はアクセスできないことを確認するのも大事です。
2.6 特定拠点からのアクセス許可設定
毎回認証を求められてしまうと、ちょっと面倒ですよね。今回の仕組みを社員旅行など、社内レクレーションに活用することを想定すると、特定のIPアドレスからのアクセスの場合は認証なしで閲覧できる仕組みを実装します。
生成AIに
lambdaのコードを修正したいです。
特定の拠点（IPアドレス）からのアクセスの場合は、認証せずにアクセスできるようにしてください。
とインプットしたところ、以下の回答を得られました。ほんの数行しか変わっていませんが、IPアドレスのチェックをするロジックが追加になっていますね。
import base64
def lambda_handler(event, context):
request = event['Records'][0]['cf']['request']
headers = request['headers']
request_ip = request['clientIp']
# 許可されたIPアドレスのリスト
allowed_ips = ['123.456.789.0', '987.654.321.0'] # 変更する必要があります
# クライアントIPアドレスが許可されているかをチェック
if request_ip in allowed_ips:
return request
# 基本認証の設定
auth_user = 'username'
auth_pass = 'password'
auth_string = f'{auth_user}:{auth_pass}'
auth_string_enc = base64.b64encode(auth_string.encode()).decode()
if 'authorization' in headers:
auth_header = headers['authorization'][0]['value']
encoded = auth_header.split(' ')[1]
if encoded == auth_string_enc:
return request
else:
return _response_403('Invalid credentials')
else:
return _response_401()
def _response_401():
return {
'status': '401',
'statusDescription': 'Unauthorized',
'headers': {
'www-authenticate': [{
'key': 'WWW-Authenticate',
'value': 'Basic'
}]
}
}
def _response_403(message):
return {
'status': '403',
'statusDescription': 'Forbidden',
'body': message
}
Lambdaのコードを更新し、Deployします。
動作確認してみますが、どうやら認証がかかったままのようです。
CloudFrontへの紐づけが正しくできているか確認してみましょう。
CloudFront > ディストリビューション > ディストリビューション名 > ビヘイビア > 編集 より、ビヘイビアに関連付けられた関数を確認したところ、関数ARNの最後に「:1」がついているようです。
今回作成したLambda関数を確認するとLambda関数自体のARNの末尾には「:1」がついていないようです。
バージョンタブより「1」を確認したところ、「バージョン:1」のARNが「:1」が付いたものとなっていました。CloudFrontに紐づけるLambda関数のバージョンを更新してあげる必要がありそうですね。
一つ上の階層に戻り、アクション > 新しいバージョンを発行 より、新しいバージョンを発行します。
以下のように「バージョン:2」が発行されます。
CloudFront > ディストリビューション > ディストリビューション名 > ビヘイビア > 編集 より、ビヘイビアに関連付けられた関数を更新します。関数ARNの最後を「:2」に書き換えてみましょう。※CloudFrontへの反映には時間がかかります。
認証を求めない拠点からのアクセス動作確認
CloudFrontへの反映がされたころを見計らって再度アクセスしたところ、認証なしでアクセスすることが出来ました！
別の回線からアクセスすると、想定通り認証を求められました！
おわりに
生成AIにアドバイスをもらいながら設計・構築することで定めた要件を実現することが出来ました。生成AIの活用によりAWSを使用した仕組みの構成検討や、Lambdaのコード作成などにかかる時間は大幅に短縮できますね。
今回は生成AIのアドバイスをもとに進めましたが、S3上のファイル公開だけであればAmplify ホスティングを使用した方が手軽に実現できたかもしれません。生成AIのアプトプットを鵜呑みにせず、正否を判断する知識をしっかり持ったうえで、生成AIを活用していきましょう！