Amazon S3 を活用した静的ウェブサイトによるご当地キーホルダー収集運用の改善

Transcript

1. Amazon S3 を活用した静的ウェブサイトによる ご当地キーホルダー収集運用の改善 2026/5/23（土） JAWS-UG 栃木 オフライン # 8 -ロゴお披露目回- 晴海（はるみ）
2. １．自己紹介 •晴海（はるみ） • 金融機関のIT部門に所属 • 趣味：マンホールカード集め、スタバ電子スタンプ集め • re:Invent 2025 に行きました
3. ２．はじめに みなさん、ちいかわって知っていますか？
4. ２．はじめに • そう、あの”ちいかわ”です。 • さまざまなグッズが展開されている。 • グッズの中にご当地キーホルダーがある。
5. ２．はじめに • 会社の先輩が、ご当地キーホルダーを集め始めた。 • 私を含め、会社の同僚がプライベートで旅行に行った際に、 お土産としてキーホルダーを買ってくる、という流れができ あがった。
6. ３．課題 • 購入したキーホルダーが徐々に増え、記憶で管理することが 難しくなってきた。 • 会社の先輩は、個人のプライベートPCのExcelを利用して管理 するようになった。（ローカル環境）
7. ３．課題 • 会社の同僚が旅行に行ったときにキーホルダーを売っているのを見つ ける。 ただし、見つけたキーホルダーが購入済みなのかすぐにわからない。 • 休日に本人（会社の先輩）に連絡して聞く ⇒休みの日にも関わらず連絡が来ることで、 “仕事でなにか課題か？！”という緊張が走る。 • 本人に確認せずに購入する ⇒同一種類のキーホルダーの購入がバッティングしてしまう 懸念がある。（実害あり）
8. ４．課題解決に向けて • AWSの資格勉強（AWS SAA、AWS DVA）の過程でS3の静的ウェブ サイトホスティングの存在を知る。 • 机上で学んだことを、実生活の課題解決につなげることがで きるのでは、と思いつく。
9. ５．S3 の静的ウェブサイトホスティングとは • S3バケットをWEBサーバーとして利用し、 HTML / CSS / JavaScript などの静的コンテンツを配信する機能。 • 構築手順概要 • S3バケットに静的ファイル（HTML、CSS、JS、画像など）をアップロード • バケットの「静的ウェブサイトホスティング」を有効化 • バケットポリシーでパブリックアクセスを許可 • S3が自動的にHTTPエンドポイントを提供 （http://<bucket-name>.s3-website-<region>.amazonaws.com）
10. ５．S3 の静的ウェブサイトホスティングとは • 主な特徴 • サーバー管理不要（フルマネージド） • 高い可用性と耐久性（99.999999999%の耐久性） • 従量課金（ストレージ + GETリクエスト数 + データ転送（量）） • スケーリングの心配なし • インデックスドキュメント（index.html）とエラードキュメント（404.htmlな ど）を指定可能 • 制限事項 • サーバーサイド処理は不可（PHP、Node.jsなどのバックエンド処理は動かな い） • HTTPSは直接サポートされない • 動的コンテンツの生成はできない
11. ６．ウェブサイトの作成 • 作成は Kiro を利用して仕様駆動開発で作成 • 作成したプロジェクトは Amazon Q Developer でコードレビュー
12. ６．ウェブサイトを作成する • Kiro を利用して仕様駆動開発（Specモード）で作成 • 構成は一般的、最小構成のウェブサイト • index.html • style.css • script.js （キーホルダー収集状況の計算、テーブル描画） • data.json （キーホルダー収集状況の実データ保持ファイル） • Kiro はドキュメント添付機能（IDE）に対応。（2026/3/11） 9種類のネイティブ対応。 ⇒この新機能を利用して、もともとExcel管理していた収集状況一覧のファイ ルを取り込むことにした
13. ６．ウェブサイトを作成する • 作成したプロジェクトは Amazon Q Developer でコードレビュー Critical, High, Medium, Low, Info といった区分でレビュー結果を表示 レビュー結果の解説を Chat 画面に表示 レビュー結果位置をコード上に表示
14. ６．ウェブサイトを作成する • 出来上がったウェブサイトはこちらです。 ＜PC イメージ＞ ＜スマホイメージ＞
15. ７．新たな課題 • ウェブサイトはできあがり、いざ公開。 • そんな時に、Qiita でこのような投稿が公開された。 • https://qiita.com/miruky/items/b996e374c91923141178 miruky（@miruky） さん
16. ７．新たな課題 • 記事に書いてある事態要約 • S3の料金体系はストレージ料金、GETリクエスト数、データ転送（量）の3つ。 • データ転送の料金が一番高い。 • DDoS攻撃を受け、大量のデータ転送が発生。 • 結果、約200万円の請求が届いてしまった。 • バケットポリシーでパブリックアクセスを許可している。 （＝ S3バケットが直接インターネットに公開されている状態） 攻撃者はバケット内のオブジェクトに対して大量のGETリクエストを送 信することができてしまう。
17. ８．対策 以下の内容を適用することにした。 ① S3 Block Public Access を有効にする （S3バケットを直接公開しない） ② CloudFront + OAC でウェブサイトを配信する
18. ８．対策 ② CloudFront + OAC でウェブサイトを配信する • OACとは • CloudFrontからS3へのアクセスを安全に制御する仕組み。 • S3バケットへの直接アクセスをブロックしつつ、CloudFront経由のアクセスだ け許可するために使う。 • CloudFront を利用することで、AWS Shield Standard が自動有効 • DDoS保護が行われる
19. ９．そして公開へ • キーホルダーの収集状況を24時間365日、どこからでも確認できるよう になった。 • ウェブサイトなので、URLを送るだけで容易に共有ができる。 • 運用コストは月あたり 1円 程度。 • 本人に所有状況を確認せずとも、自身で把握することができるように なった。 • キーホルダーの購入の重複を防止することができるようになった。 当初発生していた課題を解決することができた
20. １０．学び • S3 + CloudFront を利用することで比較的安全・容易に静的なウェブ サイトが公開できることを、実際に手を動かして学ぶことができた。 • AWS のコンセプトである”ビルディングブロック”を改めて経験する ことができた。 （当初 S3 のみでウェブサイトを公開 → CloudFront を追加） • 自身が勉強した内容を実生活で、誰かの課題を解消させる、という経 験をすることができた。 ⇒机上での勉強止まりではなく、人の役に立てることができた ⇒この発想に至るには勉強が必要