COLUMN

サーバーレス初心者がS3＋CloudFrontでWebサイトを運用してみた

EC2でのサーバーとS3でのサーバーレス構成の比較

EC2でサーバーを立てる場合

• サーバーのOSの選定（WindowsやLinuxなど）とOSのアップデートが必要
• ミドルウェアの選定（ApacheやNginxなど）とOSのアップデートが必要
• 好きなOS、ミドルウェアを選べる
• PHPなどサーバーサイドプログラムを動かせる

S3でサーバーレスの場合

• サーバーのOSの選定やOSのアップデートが不要
• apacheやnginxのようなミドルウェアのアップデートをする必要ない
• 上記が不要であるためコンテンツ運用に稼働を費やせる
• 静的コンテンツの際はコストが安くすむ EC2 t2.micro 30GB で毎月11.12USD　S3 +Cloudfront で30GB送受信　で毎月5.58USD　※AWS Pricing Caluculatorで概算

機能要件

• サーバーレス
• 直接コンテンツにアクセスさせない
• IPアドレス制限でアクセスは社内のみ
• httpsアクセスのみ
• 異常時のアラート通知がいく

構成と機能

• S3：静的Webホスティング
• WAF：WebACL＋IP制限
• GuardDuty：S3保護
• CloudFront：直接S3にアクセスさせないhttpsアクセス
• Eventbridge：WAF、Gaurddutyのモニタ
• Cloudwatch：Cloudfrontのモニタ
• SNS：Eventbridge、Cloudwatchのイベントを通知する

構成図

設定手順

• S3で静的Webサイト構築
• Cloudfrontでhttpsのみのアクセス許可、S3へ直接アクセスさせない
• WAFでIP制限、WebACL設定
• GaurdDutyでS3保護
• SNS設定
• WAFの通知設定
• Cloudfrontの通知設定
• GaurdDutyの通知設定

S3で静的Webサイト構築

①S3で静的ウェブサイトホスティングを有効にする

インデックスドキュメントにindex.htmlを指定

②アクセス許可でパブリックアクセスをすべてブロック

静的Webサイトをホスティングできたため

S3にhtmlファイルを置けばひとまずWebサイトだけは完成です。

CloudFrontでhttpsのみアクセス許可、S3へ直接アクセスさせない

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

今回はオリジナルドメインでS3を指定、オリジンパスにindex.html

②ビューワープロトコルポリシー

Redirect HTTP to HTTPSに設定

③WAFの設定後、そのWAFをWebACLと関連づける

WAFでIP制限、WebACL設定

①WAFにてIP制限を決める（IPアドレスとそれを許可するか拒否するか）

②Web ACLを作成

③Add managed rule groupsで適当なものを追加 ①で作成したIPsetを追加

GaurdDutyでのS3保護

①GaurdDutyで　S3保護　を有効化

SNSの設定

①トピックの作成

②作成したトピックから通知先のサブスクリプション（Eメール）の作成をする 　プロトコルはEメール、エンドポイントに送付先を記入しサブスクリプションの作成 　※メールの認証も忘れずに

WAFの通知設定

①WAFはCloudWatchでメトリクスで通知設定する 　ダッシュボードのすべてのアラームからアラーム作成

②必要なメトリクスと条件を選択

③通知は先ほど設定したSNSへ

CloudFrontの通知設定

①CloudFrontはダッシュボードのアラームからCloudwatchの設定ができる

②メトリクス※を選び通知オプションに先ほど作成したSNSを選択し作成

※今回は4xxエラー率と5xxエラー率で作成

Cloudwatchはバージニア北部に作成されるため注意

GaurdDutyの通知設定

①Eventbridgeで設定をする

②イベントパターンを決める カスタムパターンで細かく設定することもできるが今回は以下の設定 イベントソース：AWSのサービス AWSのサービス：GaurdDuty イベントタイプ：すべてのタイプ

③ターゲットをSNSトピックにし、先ほど作成したものを選択 ※入力トランスフォーマーを設定すれば通知内容を整形することもできるが今回はそのままで設定

運用開始後

サーバーレスであるため一度構築してしまえば、サーバーのOSやミドルウェアのアップデートやセキュリティのアップデートの管理が不要でコンテンツの作成に集中できるのはすごく楽に感じました。

ただし、サーバー以外の細かいところで継続的な運用が必要だと分かりました。

WAF

IPsetで許可するIPアドレスの変更

IP制限をかけているが社内のIPアドレスについてもブロックしてしまうなどが発生した場合、許可リストに入っていないことが考えられるためIPsetでIPアドレスを追加する。

WebACLでマネージドルールの最適化

WAFのWebACLで許可されたリクエストやブロックされたリクエストを監視していてその通知に対して以下の措置を検討する

コンテンツの拡張など必要に応じて更なるマネージドルールを追加

ブロックしたものの通知させておき、意図しない通信をブロックされた場合、Rulesでカウントモードにして必要、不要を探る。 ※カウントモードでは検知のみする マネージドルールのバージョンアップで変化があった場合も同様に設定する。

CloudFront

４XX、5XXエラーに対してディストリビューションの再有効化

CloudFrontのアラーム（今回は4XXエラー）が以下で来た場合にエラーカウントに対して通知させているため措置としてディストリビューションの再有効化でエラーカウントが減るか様子見をする

４XX、５XXごとのエラーページの作成

デフォルトのエラーページだけでは以下のようなページで不十分

セキュリティの脆弱性対策のため、各エラーに対してページを作成する。

エラーページを作成してS3におくことでカスタマイズもできる

地理的制限

また一部のエリアからアクセスが多いリスクが発生した。

日本だけ閲覧できるようにするか、アクセスの多い国をブロックする。

S3

バージョニングとライフサイクルルールの設定

コンテンツの世代管理するために、バケットのバージョニングを設定する

ライフサイクルルールで非現行バージョンをストレージクラスを移行する

ストレージクラス、現行でなくなって何日後に移行か、保存するバージョン数を コストを考慮しながら検討する

GuardDuty

S3の設定変更などで以下のような通知があったとき、事象の確認と対処の有無を確認

上記ではブロックパブリックアクセスが無効となったためGuardDutyで確認

該当のS3と作業したものが特定できる。

最後に

サーバーレスでの運用は、ほぼ手間いらずで、EC2の運用よりは楽であると思っていましたが、異常時などの通知があったときの措置や都度の設定変更が必要であると分かりました。

ただし、サーバやOSの運用が不要であるため、異常時などの対応に注力できることは嬉しいですね！