静的サイトホスティング（S3 + CloudFront）
S3にビルド成果物を置き、CloudFront(OAC)で安全・高速・低コストに配信する構成。このサイト自身もこれ。
基礎コスト最適化パフォーマンス効率セキュリティ運用上の優秀性
このパターンは？
HTML/CSS/JS（やSPA、静的サイトジェネレータの出力）を、サーバーレスで世界配信する最小・最安構成。このサイト自身がこの構成で動きます。
構成
[ユーザー]
│ HTTPS
▼
Route 53 (DNS, Alias) ──► CloudFront (CDN, OAC, ACM証明書)
│ 署名付きS3リクエスト
▼
S3 (非公開バケット: ビルド成果物)
CI/CD: GitHub Actions ─(build)→ out/ ─(sync)→ S3 ─(invalidation)→ CloudFront
各コンポーネントの役割
- S3: ビルド成果物を保存。Block Public Access 有効のまま非公開
- CloudFront: エッジ配信＋HTTPS。OACでS3を非公開のまま読む
- Route 53: 独自ドメイン。apexはAliasでCloudFrontへ
- ACM: TLS証明書（us-east-1のものをCloudFrontで使用・無料）
バケット公開はNG
S3を全公開して配信するのはアンチパターン。CloudFront + OACでS3は非公開のまま配信するのが正解です。
設計の勘所
- デプロイは
build → S3へsync → CloudFrontをinvalidation - キャッシュはファイル名にハッシュを付け、
index.htmlは短いTTLに - ディレクトリURL（
/aws/）はCloudFront Functionでindex.htmlへ書き換え
Well-Architected の観点
- コスト最適化: サーバーレス・CloudFront無料枠が大きい
- パフォーマンス効率: エッジキャッシュで高速
- セキュリティ: 非公開S3＋OAC＋HTTPS、必要ならKMS・WAF
- 運用上の優秀性: CI/CDで自動デプロイ
よくある落とし穴
アンチパターン
- S3バケットを公開して配信（OACを使わない）
- ACM証明書をus-east-1以外で作りCloudFrontに付けられない
- デプロイ後にinvalidationを忘れ、古いコンテンツが残る
監視・アクセス分析は CloudWatch やCloudFrontログで。
AWS Pattern
静的サイトホスティング（S3 + CloudFront）を実務で読む
TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。
解決すること
cost
比較で見る軸
クラウド: AWS / 難易度: basic / 関連サービス: 5件
導入後に効く点
S3にビルド成果物を置き、CloudFront(OAC)で安全・高速・低コストに配信する構成。このサイト自身もこれ。
先に潰すリスク
パターンをそのまま写すのではなく、可用性、権限、ネットワーク境界、運用手順を自分の要件に合わせる必要がある。
数字・仕様の読み方
- クラウド
- AWS
- 難易度
- basic
- 関連サービス
- 5件
- 設計柱
- cost / performance / security / operational
判断チェックリスト
- 自社の用途が「cost / performance」に近いか確認する。
- 強みである「S3にビルド成果物を置き、CloudFront(OAC)で安全・高速・低コストに配信する構成。このサイト自身もこれ。」が本当に評価軸になるか確認する。
- 注意点の「パターンをそのまま写すのではなく、可用性、権限、ネットワーク境界、運用手順を自分の要件に合わせる必要がある。」を運用で吸収できるか確認する。
- 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
- 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
- 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。
次に確認する観点
costperformancesecurityoperationalAmazon S3Amazon CloudFrontAmazon Route 53AWS KMS