AWS設計書

さくらのレンタルサーバー

1. サーバーダウン時に取れる対応がない
   • 復旧をホスティング事業者に委ねるしかなく、復旧見込みが立たない
2. DNS を親会社が管理しており、障害時にレコードを変更できない
   • 別サーバーへ退避する手段が取れない
3. 冗長構成を組めない
   • 単一障害点をそのまま抱え続けている

課題1と2が重なることで、「障害が起きたら復旧を待つしかない」状態となっている。
これが本件の最も重要な解決対象である。

1. サーバー障害という概念をなくす
   • サーバーを持たない構成（S3 + CloudFront）とし、維持管理の対象を排除する
2. リージョン障害でもサイトを落とさない
   • S3 を東京・大阪の2リージョンに配置し、自動フォールバックさせる
3. DNS レコードの変更なしで可用性を保つ
   • 障害時の切り替えを CloudFront 内部で完結させ、親会社への作業依頼を発生させない

DNS の宛先は CloudFront に固定されたまま変わらない。オリジン（S3）の切り替えは CloudFront の内部で完結する。

1. サーバーを持たない構成が組める
   • ファイル保管（S3）と配信（CloudFront）のみで完結する
   • OS・ミドルウェアの保守、脆弱性対応、スケーリング設計が不要になる
2. DNS 変更なしでオリジンを冗長化できる
   • CloudFront の Origin Group により、切り替えを内部で完結できる
   • 本件の最重要要件を満たす唯一の現実的な手段
3. 配信に必要な要素を統合管理できる
   • CDN・WAF・証明書・監視・監査ログが同一基盤上で一元管理できる
4. アクセス変動に自動で追従する
   • 事前のサイジングが不要。プレスリリース公開時などの急増にも自動対応する

1. 費目のほぼ全額が WAF である　本番・ステージング合わせて $20。アクセス数に関わらず固定的に発生する
2. 配信費用はほぼ発生しない　CloudFront の無料枠（転送1TB・リクエスト1,000万）に収まるため
3. ストレージ費用は無視できる　サイト容量 100MB では月 $0.01 程度にとどまる

転送量よりもリクエスト数が先に上限に達する。1 PV あたり15リクエストで算定すると、月間約65万 PV が無料枠の境界となる。現行想定（20万 PV）の3倍以上にあたるため、当面の超過は見込まれない。

AWS Budgets により月額 $50 超で通知する設定とし、攻撃による異常なアクセス増も早期に検知する。

株式会社NTTデータCCS 様（AWS アカウントの所有者・請求先）

NTTデータCCS コーポレートサイト　https://www.nttdata-ccs.co.jp/

nttdata-ccs　※ IAM のサインイン URL に使用する別名
https://nttdata-ccs.signin.aws.amazon.com/console

nttdata-ccs（CMS のサービスID と統一）

2環境を整備

• ステージング環境の追加・削除は本番サイトに影響しない
• ただし本番環境のリソースは削除しないこと。削除するとサイトが停止する
• 操作習得用・開発用の環境が必要な場合は都度調整する

1. リソース作成時に必ずタグを付与する。後付けにしない
2. 手動で作成した一時的なリソースには Temporary: true を付与し、用済み後に削除する
3. タグの追加・変更を行った場合は Appendix A-1 に反映する

IaC を採用しない構成では、設定のドリフト（実際の設定と設計書の乖離）が発生しやすい。タグとパラメータ一覧の更新徹底が運用品質を左右する。

• AWS の権限管理は IAM（Identity and Access Management）で行う
• 権限はロール単位で設計し、必要最小限のアクションのみを許可する
• 設定できるロール数に上限はない

1. 最小権限の原則　各ロールには、実行に必要なアクションのみを許可する
2. 長期認証情報を発行しない　CI/CD は OIDC による一時認証を使用する
3. ルートユーザーは通常運用で使用しない　MFA を必須とし、初期設定後は使用を封印する
4. 人が使う権限と、機械が使う権限を分離する　運用者アカウントと CI/CD ロールは別に管理する

GitHub OIDC Provider + IAM Role（AssumeRoleWithWebIdentity）を使用する

1. GitHub 上にアクセスキーを保管しない　キー漏洩のリスクを構造的に排除できる
2. 一時認証情報のみを使用する　セッション時間は1時間。期限切れ後は自動的に無効になる
3. リポジトリとブランチを限定できる　想定外のブランチからのデプロイを防止できる

信頼ポリシーでブランチを限定しない場合、任意のブランチから本番デプロイが可能になる。ブランチ限定は必須の設定とする。

バケットの作成・削除　／　バケットポリシーの変更　／　CloudFront の設定変更　／　他リソースへのアクセス全般

s3:ListBucket は必須である。付与しない場合、オブジェクト不在時に 403 が返り、オリジンフェイルオーバーが誤動作する（詳細は「フェイルオーバー時の注意事項」）。

1. NTTデータCCS 様側の担当者へ IAM ユーザーを発行するか
2. 発行する場合、閲覧のみか操作も許可するか
3. 発行対象の人数・氏名

• ルートユーザーは初期設定後、通常運用では使用しない
• 退任・異動時は速やかにアカウントを削除する
• アクセスキーの発行は原則行わない

AWS の操作は日常運用では発生しない。コンテンツ更新は microCMS のみで完結するため、NTTデータCCS 様が AWS を操作する機会は通常ない。

IP 制限はかけない。

CMS設計書と同様、閲覧者向けの公開サイトであるため IP 制限は行わない。ステージング環境のみ Basic 認証で保護する（「プレビュー・下書き」）。

いきなり Block モードで導入すると、正規のアクセスを遮断して公開直後に障害となる。Count モードで実際のトラフィックを観測してから適用する。

除外設定は誤検知が実際に確認された場合のみ行う。予防的な除外は行わない。除外した項目と理由は必ず記録する。

Origin Access Control（OAC）により、CloudFront からのみ S3 へアクセスさせる

この機能を使う場合、バケットを公開する必要がある。その結果、CloudFront と WAF を迂回して S3 へ直接アクセスできる経路が生まれる。

CSP は許可する外部ドメインを列挙する必要がある。外部フォーム SaaS ／ アクセス解析タグ ／ microCMS の画像配信ドメインの確定後に設定する。

記録内容: 誰が（IAM ユーザー・ロール）／ いつ ／ どこから（送信元 IP）／ 何を（実行した API・対象リソース）

用途: 設定変更時の変更証跡 ／ 意図しない変更の原因調査 ／ 保守契約終了時の引き継ぎ資料

サーバー側の処理は一切発生しない。完成済みの HTML ファイルを返すだけである。

1. アクセスが集中しても処理が重くならない
2. 実行環境がないため脆弱性対応が発生しない
3. ビルドが失敗してもサイトは停止しない（前回の内容が配信され続ける）

PriceClass_All（全世界）は南米・アフリカ・オセアニアを含むが、コーポレートサイトの閲覧者は国内が中心であるため不要と判断した。

Next.js の Static Export は /about/ に対して /about/index.html を出力する。一方 CloudFront の Default Root Object はルート直下にしか適用されない。

このため書き換えを行わない場合、下層ページはすべてエラーとなる。

CloudFront Functions（Viewer Request イベント）で URI を書き換える

実装コードは Appendix A-2 を参照。Lambda@Edge より高速かつ約 1/6 の費用で実現できる。

デプロイ時にキャッシュ無効化を実行するため、通常は即座に反映される。TTL 5分は、無効化が失敗した場合でも最大5分で最新化される安全弁として設定している。

静的配信ではオリジン負荷が問題にならないため、短めの設定を優先する。

DNS を変更せずにリージョン障害へ対応できる。親会社への作業依頼が発生しないため、現行環境の課題（01章「現状の課題」）が解決される。大阪リージョンは東京との距離が最も近く、切替時のレイテンシ影響が最小となる。

OAC + 非公開バケット構成では、存在しないファイルへのアクセスに 403 が返る。s3:GetObject のみ許可の場合、オブジェクト不在と権限不足を区別できないためである。

このまま 403 をフェイルオーバー条件に含めると、通常の 404 ページ表示のたびにセカンダリオリジンへ無駄な問い合わせが発生する。

CI/CD による同時デプロイ方式を採用する

ACM の検証用 CNAME レコードを削除すると、証明書が自動更新されず、最長1年後にサイトが閲覧不能になる。

デプロイ中のサイト停止はなし（ファイル差し替えのみ）／ 削除ファイルは --delete で除去 ／ 同時実行は concurrency で最新のみ／ 片方の sync が失敗した場合はジョブを失敗させ通知する（両リージョンの内容差異を放置しない）

ステップ1〜4は NTTデータCCS 様／ ステップ5はシステムが自動実行（約5〜8分）

1. 公開操作から反映まで約5〜8分かかる　サイト全体を再生成するため。公開直後に見えなくても正常
2. 公開予約時刻には反映されない　予約時刻＋ビルド時間後に反映される。時間厳守の公開は余裕を持って設定する
3. 短時間の連続公開は最後の1回のみ反映　ビルドの多重実行を防ぐ制御のため。すべての変更は最終ビルドに含まれる
4. ビルドが失敗してもサイトは停止しない　更新前の内容が配信され続ける

ステージング環境が検索エンジンにインデックスされると、本番サイトとの重複コンテンツ扱いとなり SEO 上の不利益が生じる。Basic 認証だけでは認証前のレスポンスがクロールされる可能性が残るため、noindex ヘッダーとの併用を必須とする。

【要確認】microCMS 更新時にステージングもビルドするか。実施する場合、ビルド回数が倍になる。

エラー率の監視では DNS 障害を検知できない（リクエストがそもそも到達しないため）。リクエスト数の急減は、こうした「エラーすら記録されない障害」を検知できる唯一の指標である。

メール（SNS）→ 【要確認】弊社保守担当 ／ Slack（AWS Chatbot）→ 【要確認】導入する場合 ／ NTTデータCCS 様へは弊社が一次判断後に連絡する（「障害対応フロー」参照）

保管期間を延ばすほど費用が増える。90日は「障害調査に必要な期間」として設定している。

【要確認】対応時間帯: 平日 9:00〜18:00 を想定。時間外対応は別途協議。

「切り戻しを前提としない移行」を基本方針とする

静的サイトは再デプロイが5〜10分で完了するため、実際には DNS 切り戻しより前進復旧の方が速い。

1. ステージング環境で全ページの確認を完了させてから切替を行う
2. 切替は営業時間内・週の前半に実施し、前進復旧できる体制を確保する
3. 旧環境（さくら）は 切替後 1ヶ月は解約しない
4. 切替当日は弊社の対応要員を確保する
5. 親会社の緊急時対応可否を事前に確認し、可能であれば連絡経路を確立しておく

関数名: nttdata-ccs-prod-fn-rewrite　／　イベント: Viewer Request　／　適用先: Default（*）ビヘイビア

function handler(event) {
  var request = event.request;
  var uri = request.uri;

  // 末尾がスラッシュの場合は index.html を付与
  if (uri.endsWith('/')) {
    request.uri = uri + 'index.html';
  }
  // 拡張子を持たない場合は /index.html を付与
  else if (!uri.includes('.')) {
    request.uri = uri + '/index.html';
  }

  return request;
}

構築時に以下5パターンすべての表示確認を行うこと。 / → /index.html　｜　/about/ → /about/index.html　｜　/about → /about/index.html　｜ /news/2026/ → /news/2026/index.html　｜　/assets/logo.svg → 変更なし

関数名: nttdata-ccs-stg-fn-auth　／　イベント: Viewer Request　／　適用先: ステージング環境のみ

function handler(event) {
  var request = event.request;
  var headers = request.headers;
  var expected = 'Basic 【構築時に設定】';   // Base64 エンコード値

  if (!headers.authorization || headers.authorization.value !== expected) {
    return {
      statusCode: 401, statusDescription: 'Unauthorized',
      headers: { 'www-authenticate': { value: 'Basic realm="Staging"' } }
    };
  }
  // 認証通過後、A-2 の URL 書き換え処理を続けて実行する
  return request;
}

CloudFront Functions のコード内に認証情報が平文で保存される。本番相当の機密情報を扱う用途には使用しない。検索エンジンからの保護と関係者外の閲覧防止を目的とする。

併せて X-Robots-Tag: noindex, nofollow をレスポンスヘッダーポリシーで付与し、認証前のレスポンスがクロールされた場合にも対応する。

除外候補: CommonRuleSet の SizeRestrictions_BODY（大きなリクエスト時）／ NoUserAgent_HEADER（監視ツール・クローラー該当時）。 除外は誤検知が実際に確認された場合のみ行い、除外項目と理由を記録する。

ガイドライン: OWASP Top 10 → 05 セキュリティ設定　／　Core Web Vitals（Google）→ 06 配信設計

更新契機: 構成変更時・AWS 仕様変更時・年次レビュー時　／　更新責任: 弊社（保守契約期間中）　／　版管理: 表紙の版数・発行日を更新する