AWS WordPressインフラ基本設計書

改訂履歴

改訂日	バージョン	改訂内容	作成者/改訂者
YYYY/MM/DD	1.0	初版作成

目次

1. はじめに

1.1. 本書の目的
1.2. 対象システム
1.3. 対象読者
1.4. 前提条件・制約条件
1.5. 非機能要件概要

2. 全体構成

2.1. システム構成図

3. AWSアカウント・リージョン・AZ

3.1. AWSアカウント
3.2. リージョン
3.3. アベイラビリティゾーン(AZ)

4. ネットワーク設計

4.1. VPC
4.2. サブネット
4.3. ルートテーブル
4.4. インターネットゲートウェイ(IGW)
4.5. NATゲートウェイ
4.6. VPCエンドポイント
4.7. DNS
4.8. VPC Flow Logs

5. コンピューティング設計

5.1. EC2インスタンス (WordPress)
5.2. Auto Scaling Group
5.3. EC2インスタンス (踏み台)
5.4. AMI (Amazon Machine Image)

6. ストレージ設計

6.1. EBS (Elastic Block Store)
6.2. S3 (Simple Storage Service)

7. データベース設計

7.1. RDS (Relational Database Service)
7.2. パラメータグループ
7.3. オプショングループ

8. コンテンツ配信・負荷分散設計

8.1. ALB (Application Load Balancer)
8.2. CloudFront

9. セキュリティ設計

9.1. 設計方針
9.2. IAM (Identity and Access Management)
9.3. Security Group
9.4. ネットワークACL (NACL)
9.5. AWS WAF
9.6. AWS Shield
9.7. AWS KMS (Key Management Service)
9.8. AWS Secrets Manager
9.9. Amazon Inspector
9.10. Amazon GuardDuty
9.11. ウィルス/マルウェア対策
9.12. 操作証跡 (CloudTrail)

10. ログ設計

10.1. ログ収集方針
10.2. 収集対象ログ
10.3. ログ保管
10.4. ログ分析・クエリ

11. 監視設計

11.1. 監視方針
11.2. 監視ツール
11.3. 主要監視項目と閾値
11.4. 通知設計
11.5. 外形監視

12. バックアップ・リストア設計

12.1. バックアップ方針
12.2. バックアップ対象と方法
12.3. リストア手順概要
12.4. RPO/RTO
12.5. バックアップ/リストアテスト

13. 障害復旧(DR)設計

13.1. DR要件
13.2. DR方式
13.3. DR手順概要
13.4. DRテスト

14. 構成管理

14.1. AWS Config
14.2. AWS Systems Manager Inventory
14.3. 構成ドキュメントの自動化

15. デプロイ・プロビジョニング

15.1. インフラプロビジョニング (IaC)
15.2. アプリケーションデプロイ (CI/CD)
15.3. 環境管理

16. パッチ管理

16.1. OSパッチ (EC2)
16.2. RDSメンテナンス

17. 可用性設計

17.1. 目標稼働率
17.2. 冗長化構成
17.3. メンテナンス計画

18. 命名規則・タグ設計

18.1. 命名規則
18.2. タグ設計

19. コスト最適化

19.1. コスト見積もり
19.2. コスト削減策

20. 運用設計

20.1. 運用体制
20.2. 定常運用タスク
20.3. インシデント管理
20.4. 変更管理

1. はじめに

1.1. 本書の目的

本ドキュメントは、AWS上に構築する「WordPress WEBサーバーシステム」（以下、本システム）のインフラストラクチャに関する基本設計を定義することを目的とする。AWSのベストプラクティスに基づき、可用性、セキュリティ、運用性、コスト効率に配慮した設計を示す。

1.2. 対象システム

WordPressを用いたWebサイト（顧客向け情報発信サイトを想定）
構成要素: Webサーバー(Apache/Nginx), PHP, WordPress, データベース(MySQL/PostgreSQL)

1.3. 対象読者

インフラ構築担当者
アプリケーション開発担当者
運用担当者
プロジェクトマネージャー

1.4. 前提条件・制約条件

インフラ: AWSを利用する。
WordPress: 特定のバージョン (例: 6.x) を利用する。
データベース: Aurora PostgreSQLを利用する。（※PDFではMySQL例もあったが、ここではPostgreSQLを選択）
予算: XXX円以内 (初期費用), YYY円/月以内 (ランニングコスト) ※具体的な値はプロジェクトによる
納期: YYYY/MM/DDまでに構築完了。
連携システム: (もしあれば記載)
準拠基準: (もしあれば記載。例: 社内セキュリティ基準、ISMSなど)

1.5. 非機能要件概要

項目	要件概要	関連章
可用性	目標月間稼働率: 99.9% (Mediumレベル)。Single-AZ構成を基本とする。EC2 Auto Recovery設定。RPO: 24時間, RTO: 4時間	3, 12, 13, 17
性能	想定アクセス数: XXXX PV/日、ピーク時 YYY req/sec。レスポンスタイム目標: Z秒以内。	5, 6, 7, 8
拡張性	将来的なアクセス増に対応可能な構成とする (Auto Scaling)。	5
セキュリティ	AWSセキュリティベストプラクティスに準拠。WAF導入、脆弱性診断実施、KMSによる暗号化。	9, 16
運用性	監視・ログ収集の自動化。IaCによる構成管理。パッチ適用の半自動化。	10, 11, 14, 15, 16, 20
コスト効率	RI/SPの活用検討。不要リソースの定期的な見直し。	19

2. 全体構成

2.1. システム構成図

3. AWSアカウント・リージョン・AZ

3.1. AWSアカウント

アカウント名	アカウントID	目的
WordPress 本番環境	111111111111	本番環境リソース展開
WordPress 検証環境	222222222222	検証環境リソース展開
セキュリティコントロール	333333333333	GuardDutyマスター等
ログ集約	444444444444	ログ集約用S3バケット
管制塔	555555555555	CI/CD, 共通管理

本番環境と検証環境はアカウント分離する。
Organizationsを利用し、SCP(Service Control Policy)でガバナンスを効かせる。

3.2. リージョン

東京リージョン (ap-northeast-1) を使用する。
理由: 日本国内ユーザーへのレイテンシ、データ主権、利用可能なサービスの多さ。

3.3. アベイラビリティゾーン(AZ)

可用性要件 (99.9%) とコストを考慮し、Single-AZ (ap-northeast-1a) 構成を基本とする。
- 理由: Mediumレベルの可用性目標であり、Multi-AZ構成はコスト増となるため。AZ障害時は後述のDR手順で対応。
ただし、以下はMulti-AZを検討・採用する:
- NAT Gateway: Single-AZ構成の場合、NAT GatewayがSPOF(単一障害点)となるため、Multi-AZ構成 (各AZに配置) も検討する。（本設計ではコスト優先でSingle-AZとするがリスクとして認識）
- RDS: RDSはMulti-AZ配置が可能だが、本設計ではコストと目標RTO/RPOを考慮しSingle-AZ構成とする。リストアによる復旧で対応。※高可用性要件の場合はMulti-AZを推奨。
- ALB: 最低2つのAZを指定する必要があるが、実質的なインスタンスは1aに配置されるため、AZ障害時の完全な冗長性はない。

4. ネットワーク設計

4.1. VPC

項目	設定値	備考
環境	本番 / 検証	アカウントごとに作成
名前	`wp-prod-vpc` / `wp-stg-vpc`	命名規則に従う
CIDRブロック	`10.0.0.0/16` / `10.1.0.0/16`	RFC1918プライベートアドレス空間から選択
テナンシー	Default	共有ハードウェア
DNSホスト名解決	有効	VPC内での名前解決を可能にする
DNS解決	有効

4.2. サブネット

3層アーキテクチャ（Public, Private, Protected）に基づきサブネットを分割する。

本番環境 (例: ap-northeast-1a)

サブネット名	CIDRブロック	AZ	レイヤー	配置リソース例
`wp-prod-public-subnet01a`	`10.0.128.0/20`	ap-northeast-1a	Public	ALB, NAT Gateway
`wp-prod-private-subnet01a`	`10.0.0.0/20`	ap-northeast-1a	Private	EC2 (WordPress), RDS
`wp-prod-protected-subnet01a`	`10.0.48.0/20`	ap-northeast-1a	Protected	EC2 (踏み台)
`(ALB用に他のAZも形式的に作成)`	`10.0.144.0/20`	ap-northeast-1c	Public	ALBの要件のため (実質インスタンスは配置せず)
`(将来拡張用)`	`10.0.16.0/20`	ap-northeast-1a	Private	(予備)

検証環境: 本番環境と同様の構成とする（CIDRは10.1.x.x/y）。

4.3. ルートテーブル

ルートテーブル名	関連付けるサブネット	ルーティングルール
`wp-prod-public-rtb`	Public Subnets	`0.0.0.0/0` -> `igw-xxxxxxxx` (IGW)
`wp-prod-private-rtb`	Private Subnets	`0.0.0.0/0` -> `nat-xxxxxxxx` (NAT GW) `pl-xxxxxxxx` (S3 Endpoint)
`wp-prod-protected-rtb`	Protected Subnets	(デフォルト: VPC内通信のみ)

4.4. インターネットゲートウェイ(IGW)

VPCに1つアタッチし、Publicサブネットからのインターネットアクセスを可能にする。
名前: wp-prod-igw

4.5. NATゲートウェイ

Publicサブネット (1a) に1つ配置 し、Elastic IPを付与する。
Privateサブネットからのアウトバウンド通信（OSアップデート、外部API連携等）に使用する。
名前: wp-prod-nat-gw-1a
※コストと可用性のトレードオフ。AZ障害時は通信不可となるリスクあり。高可用性が必要な場合は各AZに配置し、ルートテーブルをAZごとに設定。

4.6. VPCエンドポイント

通信をAWSネットワーク内に閉じることでセキュリティとパフォーマンスを向上させる。

サービス	エンドポイントタイプ	関連付けるルートテーブル/サブネット	設定
S3	Gateway	`wp-prod-private-rtb`	プライベートサブネットからS3へのアクセスを許可
Systems Manager	Interface	Private Subnets	SSM AgentがSSMサービスと通信するため。関連SGでHTTPS(443)を許可。
CloudWatch Logs	Interface	Private Subnets	CloudWatch AgentがLogsサービスと通信するため。関連SGでHTTPS(443)を許可。
EC2 Messages	Interface	Private Subnets	SSM AgentがSSMサービスと通信するため。関連SGでHTTPS(443)を許可。
KMS	Interface	Private Subnets	KMSを利用した暗号化/復号のため。関連SGでHTTPS(443)を許可。
Secrets Manager	Interface	Private Subnets	アプリケーションがSecrets Managerから認証情報を取得するため。HTTPS(443)許可。
(ECR)	Interface	Private Subnets	(コンテナ利用時) ECRからのイメージプル用。HTTPS(443)許可。

4.7. DNS

パブリックDNS:
- Route 53 Public Hosted Zoneを使用し、Webサイトのドメイン (example.com) を管理する。
- CloudFrontディストリビューションに対してAliasレコードを設定する。
プライベートDNS:
- Route 53 Private Hosted ZoneをVPC (wp-prod-vpc) に関連付け、VPC内リソースの名前解決に使用する (internal.example.com など)。
- RDSエンドポイントや内部ALBなど、IPアドレスが変動するリソースの名前解決に利用。
VPC DNS設定: VPCの「DNSホスト名」「DNS解決」を有効にする。

4.8. VPC Flow Logs

設定:
- 対象: VPC全体
- 送信先: CloudWatch Logs (/aws/vpcflowlogs/wp-prod-vpc) および S3 (wp-prod-logs-ACCOUNTID/vpcflowlogs/)
- ログ形式: カスタム形式 (必要なフィールドを選択。例: version account-id interface-id srcaddr dstaddr srcport dstport protocol packets bytes start end action log-status vpc-id subnet-id instance-id tcp-flags type pktdstaddr)
- 集約間隔: 10分間隔
目的: アクセス傾向の把握、拒否された通信の監視、セキュリティインシデント調査。
ログ保管期間: CloudWatch Logs: 90日、S3: 1年 (ライフサイクルポリシーでGlacier Deep Archiveへ移行)

5. コンピューティング設計

5.1. EC2インスタンス (WordPress)

項目	設定値	備考・理由
インスタンスタイプ	`t3.medium` (vCPU: 2, Mem: 4GiB)	想定負荷とコストバランスから選択。初期値であり、負荷テスト後に見直し。
AMI	最新のAmazon Linux 2 (AL2)	長期サポート、AWSサービスとの親和性。
配置サブネット	`wp-prod-private-subnet01a`	Privateサブネットに配置し、ALB経由でのみアクセスを許可。
ストレージ	EBS (詳細は6.1参照)
Security Group	`wp-prod-web-sg` (詳細は9.3参照)
IAM Role	`wp-prod-web-role` (詳細は9.2参照)	SSM, CloudWatch Agent, S3, Secrets Manager等へのアクセス権限を付与。
ユーザーデータ	初期設定スクリプト（Apache/Nginx, PHP, CW Agent, SSM Agent等のインストール・設定）	起動時に自動で環境構築を行う。
停止保護	有効	誤操作による停止を防止。
詳細モニタリング	有効	1分間隔のメトリクス収集 (CloudWatchコスト増に注意)。

5.2. Auto Scaling Group

項目	設定値	備考・理由
名前	`wp-prod-web-asg`
起動テンプレート	上記EC2設定に基づく起動テンプレートを使用	構成の均一化。
サブネット	`wp-prod-private-subnet01a`
ロードバランサー	`wp-prod-alb` をアタッチ	ALBからのヘルスチェックを利用。
ヘルスチェックタイプ	ELB	ALBのヘルスチェック結果に基づいてインスタンスの状態を判断。
ヘルスチェック猶予期間	300秒	インスタンス起動後の初期化時間を考慮。
最小インスタンス数	1	常時稼働させる最低インスタンス数。
最大インスタンス数	3	スケールアウトの上限。想定負荷とコストから決定。
希望インスタンス数	1	通常時の稼働インスタンス数。
スケーリングポリシー	ターゲット追跡スケーリング
- メトリクス	`ASGAverageCPUUtilization`	CPU使用率を指標とする。
- ターゲット値	60 (%)	CPU使用率が60%を超えたらスケールアウト、下回ったらスケールインを検討。
- ウォームアップ時間	120秒	新規インスタンスがトラフィック処理可能になるまでの時間。
スケールイン保護	有効	意図しないスケールインによるサービス影響を防ぐ。
終了ポリシー	Default (最も古いインスタンスから終了)

5.3. EC2インスタンス (踏み台)

項目	設定値	備考・理由
インスタンスタイプ	`t3.nano` または `t3.micro`	低スペックで十分。コスト重視。
AMI	最新のAmazon Linux 2 (AL2)
配置サブネット	`wp-prod-protected-subnet01a`	限定的なアクセス元からのみSSH可能とする。
Security Group	`wp-prod-bastion-sg` (詳細は9.3参照)	特定IPからのSSH、およびPrivateサブネットへのSSH許可。
IAM Role	`wp-prod-bastion-role`	SSM Agent利用のための権限。
アクセス方法	SSM Session Manager	推奨。 SGでのSSHポート開放不要、IAMでアクセス制御、操作ログ記録可能。
	SSH (要キーペア管理)	Session Managerが使えない場合の代替。キーペアは厳重に管理。
停止	利用時間外は停止	コスト削減のため、運用時間外（夜間・休日など）は停止する運用を検討。

5.4. AMI (Amazon Machine Image)

ゴールデンAMI戦略:
1. ベースAMI (Amazon Linux 2) からEC2インスタンスを起動。
2. 必要なミドルウェア (Webサーバー, PHP, エージェント等) をインストール・設定。
3. 上記インスタンスからカスタムAMI（ゴールデンAMI）を作成。
4. Auto Scaling Groupの起動テンプレートでは、このゴールデンAMIを使用する。
AMI更新プロセス:
1. OSパッチ適用やミドルウェア更新が必要な場合、上記プロセスで新しいゴールデンAMIを作成。
2. 起動テンプレートを更新し、ASGのインスタンス更新機能 (Instance Refresh) を利用してローリングアップデートを実施。
AMI名: wp-prod-web-YYYYMMDD
保管: 定期的に古いAMIは削除する（例: 直近3世代を保持）。

6. ストレージ設計

6.1. EBS (Elastic Block Store)

EC2 (WordPress) 用

項目	設定値	備考・理由
ボリュームタイプ	`gp3`	推奨。汎用SSD。ベースライン性能とIOPS/スループットを個別に設定可能でコスト効率が良い。
サイズ	30 GiB (ルートボリューム)	OS、アプリケーション、ログ等。必要に応じて調整。
IOPS	3000 (gp3デフォルト)	必要に応じて増強。
スループット	125 MiB/s (gp3デフォルト)	必要に応じて増強。
暗号化	有効 (AWS Managed Key: aws/ebs)	保管データの暗号化。デフォルトで有効化を推奨。
スナップショット	AWS Backupで取得 (後述)	定期的なバックアップ。

EC2 (踏み台) 用

gp3, 8 GiB, 暗号化有効

6.2. S3 (Simple Storage Service)

命名規則: (プロジェクト名)-(環境)-(用途)-(AWSアカウントID) (例: wp-prod-media-111111111111) ※S3バケット名はグローバルで一意。

バケット用途	バケット名 (例)	アクセス制御	バージョニング	暗号化 (SSE-S3)	ライフサイクル	ログ記録
WordPressメディアファイル	`wp-prod-media-ACCOUNTID`	CloudFront OAI (Origin Access Identity) のみ許可。 EC2 IAM Role からのアクセス許可。	有効	有効	(必要に応じて低頻度アクセス層へ移行)	有効 (S3アクセスログ)
各種ログ保管	`wp-prod-logs-ACCOUNTID`	各サービス (ALB, CloudFront, CloudTrail, Config, Flow Logs) からの書き込み許可。特定IAM Role/Userからの読み取り許可。	有効	有効	90日後に Intelligent-Tiering、1年後に Glacier Deep Archiveへ移行。削除はしない。	有効 (S3アクセスログ)
構成ドキュメント保管	`wp-prod-configdocs-ACCOUNTID`	特定IAM Role/Userのみアクセス許可。	有効	有効		有効 (S3アクセスログ)
バックアップデータ	(AWS Backup Vault管理下)	AWS Backupからのアクセスのみ許可。	(Backup管理)	有効	(Backup Vaultのポリシーに従う)	(CloudTrailでAPI追跡)

S3アクセスログ: wp-prod-logs-ACCOUNTID バケット内の専用プレフィックス (/s3accesslogs/) に集約する。
ブロックパブリックアクセス: 全てのバケットで有効化する。

7. データベース設計

7.1. RDS (Relational Database Service)

項目	設定値	備考・理由
DBエンジン	Aurora PostgreSQL (WordPress互換バージョン)	高パフォーマンス、高可用性機能(Multi-AZは今回不使用)、スケーラビリティ。MySQLも選択肢だがここではPostgreSQLを選択。
クラスター名	`wp-prod-aurora-pg-cluster`
DBインスタンスクラス	`db.t3.medium` (Writer)	初期値。CPU/メモリ/コネクション数を考慮。負荷テスト後に見直し。Readerは今回は構成しない（必要に応じて追加）。
配置サブネットグループ	Private Subnets (`wp-prod-private-*`) を指定	Privateサブネット内に配置。
Multi-AZ配置	無効	コストと目標RTO/RPOを考慮。AZ障害時はリストアで対応。高可用性要件の場合は有効化。
DB名	`wordpress_db`
マスターユーザー名	(非 `admin`, `postgres` 等の推測容易な名前)
マスターパスワード	Secrets Managerで管理	強力なパスワードを自動生成し、ローテーションを設定。アプリケーションはSecrets Managerから取得。
ストレージタイプ	Aurora Storage	自動拡張。
ストレージ暗号化	有効 (AWS Managed Key: aws/rds)	保管データの暗号化。
自動バックアップ	有効	保持期間: 7日間。
バックアップウィンドウ	深夜帯 (例: 03:00-04:00 JST)	業務影響の少ない時間帯。
メンテナンスウィンドウ	日曜深夜 (例: 04:00-05:00 JST)	業務影響の少ない時間帯。
ログのエクスポート	CloudWatch Logsへエクスポート (後述)	PostgreSQLログ, 監査ログ。
Performance Insights	有効	DB負荷のボトルネック分析に利用。保持期間: 7日間 (無料枠)。
拡張モニタリング	有効 (粒度: 60秒)	OSレベルのメトリクスを収集。
Security Group	`wp-prod-db-sg` (詳細は9.3参照)
削除保護	有効	誤操作による削除を防止。

7.2. パラメータグループ

デフォルトからカスタムパラメータグループ (wp-prod-aurora-pg14-param-group) を作成し、以下などを調整。
log_statement = 'ddl' (DDL操作をログ記録)
log_min_duration_statement = 1000 (1秒以上のクエリをログ記録)
pgaudit.log = 'all' (pgauditによる監査ログを有効化)
shared_preload_libraries = 'pgaudit' (pgauditをロード)
その他、パフォーマンスチューニングに必要なパラメータ（work_mem, shared_buffers等）を必要に応じて調整。

7.3. オプショングループ

デフォルトを使用。特別な拡張機能は利用しない想定。

8. コンテンツ配信・負荷分散設計

8.1. ALB (Application Load Balancer)

項目	設定値	備考・理由
名前	`wp-prod-alb`
スキーム	Internet-facing	インターネットからのアクセスを受け付ける。
IPアドレスタイプ	IPv4
配置サブネット	Public Subnets (`wp-prod-public-*`) を2つ以上指定	高可用性の確保 (ただしインスタンスはSingle-AZ)。
Security Group	`wp-prod-alb-sg` (詳細は9.3参照)
リスナー	HTTPS: 443	HTTP通信はHTTPSへリダイレクト。
- プロトコル	HTTPS
- ポート	443
- SSL証明書	ACM (AWS Certificate Manager) で発行した証明書	無料で利用可能、自動更新。
- SSLポリシー	`ELBSecurityPolicy-TLS-1-2-Ext-2018-06`	推奨される最新のポリシー（互換性を考慮しつつセキュリティを確保）。
- デフォルトアクション	EC2ターゲットグループへ転送
リスナー	HTTP: 80 (リダイレクト用)
- プロトコル	HTTP
- ポート	80
- デフォルトアクション	HTTPS:443へリダイレクト	常時HTTPS化。
ターゲットグループ	`wp-prod-web-tg`
- ターゲットタイプ	Instance
- プロトコル	HTTP	ALB-EC2間はHTTP通信（暗号化が必要な場合はHTTPSに変更）。
- ポート	80
- ヘルスチェック	HTTP / パス: `/wp-includes/images/blank.gif` (または専用ヘルスチェックパス) / 正常コード: 200	WordPressが応答可能な軽量なパスを指定。
- ターゲット	Auto Scaling Groupによって自動登録/解除
属性	アイドルタイムアウト: 60秒	デフォルト値。必要に応じて調整。
	アクセスログ: 有効	S3 (`wp-prod-logs-ACCOUNTID/alblogs/`) へ出力。
	HTTP/2: 有効	パフォーマンス向上。
WAF連携	無し (CloudFront側で連携)

8.2. CloudFront

項目	設定値	備考・理由
オリジン	`wp-prod-alb` (ALBのDNS名)
- プロトコルポリシー	HTTPS Only	CloudFront-ALB間もHTTPS通信。
デフォルトキャッシュビヘイビア
- ビューワープロトコルポリシー	Redirect HTTP to HTTPS	常時HTTPS化。
- 許可HTTPメソッド	GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE	WordPressの管理画面操作なども考慮。
- キャッシュキーとオリジンリクエスト	`CachingOptimized` ポリシー (静的コンテンツ用)	デフォルト。動的コンテンツは別途ビヘイビア設定。
- TTL設定	オリジンキャッシュヘッダーに従う / デフォルトTTL: 86400秒 (1日)	WordPressが出力するキャッシュヘッダーを尊重。静的ファイルは長めにキャッシュ。
- 圧縮	有効 (Gzip, Brotli)	転送量削減。
追加キャッシュビヘイビア (例)
- パスパターン	`/wp-admin/*`, `/wp-login.php`	管理画面やログインページはキャッシュしない。
- キャッシュポリシー	`CachingDisabled`	キャッシュ無効化。
- オリジンリクエストポリシー	`AllViewer`	必要なヘッダー、クッキー、クエリ文字列を全てオリジンに転送。
- パスパターン	`/wp-content/uploads/*` (静的ファイル)	メディアファイル等。
- キャッシュポリシー	`CachingOptimized` (または TTLを長く設定したカスタムポリシー)	長期間キャッシュさせる。
ディストリビューション設定
- 代替ドメイン名(CNAME)	`www.example.com`, `example.com`	Webサイトのドメイン。
- SSL証明書	ACMで発行した証明書 (`example.com`)
- セキュリティポリシー	`TLSv1.2_2021`	推奨される最新ポリシー。
- 対応HTTPバージョン	HTTP/2, HTTP/3	パフォーマンス向上。
- ログ記録	有効 (S3: `wp-prod-logs-ACCOUNTID/cflogs/`, Cookieログ記録無効)	アクセスログを保管。Cookieログはプライバシーに配慮し無効。
- IPv6	有効
- WAF連携	`wp-prod-waf-webacl` をアタッチ	WAFによる保護。
- 地域制限	(必要に応じて設定。例: 日本国内のみ許可)
- オリジンアクセスアイデンティティ(OAI)	利用 (S3メディアバケット用)	S3バケットへの直接アクセスを禁止し、CloudFront経由のみ許可する場合。

9. セキュリティ設計

9.1. 設計方針

最小権限の原則: IAMポリシー、Security Group、NACL等で必要最小限の権限・通信のみを許可する。
多層防御: ネットワーク境界 (WAF, SG, NACL)、ホスト (OS設定, ウィルス対策)、アプリケーション、データ (暗号化) の各層で対策を実施する。
証跡管理: CloudTrail, Config, 各種ログにより、操作やイベントの記録・追跡を可能にする。
自動化: セキュリティチェック (Inspector, GuardDuty, Config Rules) や通知を自動化する。
暗号化: 保管データ (EBS, S3, RDS)、通信経路 (TLS/SSL) を暗号化する。

9.2. IAM (Identity and Access Management)

ユーザー:
- AWS操作を行う担当者ごとにIAMユーザーを作成する。共有ユーザーは禁止。
- ルートアカウントは使用しない。MFAを設定し、アクセスキーは作成しない。
- 全てのIAMユーザーにMFAを設定する。
- パスワードポリシーを設定する (PDF記載内容準拠)。
グループ:
- 職責に基づきIAMグループを作成し、ユーザーを所属させる。権限はグループに付与する。
- 例: Administrators, InfraAdmins, SecurityAdmins, AppDevelopers, Operators, WordPressAdmins (PDF記載内容準拠)
ポリシー:
- AWS管理ポリシーを参考にしつつ、職責に必要な最小限の権限を持つカスタムポリシーを作成・アタッチする。
- 定期的に権限を見直し、不要な権限を削除する (Access Advisor活用)。
ロール:
- EC2インスタンスやLambda等のAWSサービスにはIAMロールをアタッチし、アクセスキーを使用しない。
  - wp-prod-web-role: SSM, CloudWatch Agent, S3(メディア, ログ), Secrets Managerへのアクセス権限。
  - wp-prod-bastion-role: SSM Agent利用権限。
- クロスアカウントアクセスやフェデレーションにもロールを利用する。
アクセスキー:
- 原則として作成しない。プログラムによるアクセスが必要な場合はIAMロールまたは一時クレデンシャルを使用する。
- やむを得ず作成する場合は、厳重に管理し、定期的にローテーションする。

9.3. Security Group

ステートフルファイアウォール。許可する通信のみを定義。デフォルトDeny。
命名規則: (プロジェクト名)-(環境)-(役割)-sg
主なSecurity Groupとルール (抜粋):

SG名	関連リソース	Inbound ルール (Source -> Port)	Outbound ルール (Dest -> Port)
`wp-prod-alb-sg`	ALB	`0.0.0.0/0`, `::/0` -> `80` (HTTP) `0.0.0.0/0`, `::/0` -> `443` (HTTPS)	`wp-prod-web-sg` -> `80`
`wp-prod-web-sg`	EC2 (WordPress)	`wp-prod-alb-sg` -> `80` `wp-prod-bastion-sg` -> `22` (SSH, SSM経由の場合は不要) (Interface Endpoint SG) -> `443` (各種Endpoint)	`0.0.0.0/0` -> `443` (HTTPS, Endpoint) `wp-prod-db-sg` -> `5432` (PostgreSQL)
`wp-prod-db-sg`	RDS	`wp-prod-web-sg` -> `5432` (PostgreSQL)	(デフォルト: ALL)
`wp-prod-bastion-sg`	EC2 (踏み台)	(運用拠点IP) -> `22` (SSH, SSM経由の場合は不要) (Interface Endpoint SG) -> `443` (SSM Endpoint)	`wp-prod-web-sg` -> `22` `0.0.0.0/0` -> `443` (HTTPS, Endpoint)
(Endpoint用SG)	Interface Endpoints	(各リソースSG) -> `443`	(デフォルト: ALL)

9.4. ネットワークACL (NACL)

ステートレスファイアウォール。サブネット単位で適用。デフォルトAllow。
基本的にはSecurity Groupで制御し、NACLはデフォルト (Inbound/OutboundともALL Allow) のまま運用。
明示的に拒否したい通信（特定の不正IPアドレスからのアクセス等）がある場合にルールを追加検討。
ルール番号: 小さい番号から評価される。許可/拒否ルールは100番単位で設定し、緊急対応用に間を開けておく。

9.5. AWS WAF

適用対象: CloudFrontディストリビューション
WebACL名: wp-prod-waf-webacl
ルール:
- AWS Managed Rules:
  - AWSManagedRulesCommonRuleSet: 一般的な脅威 (SQLi, XSS等) をブロック。
  - AWSManagedRulesAmazonIpReputationList: 悪意のあるIPアドレスリストからのアクセスをブロック。
  - AWSManagedRulesKnownBadInputsRuleSet: 不正な入力パターンをブロック。
  - AWSManagedRulesLinuxRuleSet: Linux特有の攻撃をブロック。
  - (WordPress利用の場合) AWSManagedRulesWordPressRuleSet: WordPress特有の脆弱性を狙った攻撃をブロック。
- カスタムルール:
  - レートベースルール: 過剰なリクエストを行うIPアドレスをブロック (例: 5分間に2000リクエスト以上)。
  - 地理的制限ルール: (必要に応じて) 特定国以外からのアクセスをブロック。
デフォルトアクション: Allow (ルールに一致しない通信は許可)
ログ: Kinesis Data Firehose経由でS3 (wp-prod-logs-ACCOUNTID/waflogs/) に出力。Athenaで分析可能。
初期導入: まずはCountモードで導入し、誤検知を確認・調整してからBlockモードに移行する。

9.6. AWS Shield

Shield Standard: 全てのAWS顧客に自動適用され、追加料金なし。一般的なネットワーク/トランスポート層のDDoS攻撃からの保護。
Shield Advanced: (オプション) より高度なDDoS攻撃からの保護、コスト保護、DDoS対応チーム(DRT)のサポートが必要な場合に契約を検討。本設計ではStandardを前提とする。

9.7. AWS KMS (Key Management Service)

EBS, S3, RDS等の保管データ暗号化に使用する暗号化キーを管理する。
キータイプ:
- AWS Managed Key (例: aws/ebs, aws/s3, aws/rds): デフォルトで利用。管理が容易。
- Customer Managed Key (CMK): より詳細なアクセス制御やローテーション管理が必要な場合に作成・利用を検討。本設計ではAWS Managed Keyを主に使用。
アクセス制御: IAMポリシーでキーへのアクセス権限 (暗号化/復号等) を制御する。

9.8. AWS Secrets Manager

RDSマスターパスワード、APIキーなどのシークレット情報を安全に保管・管理・ローテーションする。
シークレット:
- wp-prod/rds/master-credentials: RDSマスターユーザー名とパスワード。自動ローテーションを設定。
- (その他必要なAPIキーなど)
アクセス: EC2 (WordPress) のIAMロールに必要なシークレットへの読み取り権限を付与。アプリケーションはSDK経由で取得。

9.9. Amazon Inspector

対象: EC2インスタンス (WordPress, 踏み台)
スキャンタイプ: ネットワーク到達可能性スキャン、ホスト評価 (OSパッケージ脆弱性、CISベンチマーク)
実行: 定期的 (例: 週次) またはイベントベース (デプロイ時など) でスキャンを実行。
結果: Security Hubへ集約し、検出された脆弱性は深刻度に応じて対応計画を立てる (パッチ適用等)。

9.10. Amazon GuardDuty

有効化: 全てのリージョンで有効化する。
マスターアカウント: セキュリティアカウント (333333333333) をマスターとし、他のアカウントをメンバーとして招待・管理する。
データソース: CloudTrailログ, VPC Flow Logs, DNSログを分析。S3保護機能も有効化。
検出結果 (Findings):
- Security Hubへ集約する。
- 重大度 (High/Medium) の検出結果はCloudWatch Events経由でSNSトピックに連携し、運用担当者へ通知する。
- 検出結果に基づき、インシデント対応プロセスに従って調査・対応を行う。

9.11. ウィルス/マルウェア対策

EC2インスタンス:
- サードパーティ製対策ソフト導入: (例: Trend Micro Cloud One - Workload Security, CrowdStrike Falcon等) ※別途ライセンス費用が必要。
- 機能: 不正プログラム対策、Webレピュテーション、侵入防御、変更監視、セキュリティログ監視を有効化。
- 運用: パターンファイル/エンジンは常に最新化。検出時は管理コンソールで確認し対応。初期は検出モードでチューニング。
- 代替案 (コスト重視): Amazon Linux 2標準のセキュリティ機能、定期的なInspectorスキャン、GuardDutyによる検知に依存する。ただし、リアルタイム検知能力は劣る。
S3バケット: GuardDuty S3 Protectionを有効化し、不審なアクティビティを検知。

9.12. 操作証跡 (CloudTrail)

有効化: 全てのリージョンで有効化する。
証跡:
- 管理イベント: 全て記録。
- データイベント: S3 (全バケット), Lambda (必要に応じて) のデータイベントを記録。※コストとログ量に注意。
保管場所: S3 (wp-prod-logs-ACCOUNTID/cloudtrail/) および CloudWatch Logs (/aws/cloudtrail/wp-prod-trail)。
ログファイルの整合性検証: 有効化。改ざん検知。
暗号化: SSE-S3で暗号化。
保管期間: S3: 永年 (ライフサイクルポリシーで低コスト層へ移行), CloudWatch Logs: 90日。
活用: セキュリティインシデント調査、不正操作の特定、コンプライアンス監査。CloudWatch Logs InsightsやAthenaで分析。

10. ログ設計

10.1. ログ収集方針

システム運用、セキュリティ監査、障害調査に必要なログを網羅的に収集・保管する。
可能な限りCloudWatch LogsおよびS3に集約し、一元的な管理・分析を可能にする。

10.2. 収集対象ログ

ログ種類	収集元	収集方法/保管先 (CloudWatch Logs / S3)
OSログ (EC2)		CloudWatch Agent -> CW Logs (`/var/log/messages`, `/var/log/secure`等)
- システムログ	`/var/log/messages`	CW Logs Group: `/ec2/wp-prod/system`
- セキュリティログ	`/var/log/secure`	CW Logs Group: `/ec2/wp-prod/secure`
Webサーバーログ (EC2)		CloudWatch Agent -> CW Logs
- Apache/Nginxアクセス	`/var/log/httpd/access_log` or `/var/log/nginx/access.log`	CW Logs Group: `/ec2/wp-prod/web/access`
- Apache/Nginxエラー	`/var/log/httpd/error_log` or `/var/log/nginx/error.log`	CW Logs Group: `/ec2/wp-prod/web/error`
PHP-FPMログ (EC2)	`/var/log/php-fpm/error.log` (例)	CloudWatch Agent -> CW Logs (`/ec2/wp-prod/php/error`)
WordPressデバッグログ	`wp-content/debug.log` (WP_DEBUG有効時)	CloudWatch Agent -> CW Logs (`/ec2/wp-prod/wordpress/debug`) (本番では通常無効)
ALBアクセスログ	ALB	S3 (`wp-prod-logs-ACCOUNTID/alblogs/`)
CloudFrontアクセスログ	CloudFront	S3 (`wp-prod-logs-ACCOUNTID/cflogs/`)
WAFログ	WAF	Kinesis Data Firehose -> S3 (`wp-prod-logs-ACCOUNTID/waflogs/`)
VPC Flow Logs	VPC	CW Logs (`/aws/vpcflowlogs/wp-prod-vpc`), S3 (`wp-prod-logs-ACCOUNTID/vpcflowlogs/`)
RDSログ (PostgreSQL)	RDS	RDSコンソール設定 -> CW Logs (`/aws/rds/cluster/wp-prod-aurora-pg-cluster/postgresql`, `/audit`等)
S3アクセスログ	S3	S3 (`wp-prod-logs-ACCOUNTID/s3accesslogs/`)
CloudTrailログ	CloudTrail	CW Logs (`/aws/cloudtrail/wp-prod-trail`), S3 (`wp-prod-logs-ACCOUNTID/cloudtrail/`)
Configログ	AWS Config	S3 (`wp-prod-logs-ACCOUNTID/configlogs/`)
SSM Session Managerログ	SSM	CW Logs (`/aws/ssm/session-manager`), S3 (`wp-prod-logs-ACCOUNTID/ssm-session-logs/`) (設定による)

10.3. ログ保管

CloudWatch Logs:
- 保持期間: 90日間 (短期分析、アラート用)
- 暗号化: 有効 (AWS Managed Key: aws/logs)
S3:
- 保持期間: 1年間（ログ種類によっては永年保管）。ライフサイクルポリシーで低コストストレージ (Glacier Deep Archive) へ移行。
- 保管先バケット: wp-prod-logs-ACCOUNTID (ログ集約アカウントのバケットも検討)
- 暗号化: SSE-S3
- バージョニング: 有効

10.4. ログ分析・クエリ

CloudWatch Logs Insights: 短期的な調査、ダッシュボードでの可視化。
Amazon Athena: S3に保管されたログ (ALB, CloudFront, WAF, VPC Flow Logs, S3 Access Logs, CloudTrail等) に対するアドホックなクエリ実行、長期的な傾向分析。Glueデータカタログでテーブル定義を行う。

11. 監視設計

11.1. 監視方針

システムの正常性、パフォーマンス、セキュリティに関するメトリクスとログを継続的に監視し、異常を早期に検知する。
自動化されたアラートにより、迅速なインシデント対応を可能にする。
パフォーマンスベースラインを取得し、将来的なキャパシティプランニングに活用する。

11.2. 監視ツール

Amazon CloudWatch: Metrics, Alarms, Logs, Dashboards, Synthetics (外形監視)
AWS Personal Health Dashboard: AWS全体のイベント、アカウント固有のイベント監視。
AWS Trusted Advisor: ベストプラクティスチェック (コスト最適化、セキュリティ、耐障害性、パフォーマンス)。
RDS Performance Insights: DBパフォーマンスの詳細分析。
サードパーティ監視ツール: (オプション) Datadog, New Relicなど、より高度なAPMや統合監視が必要な場合に検討。

11.3. 主要監視項目と閾値

(CloudWatch Alarmsで設定)

対象リソース	メトリクス/ログ	閾値・条件	通知レベル	イベント分類 (PDF参考)
EC2 (WordPress)	`CPUUtilization`	>= 80% (5分間連続)	Warning
	`StatusCheckFailed_Instance`	1 (2分間連続 x 2回)	Critical	AR
	`StatusCheckFailed_System`	1 (2分間連続 x 2回)	Critical	AR
	`DiskSpaceUtilization` (Root Volume, gp3使用時)	>= 85% (CloudWatch Agentカスタムメトリクス)	Critical	AR
	`MemoryUtilization`	>= 80% (CloudWatch Agentカスタムメトリクス)	Warning	AR
	`procstat_lookup_pid_count` (Webサーバープロセス)	= 0 (3分間連続 x 1回) (CloudWatch Agent)	Critical	AR
	`procstat_lookup_pid_count` (PHP-FPMプロセス)	= 0 (3分間連続 x 1回) (CloudWatch Agent)	Critical	AR
ALB	`HTTPCode_Target_5XX_Count`	>= 10 (5分間のSum)	Warning
	`UnHealthyHostCount`	>= 1 (5分間連続)	Critical	AR
	`RejectedConnectionCount`	>= 1 (5分間のSum)	Warning	AR
RDS	`CPUUtilization`	>= 80% (15分間連続)	Warning
	`DatabaseConnections`	>= (インスタンスクラス上限の85%) (10分間連続)	Warning	AR
	`FreeableMemory`	<= (インスタンスメモリの10%) (15分間連続)	Warning
	`DiskQueueDepth`	>= 10 (5分間連続)	Warning
	`FreeStorageSpace`	<= 10GB (例)	Critical	AR
CloudFront	`5xxErrorRate`	>= 1% (5分間のAverage)	Warning
	`4xxErrorRate`	>= 5% (5分間のAverage)	Notice
ログ監視	WordPress エラーログ (`/ec2/wp-prod/wordpress/error`等)	"FATAL", "PHP Fatal error" (含む場合)	Critical	AR
	Webサーバーエラーログ (`/ec2/wp-prod/web/error`)	"error", "crit" (含む場合)	Warning
	セキュリティログ (`/ec2/wp-prod/secure`)	"Failed password", "Invalid user" (含む場合)	Warning
セキュリティ関連	(GuardDuty Findings - High/Medium)	(GuardDutyが検知)	Critical	AR (イベントによる)
	(Config Rules - Noncompliant)	(Configが検知)	Warning	AR (ルールによる)
	(CloudTrail特定API呼び出し - 例: SG変更)	(CloudWatch Eventsで検知)	Critical	AR
	(CloudTrailログイン失敗)	(CloudWatch Eventsで検知)	Warning	AR
AWS Health	(アカウントに影響するイベント)	(PHDイベント)	Notice/AR	Notice/AR
Billing	`EstimatedCharges`	>= (予算額の80%)	Warning

11.4. 通知設計

通知経路: CloudWatch Alarm -> SNSトピック -> Email / ChatOps (Slack等) / PagerDuty (障害レベルに応じて)
SNSトピック:
- wp-prod-critical-alerts: 重大な障害通知用 (PagerDuty連携等)
- wp-prod-warning-alerts: 警告レベルの通知用 (Email, ChatOps)
- wp-prod-notice-alerts: 情報レベルの通知用 (Email, ChatOps)
件名: PDF記載の通り、Notice- や AR- を付与し、リソース名、アラート内容がわかるようにする。例: AR- [wp-prod] EC2 Instance StatusCheckFailed - i-xxxxxxxxxxxxxxxxx
通知内容: アラート発生日時、対象リソース、メトリクス名、閾値、現在の値、CloudWatch Alarmへのリンクなど、対応に必要な情報を含める。

11.5. 外形監視

ツール: CloudWatch Synthetics Canary
監視内容:
- Webサイトのトップページ (https://www.example.com/) への定期的なアクセス (例: 5分間隔)。
- HTTPステータスコード (200 OK)、特定の文字列の存在確認、レスポンスタイムをチェック。
- ログイン画面や主要な機能ページの疎通確認も検討。
目的: ユーザー視点でのサービス正常性を確認。CloudFront, ALB, EC2, WordPress全体の疎通確認。
アラート: Canaryが失敗した場合、Criticalレベルで通知 (wp-prod-critical-alerts SNSトピックへ)。

12. バックアップ・リストア設計

12.1. バックアップ方針

主要なデータ（DB、EC2、メディアファイル）を定期的にバックアップし、障害発生時に復旧可能な状態を維持する。
AWS Backupを利用し、バックアップ計画を一元管理・自動化する。
バックアップデータは暗号化し、安全に保管する。

12.2. バックアップ対象と方法

AWS Backupによる統合管理:
- Backup Vault: wp-prod-backup-vault を作成。KMS (CMK推奨) で暗号化。アクセスはIAMポリシーで制御。
- Backup Plan: wp-prod-daily-backup-plan を作成。
  - バックアップルール:
    - 頻度: 毎日
    - バックアップウィンドウ: 深夜帯 (例: 02:00 - 05:00 JST)
    - ライフサイクル:
      - コールドストレージへの移行: 30日後 (コスト削減)
      - 保持期間: 90日間
    - コピー: (オプション) DR要件に基づき、別リージョン (ap-southeast-1等) または別アカウント (ログ集約アカウント等) のVaultへコピー。
  - リソース割り当て: 以下のタグが付与されたリソースを対象とする。
    - Tag Key: Backup
    - Tag Value: Daily
バックアップ対象リソースとタグ付け:

リソース	バックアップ方法 (AWS Backup)	付与するタグ (`Backup=Daily`)	備考
EC2 (WordPress)	AMI & EBS スナップショット	✓	インスタンス全体をバックアップ。
EBS (WordPress Root)	(EC2バックアップに含まれる)
RDS (Aurora Cluster)	RDS スナップショット	✓	自動バックアップとは別に、AWS Backupで管理。Point-in-TimeリカバリはRDS自動バックアップを利用。
S3 (メディア)	S3 バックアップ	✓	S3バージョニングと併用。Point-in-Timeリカバリも可能。大量データの場合はコストと時間に注意。クロスリージョンレプリケーションも検討。

構成情報:
- TerraformコードはGit (GitHub/CodeCommit) でバージョン管理する。
- CloudFormationテンプレートや手動設定情報は、定期的にエクスポート or ドキュメント自動化ツールでS3へ保管。
- Secrets Managerのシークレットは、必要に応じて内容を安全な場所に記録しておく（ただし推奨されない）。

12.3. リストア手順概要

シナリオ例1: EC2インスタンス障害
1. AWS Backupコンソールから、直近の正常なEC2バックアップ(AMI/Snapshot)を選択。
2. リストアジョブを開始し、新しいEC2インスタンスを指定したサブネットに復元。
3. 必要に応じてElastic IPの付け替えや、ALBターゲットグループへの再登録を行う。
4. 動作確認。
シナリオ例2: RDSクラスター障害 or データ破損
1. (データ破損の場合) AWS Backupコンソール or RDSコンソールから、Point-in-Timeリカバリを実行し、指定した時刻の新しいRDSクラスターを復元。
2. (クラスター障害の場合) AWS Backupコンソール or RDSコンソールから、最新のスナップショットを選択し、新しいRDSクラスターを復元。
3. アプリケーション(WordPress)の接続先DBエンドポイントを新しいクラスターに変更 (Secrets Manager更新 or 設定ファイル変更&デプロイ)。
4. 動作確認。
シナリオ例3: S3メディアファイル消失
1. (バージョニング有効時) S3コンソールから削除マーカーを削除するか、以前のバージョンを復元。
2. (AWS Backup利用時) AWS Backupコンソールから必要なファイル/フォルダを選択し、リストアジョブを実行。
3. 動作確認。
詳細なリストア手順書を別途作成し、定期的にテスト・更新する。

12.4. RPO/RTO

RPO (目標復旧時点): 24時間
- 根拠: 1日1回のバックアップ取得間隔。
RTO (目標復旧時間): 4時間
- 根拠: 上記リストア手順の想定所要時間。DBのサイズやリストア内容によって変動。テストにより実測値を把握する。

12.5. バックアップ/リストアテスト

頻度: 半年に1回実施。
内容:
- 主要な障害シナリオ（EC2、RDS、S3）に基づき、実際にリストア手順を実行する。
- リストアした環境でWordPressの基本動作（ページ表示、ログイン、投稿等）を確認する。
- リストアにかかった時間を計測し、RTO目標を達成できるか確認する。
- 手順書の問題点や改善点を洗い出し、更新する。
テスト環境: 検証環境で実施するか、本番VPC内に一時的なリストア用サブネットを作成して実施する。

13. 障害復旧(DR)設計

13.1. DR要件

東京リージョン (ap-northeast-1) 全体が利用不可となる大規模災害を想定。
目標: 別リージョンでシステムを復旧し、サービスを再開する。
DR用RPO: 24時間 (バックアップコピー間隔に依存)
DR用RTO: 24時間 (手動復旧を想定)

13.2. DR方式

バックアップ & リストア方式 (コールドスタンバイ)
- 理由: 目標RTOが比較的長く、コストを抑えるため。
- 平常時: AWS Backupのクロスリージョンコピー機能を利用し、バックアップデータ (AMI, RDS Snapshot, S3) をDR用リージョン (例: 大阪 ap-northeast-3 またはシンガポール ap-southeast-1) のBackup Vaultにコピーしておく。
- 災害発生時: DRリージョンにネットワーク、EC2、RDS等をバックアップからリストアし、Route 53のDNSレコードを切り替える。

13.3. DR手順概要

災害検知・DR発動判断: 東京リージョンの広範囲な障害を確認し、経営層/責任者がDR発動を判断。
DRリージョンでのインフラ復旧:
- DRリージョンにVPC、サブネット等をTerraform/CloudFormation等で構築 (DR用コードを事前準備)。
- AWS Backupコンソール (DRリージョン) から、コピーされたバックアップを選択し、EC2, RDSをリストア。
- S3バケットを作成し、バックアップからメディアファイルをリストア (S3クロスリージョンレプリケーション設定時は不要な場合あり)。
設定変更:
- WordPress設定ファイル (wp-config.php) 内のDB接続情報等をDRリージョンのRDSエンドポイントに変更。
- Secrets ManagerのシークレットをDRリージョンで再作成or更新。
DNS切り替え: Route 53で、WebサイトドメインのAliasレコードまたはCNAMEレコードを、DRリージョンのCloudFront/ALBエンドポイントに向ける。TTLを短く設定しておく。
動作確認: DRリージョンでサービスが正常に動作することを確認。
サービス再開通知: 関係者、ユーザーへサービス再開を通知。

詳細なDR手順書を別途作成し、定期的にテスト・更新する。

13.4. DRテスト

頻度: 年に1回実施。
内容:
- DRリージョンに実際にインフラを構築し、バックアップからリストアする手順を確認 (DNS切り替えは行わないシミュレーション)。
- 復旧にかかる時間を計測し、RTO目標を達成できるか確認する。
- 手順書の問題点や改善点を洗い出し、更新する。
テスト環境: DRリージョンに一時的にリソースを作成して実施。テスト後はリソースを削除する。

14. 構成管理

14.1. AWS Config

有効化: 全てのリージョンで有効化する。
記録対象: サポートされている全ての種類のリソース。グローバルリソース (IAM等) も含める。
ルール (Config Rules):
- AWS Managed Rulesの中から、セキュリティポリシーや運用ルールに合致するものを有効化する。
  - 例: s3-bucket-public-read-prohibited, s3-bucket-public-write-prohibited, ec2-instance-no-public-ip, restricted-common-ports, iam-root-access-key-check, mfa-enabled-for-iam-console-access, vpc-flow-logs-enabled, encrypted-volumes など。
- (オプション) カスタムルールを作成し、独自のコンプライアンス要件をチェック。
修復アクション: (オプション) ルール違反時に自動修復アクション (例: SSM Automation実行) を設定。慎重に検討・テストする。
記録の保管: S3 (wp-prod-logs-ACCOUNTID/configlogs/) に保管。
活用: リソース構成変更履歴の追跡、コンプライアンスチェック、セキュリティ監査。

14.2. AWS Systems Manager Inventory

設定: SSM AgentがインストールされたEC2インスタンスを対象に、インベントリ収集を有効化する。
収集対象:
- AWSコンポーネント (EC2ドライバ, エージェント等)
- アプリケーション (WordPress, PHP, Webサーバー, etc.)
- ファイル情報 (特定のパス、バージョン情報等)
- ネットワーク設定 (IPアドレス, MACアドレス, DNS等)
- インスタンス詳細 (OS情報, ホスト名等)
- サービス (稼働中のサービス, 起動タイプ等)
- Windowsレジストリ/ロール (Windowsの場合)
収集頻度: 1日1回 (デフォルト)
活用: インストールされているソフトウェアとそのバージョンの把握、パッチ適用の要否判断、ライセンス管理、構成ドリフトの検出。

14.3. 構成ドキュメントの自動化

目的: 手動でのドキュメント更新漏れを防ぎ、常に最新の構成情報を参照可能にする。
方法:
- IaC (Terraform/CloudFormation): コード自体が構成定義となる。
- スクリプト/ツール: AWS CLIやSDKを使用し、特定のリソース情報 (例: SGルール、IAMポリシー、EC2一覧) を定期的に取得し、Markdown形式などでS3やGitリポジトリに出力する。
- サードパーティツール: (オプション) CloudMapper, Hava.ioなどの構成可視化・ドキュメント化ツールを検討。
保管場所: S3 (wp-prod-configdocs-ACCOUNTID) またはバージョン管理されたGitリポジトリ。

15. デプロイ・プロビジョニング

15.1. インフラプロビジョニング (IaC)

ツール: Terraform を使用する。（CloudFormationも選択肢）
コード管理: Gitリポジトリ (GitHub or AWS CodeCommit) で管理。ブランチ戦略 (例: Gitflow) を採用。
状態管理(State): S3バケット (wp-prod-tfstate-ACCOUNTID) とDynamoDBテーブル (wp-prod-tfstate-lock) を使用し、リモートで状態を管理・ロックする。
実行環境: 管制塔アカウントのEC2インスタンスまたはCI/CDパイプライン (CodePipeline/GitHub Actions) 上で実行。
ワークスペース: 環境 (prod/stg) ごとにワークスペースを分け、設定値 (tfvars) を管理する。
適用フロー:
1. 開発ブランチでコード変更。
2. Pull Requestを作成し、レビュー。terraform plan の結果を確認。
3. mainブランチにマージ。
4. CI/CDパイプラインが自動で terraform apply を実行 (手動承認ステップを挟むことも可能)。

15.2. アプリケーションデプロイ (CI/CD)

対象: WordPressコア、テーマ、プラグイン、カスタムコード
ソースコード管理: Gitリポジトリ (GitHub or AWS CodeCommit)
ツール: GitHub Actions を使用する。（AWS CodePipeline/CodeBuild/CodeDeployも選択肢）
ワークフロー概要 (例):
1. トリガー: mainブランチへのPush (またはPull Requestマージ)。
2. ビルド:
  - 依存ライブラリのインストール (Composerなど)。
  - 静的ファイルの圧縮・最適化。
  - テストコード実行 (単体テスト、静的解析)。
  - デプロイ用パッケージ (zip等) の作成。
3. デプロイ:
  - (戦略: Blue/Greenまたはローリングアップデート)
  - SSM Run CommandまたはCodeDeploy Agentを使用し、ターゲットEC2インスタンス群にパッケージを配布・展開。
  - Webサーバードキュメントルートへの配置、必要な設定変更 (パーミッション等)。
  - (Blue/Greenの場合) ALBのターゲットグループ切り替え or Route 53の重み付けレコード変更。
4. キャッシュクリア: CloudFrontのキャッシュを無効化 (Invalidation)。
5. 通知: デプロイ結果をChatOps等へ通知。
注意点:
- WordPressコアのアップデートは慎重に行う。自動化せず、検証環境で十分テストした上で手動適用を基本とする。
- データベーススキーマ変更を伴うアップデートは、別途マイグレーション手順を確立する。
- ユーザーがアップロードしたメディアファイル (S3) やWordPress管理画面からの変更は、このCI/CDパイプラインの対象外。

15.3. 環境管理

環境分離: 本番(prod)、検証(stg)環境をAWSアカウントレベルで分離する。
設定値管理:
- DB接続情報、APIキーなどの機密情報はAWS Secrets Managerで管理する。
- 環境ごとに異なる非機密設定値 (例: エンドポイントURL、機能フラグ) は、SSM Parameter Store または Terraformのtfvarsファイルで管理する。アプリケーションは起動時や実行時にこれらの値を取得する。

16. パッチ管理

16.1. OSパッチ (EC2)

ツール: AWS Systems Manager Patch Manager を利用する。
パッチベースライン:
- カスタムベースライン (wp-prod-al2-baseline) を作成。
- 対象OS: Amazon Linux 2
- 承認ルール: 分類(Security, Bugfix等)と深刻度(Critical, Important等)に基づき、リリース後7日経過したパッチを自動承認。※特定のパッチを除外することも可能。
パッチグループ: EC2インスタンスに PatchGroup タグを付与し、ベースラインと関連付ける (例: PatchGroup=wp-prod-web)。
適用フロー:
1. スキャン: Patch Managerのメンテナンスウィンドウ (週次、深夜帯) で Scan タスクを実行し、適用が必要なパッチを特定。結果はSSM Complianceで確認。
2. 検証環境への適用: 検証環境のEC2に対し、別のメンテナンスウィンドウで Install タスクを実行し、パッチを適用。再起動が必要な場合は行う。
3. 動作確認: 検証環境でWordPressおよび関連ミドルウェアが正常動作することを確認。
4. 本番環境への適用計画: 問題なければ、本番環境への適用日時を計画 (例: 月1回、メンテナンス時間帯)。
5. 本番環境への適用: 本番環境のEC2に対し、計画したメンテナンスウィンドウで Install タスクを実行。ローリング方式で適用し、サービス影響を最小化する。
注意: OS上のパッチ適用自動設定 (yum-cron等) は無効にしておく。Patch Managerで一元管理する。

16.2. RDSメンテナンス

メンテナンスウィンドウ: RDSインスタンス作成時に、業務影響の少ない曜日・時間帯 (例: 日曜深夜 04:00-05:00 JST) を指定する。
パッチ適用:
- AWSによるOSパッチやDBエンジンバージョンアップ (マイナーバージョン) は、指定したメンテナンスウィンドウ中に自動的に適用される場合がある (必須メンテナンス)。
- 事前にPersonal Health Dashboardやメールで通知されるため、内容を確認する。
- 延期可能なメンテナンスは、影響を考慮し実施タイミングを検討する。
DBエンジンメジャーバージョンアップ:
- 自動では適用されない。互換性を十分に検証した上で、手動で計画的に実施する必要がある。
- 検証環境で先行してアップグレードし、テストを行う。

17. 可用性設計

17.1. 目標稼働率

99.9% (月間停止許容時間: 約43分)
Mediumレベルの重要度に基づき設定。

17.2. 冗長化構成

基本方針: Single-AZ構成を基本としつつ、コンポーネントレベルでの障害対策と迅速な復旧を目指す。
EC2:
- Auto Scaling Groupによる複数インスタンス構成は採用しない（コストと運用負荷考慮）。
- EC2 Auto Recovery機能を有効化し、AWS基盤側の障害時には自動でインスタンスを再起動させる。
ALB:
- AWS側で冗長化されているが、AZ障害には対応できない。
- ヘルスチェックにより異常なEC2インスタンスを自動的に切り離す。
RDS:
- Single-AZ構成。AZ障害時はバックアップからのリストアで対応 (RTO 4時間)。
- 高可用性が必要な場合はMulti-AZ構成を検討。
S3:
- AWS側で複数AZにデータが複製され、高い耐久性を持つ。
- バージョニングにより誤削除・上書きからの復旧が可能。
CloudFront:
- 世界中のエッジロケーションに分散され、高い可用性を持つ。オリジン障害時はキャッシュで応答可能な場合あり。
Route 53:
- 100% SLAが提供され、非常に高い可用性を持つ。

17.3. メンテナンス計画

計画メンテナンス:
- OSパッチ適用、WordPressメジャーアップデート、インフラ構成変更など。
- 原則として深夜・早朝の業務影響の少ない時間帯に実施する。
- 実施ウィンドウ例: 毎月第3日曜日 00:00 - 05:00 JST
- 影響が大きい変更の場合は、事前にユーザーへの告知を行う。
緊急メンテナンス:
- 重大な脆弱性への対応など、緊急性が高い場合。
- 可能な限り影響を最小限に抑える手順で実施し、事後報告を行う。
計画停止:
- メンテナンススケジュールに規定されない特別なメンテナンスで、サービスの停止が必要な場合。
- 原則として実施しない。やむを得ない場合は、最低2週間前に関係者へ通知し、承認を得て実施。

18. 命名規則・タグ設計

18.1. 命名規則

PDF記載の命名規則表に基づき、リソース名を統一する。

基本ルール:
- 英小文字、数字、ハイフン(-) のみ使用。
- 単語間はハイフンで結ぶ。
- マルチバイト文字、大文字、アンダースコア(_)は使用しない。
構成要素:
- {sysname}: システム識別子 (例: wp)
- {env}: 環境 (例: prod, stg, dev)
- {nlayer}: ネットワーク層 (例: public, private, protected)
- {type}: リソース種別 (例: vpc, subnet, rtb, igw, nat, sg, ec2, rds, alb, s3, iam, role, policy)
- {use}: 用途 (例: web, db, bastion, media, logs, backup, tfstate)
- {identifier}: 連番、AZ識別子など (例: 01, 1a, web01)
例:
- VPC: wp-prod-vpc
- Subnet: wp-prod-private-subnet01a
- EC2: wp-prod-web01
- RDS: wp-prod-aurora-pg-cluster
- S3 Bucket: wp-prod-media-111111111111
- Security Group: wp-prod-web-sg
- IAM Role: wp-prod-web-role

18.2. タグ設計

リソースの識別、コスト管理、運用自動化のためにタグを付与する。

必須タグ: 全てのリソースに可能な限り付与する。

タグキー	説明	値の例
`Name`	リソース名 (命名規則に従う)	`wp-prod-web-sg`
`Environment`	環境 (本番/検証/開発)	`prod`, `stg`, `dev`
`SystemName`	システム識別子	`wp`
`Project`	プロジェクト名またはコード	`WordPress Site Project`
`CostCenter`	コスト負担部門またはコード	`IT Department`, `CC12345`
`Owner`	リソース管理責任者またはチーム	`Infra Team`, `john.doe`
`TechnicalContact`	技術的な問い合わせ先	`infra-admins@example.com`

運用自動化タグ: 特定の運用 (バックアップ、パッチ適用、起動停止) の対象リソースを識別するために使用。

タグキー	説明	値の例
`Backup`	AWS Backupの対象指定用	`Daily`, `Weekly`
`PatchGroup`	SSM Patch Managerの対象指定用	`wp-prod-web`, `wp-stg-db`
`EC2DailyStartStop`	EC2の自動起動停止用 (Automationタグの例)	`True`
`EC2StartTime`	自動起動時刻 (例: `0900`)	`0900`
`EC2StopTime`	自動停止時刻 (例: `2100`)	`2100`

その他: 必要に応じてアプリケーション固有のタグ (ApplicationID, ApplicationRole, Component) などを追加。
タグ付け: リソース作成時にTerraform等で自動付与する。手動作成時も付与を徹底。定期的にタグ付け状況を確認 (Config Rules等)。

19. コスト最適化

19.1. コスト見積もり

AWS Pricing Calculatorを使用し、初期構築費用および月額ランニングコストを試算する。
主要なコスト要因: EC2, RDS, NAT Gateway, データ転送量, EBS, S3, CloudWatch (Logs, Metrics, Alarms), WAF。
試算結果は関係者と共有し、予算内であることを確認する。

19.2. コスト削減策

インスタンスタイプの最適化:
- Compute OptimizerやCloudWatchメトリクスに基づき、EC2およびRDSインスタンスのサイジングを定期的に見直す (過剰スペックでないか確認)。
- 最新世代のインスタンスタイプ (例: gp3 EBS, GravitonベースEC2/RDS) を利用し、コストパフォーマンスを向上させる。
購入オプションの活用:
- リザーブドインスタンス (RI) / Savings Plans (SP): 稼働時間が長く、インスタンスタイプが固定的なEC2、RDSに対して適用を検討する (1年または3年契約)。SPの方が柔軟性が高い。事前に利用状況を分析し、最適なプランを選択。
ストレージコスト削減:
- EBS: 不要なスナップショットを定期的に削除。gp3ボリュームのIOPS/スループットを必要最低限に設定。
- S3: ライフサイクルポリシーを活用し、アクセス頻度の低いデータを低コストなストレージクラス (Intelligent-Tiering, Glacier Instant Retrieval, Glacier Deep Archive) へ移行。
データ転送コスト削減:
- CloudFrontを活用し、オリジンへのデータ転送量を削減。
- 可能な限り同一リージョン、同一AZ内での通信を行う。
- VPCエンドポイントを利用し、パブリックインターネット経由のデータ転送を避ける。
不要リソースの停止・削除:
- 検証環境や踏み台サーバーなど、利用時間外は停止する (自動停止スクリプトやSSM Automationを活用)。
- 使用していないEBSボリューム、Elastic IP、スナップショットなどを定期的に棚卸しし、削除する (Trusted Advisorやカスタムスクリプトで検出)。
NAT Gatewayコスト:
- データ転送量が多い場合、コストが高額になる可能性がある。VPCエンドポイントの活用や、代替構成 (例: プロキシサーバー) を検討。
CloudWatchコスト:
- カスタムメトリクスの収集頻度、ログの保持期間、アラーム数を見直し、不要なものを削減する。
- VPC Flow Logsの送信先をS3のみにする（CW Logsへの送信はコスト増）。
コスト監視:
- AWS Budgetsを設定し、予算超過アラートを受け取る。
- Cost Explorerでコストの内訳や傾向を定期的に分析する。
- コスト配分タグを活用し、プロジェクトや部門ごとのコストを可視化する。

20. 運用設計

20.1. 運用体制

役割	担当チーム/担当者	主な責務
インフラ運用担当	Infra Team	監視、障害一次対応、パッチ適用、バックアップ/リストア、定常オペレーション実施、手順書メンテナンス、コスト管理、AWSサービス管理、セキュリティ運用
アプリ運用担当	App Team / Developers	WordPress本体・テーマ・プラグインのアップデート、コンテンツ管理、アプリケーションレベルの障害対応、インフラチームとの連携
セキュリティ担当	Security Team	セキュリティポリシー策定・維持、脆弱性管理、インシデントレスポンス統括、監査対応、GuardDuty/Inspector/SecurityHub等の管理
エスカレーション先	(役職/氏名)	重大インシデント発生時の意思決定、関係部署調整

連絡手段: ChatOps (Slack等)、電話、メール。インシデント管理ツール (Jira Service Management, Redmine等) を利用。
責任分界点: 各チームの責任範囲を明確にし、連携フローを定義する。

20.2. 定常運用タスク

タスク名	頻度	担当	概要	ツール/手順書
監視アラート確認	随時	インフラ運用担当	CloudWatchアラート、PHDイベント、その他監視ツールからの通知を確認し、必要に応じて対応。	CloudWatch, 手順書
ログレビュー	日次/週次	インフラ/セキュリティ	主要なエラーログ、セキュリティログ、アクセスログを確認し、異常や不審な傾向がないか分析。	CW Logs Insights, Athena
バックアップ成否確認	日次	インフラ運用担当	AWS Backupジョブの結果を確認し、失敗している場合は原因調査・再実行。	AWS Backup Console
リソース棚卸し	月次	インフラ運用担当	不要なリソース (EBS, EIP, Snapshot等) がないか確認し、あれば削除。タグ付け漏れがないか確認。	Trusted Advisor, スクリプト
コストレポート確認	月次	インフラ運用担当	Cost Explorerでコスト実績を確認し、予算との乖離や想定外のコスト増がないか分析。レポート作成。	Cost Explorer, Budgets
OSパッチ適用	月次 (計画)	インフラ運用担当	Patch Managerによるスキャン結果に基づき、検証環境でのテスト後、本番環境へ計画的に適用。	Patch Manager, 手順書
WordPress関連更新	適宜 (計画)	アプリ運用担当	WordPressコア、テーマ、プラグインのアップデート情報を確認し、検証環境でのテスト後、本番環境へ適用。	手順書
脆弱性スキャン確認	週次/月次	セキュリティ担当	Inspectorのスキャン結果を確認し、検出された脆弱性に対する対応を計画・実施依頼。	Inspector, Security Hub
GuardDuty Findings確認	日次/週次	セキュリティ担当	GuardDutyの検出結果を確認し、必要に応じて調査・対応。	GuardDuty, Security Hub
リストアテスト	半年次	インフラ運用担当	定義されたシナリオに基づき、バックアップからのリストアテストを実施し、手順とRTOを確認・改善。	AWS Backup, 手順書
DRテスト	年次	インフラ運用担当	DR手順に基づき、DRリージョンでの復旧テストを実施し、手順とRTOを確認・改善。	AWS Backup, 手順書
アクセス権限レビュー	半年次/年次	インフラ/セキュリティ	IAMユーザー、グループ、ポリシー、ロールの権限を見直し、不要な権限やユーザーを削除。	IAM Access Advisor
手順書メンテナンス	適宜	各担当	構成変更やプロセス改善に伴い、関連する手順書を更新する。

20.3. インシデント管理

インシデント検知: 監視アラート、利用者からの報告、運用担当者による発見など。
記録: インシデント管理ツールに、発生日時、事象、影響範囲、対応状況、担当者などを記録する。
一次切り分け・対応: インフラ運用担当が、手順書に基づき影響範囲の特定、原因調査、暫定対応・恒久対応を実施する。
エスカレーション: 対応困難な場合や影響が大きい場合は、アプリ運用担当、セキュリティ担当、上位者へエスカレーションする。
情報共有: 関係者へ状況を適時報告する (ChatOps, メール等)。
クローズ: 復旧確認後、インシデント記録に対応結果、原因、再発防止策を追記し、クローズする。
事後レビュー (PIR): 重大インシデント発生後、関係者でレビュー会議を実施し、原因分析と再発防止策の有効性を評価・改善する。

20.4. 変更管理

変更要求: インフラ構成、アプリケーション、運用手順等に対する変更要求は、変更管理プロセスに従って行う。
申請・承認: 変更内容、理由、影響範囲、手順、テスト計画、ロールバック計画を記載した申請書を作成し、関係者のレビュー・承認を得る。
実施: 承認された計画に基づき、原則としてメンテナンスウィンドウ中に変更作業を実施する。
結果確認: 変更後の動作確認、監視状況の確認を行う。
記録: 変更管理ツールまたは台帳に変更履歴を記録する。関連ドキュメント (設計書、手順書) を更新する。

以上