AWSについて

2025/2/42025/3/18

姉川寛生

初期設定

セキュリティ設定

ルートアカウントはGoogle Authenticato‪r‬（Google 認証システム）を使用して、
二段階認証をかけておく。

左記の認証システムを使用してIAMでMFAを追加する

デバイス名は任意の名称でOK
ただし、Google Authenticato‪r‬に表示される名前なので、どのMFAか分かりやすい名称にした方が良い
「認証アプリケーション」を選択

ステップに従い登録
シークレットキーは、「Google Authenticato‪r‬」に登録したMFAが何かの拍子で消えてしまい復元したい時や、別の端末にインストールしたい時に使用するため必ず控えておく。
※シークレットキーは再度表示されないので、必ずここでメモしておく

IAMの設定

IAMとはAWSで自分だけのユーザーやグループを作成できるサービスのこと。
※料金は無料

ルートアカウントはAWSアカウント作成後の初期設定や、AWSを解約するときくらいしか使用しない。

全ての操作ができてしまう超強力なアカウントは普段は使用せず、
代わりにルートアカウントに近い管理者権限をもつIAMユーザーを作成し、
そちらを使用する。

IAMパスワードポリシーを強化

ここで設定するパスワードポリシーはIAMユーザーに対してのみ適用されます。
ルートアカウントには適用されません。

デフォルトのパスワードポリシーはセキュリティが弱いので以下へ変更します。

アカウント設定
パスワードポリシーの「編集」をクリック

カスタムで左図の設定に変更

Security Token Service (STS)を東京リージョン以外は無効にする

Security Token Serviceとは
「AWSサービスにアクセスするための一時的な認証情報」を発行するサービスのことです。
使用する予定がないリージョンのサービスは無効にしてください。
※「グローバルエンドポイント」、「米国東部 (バージニア北部)」は無効化できない

「アジアパシフィック (東京)」以外は非アクティブに変更する。
※東京以外で使用するリージョンのサービスがあればそれはアクティブにしておく

IAMグループを作成

IAMグループを作成し、グループにポリシーをアタッチする事で、
そのグループに所属するユーザー全員に同じポリシーが適応されるため管理が楽になる。

ユーザーグループを選択
「グループ作成」を選択

ユーザーグループ名に任意の名前を付ける

「許可ポリシーを添付」ではIAMグループに好きな権限を設定することができます。
作成するアカウントの作業内容によって、許可するポリシーを絞る事で、セキュアな運用ができる。
まずは、rootアカウントの次に権限が強いアカウントを作成したいので、「AdministratorAccess」にチェックを入れて作成する。

IAMユーザーを作成

ユーザーを選択
「ユーザーの作成」を選択

ユーザー名は任意の名前を入力
「AWS マネジメントコンソールへのユーザーアクセスを提供する」にチェック
「自動生成されたパスワード」にチェック
※カスタムでもOK
「ユーザーは次回のサインイン時に新しいパスワードを作成する必要があります」のチェックを外す。
※外部の作業者にアカウントを払い出すのであれば、チェックを入れておく。

「ユーザーをグループに追加」に選択
事前に作成しておいたグループで所属させたいグループを選択

確認内容に誤りがなければ「ユーザーの作成」を選択

作成したユーザーがAWSのコンソールにサインインするために必要な情報が表示されるので控えておく。
「.csvファイルをダウンロード」で取得できるファイルにサインインに必要な全ての情報が記載されているのでこちらを取得でもOKです。

支払い通貨をドルから日本円へ変更

AWSの料金はデフォルトではドルで請求されるので、日本円に変更しましょう。
外貨取扱手数料を節約できます。
※本操作はルート権限のアカウントで行う

右上のアカウント名を選択
「アカウント」を選択
「支払い設定」を選択

「デフォルトの支払い通貨」をJPYに変更

代替の連絡先

AWSアカウント作成時に登録したメールアドレス以外に、
タイプごとに別の連絡先を設定する事が可能。
共通のメーリスやクライアント先など、
別のメールアドレスや電話番号に通知したいときは設定しておくと便利です。

請求に関する連絡先
AWS料金の請求書などの通知
オペレーションに関する連絡先
AWSの操作に関する通知
セキュリティに関する連絡先
不正使用された時や認証情報が漏洩したときなどの通知

Cost Management（コスト管理）の設定

コストエクスプローラーの有効化

右上のアカウントから「Cost Explorer」を選択
「Cost Explorerを起動」を選択

ブラウザの別タブが起動して以下が表示されれば設定完了。

予算の作成

AWSは重量課金のため、「気づかないまま余計な料金が発生していた」ということを防ぐためにも
予め予算を作成して起き、「自分で決めた予算を超える場合にアラートメールを送信する」という
設定をしておきましょう。

右上のアカウントから「予算」を選択
「予算を作成」を選択

「カスタマイズ（アドバンスト）」を選択
「コスト予算」を選択

任意の予算名を付ける
月単位での管理を作成したいのであれば、
左図のような「月別AWS全体予算」といった名称

設定したい予算の条件によって、
「期間」や「予算更新タイプ」を設定
月の予算管理であれば、左図のような設定

AWS全体サービスの予算管理をするのであれば、
「すべてのAWSのサービス」を選択
詳細オプションは「非ブレンドコスト」

設定した予算に対してアラートを作成。
「実際」に消費した金額と
「予測」で設定金額に達しそうな2つのタイミングで登録。

「実際」…しきい値は90％
「予想」…しきい値は100％
※「実際」のしきい値はケースバイケースで変更

「アクションをアタッチ」を設定すると、
予算をオーバーした際に、EC2インスタンスを停止するなとの対応が可能になる。

設定内容を確認し、
問題がなければ「予算を作成」を選択

AWS CloudTrailを設定

CloudTrailはAWSにおける操作ログを記録するサービスです。
基本的にデフォルトで有効になっている。
自分のAWSを誰かに不正利用されたときに、
誰が・いつ・何をしたか確認可能になったり、
行った作業の証明が可能になる。

実際の画面

誰（どのユーザー）が何に対して（リソースタイプ）、何をした（イベント名）などが分かる。

CloudTrailのイベント履歴には90日間分が無料で保存されます。
90日以上保存したい場合は、「証跡」を作成してS3へ保存します。
※S3への保存料金は発生します。

Amazon CloudWatch LogsへCloudTrailのログを送信することによってモニタリングを行うことができます。
※Amazon CloudWatchの利用は料金が発生します。

AWS環境の構築イメージ

上記は最も基本的なAWSの構成図になります。
ユーザーがインターネットにアクセスし、
AWS環境内に作成した自分だけのVPC（Virtual Private Cloud）にて、
必要なサービスを立ち上げて構築する。

VPC

VPCとは？

VPCはVirtual Private Cloudの略

AWSアカウント内に自分だけのネットワーク領域を作成できるサービス

VPCを作成することでEC2など自分だけのサーバーを構築することができる

VPCはアベイラビリティゾーン(AZ)をまたいで作成できる

VPCに関連するサービスで基本として使用するのは下記の3つ

① サブネット
② ルートテーブル
③ インターネットゲートウェイ

サブネットとは

利用料は無料

VPC内のネットワークを分割したもの

EC2やRDSなどのAZサービスは1つのサブネット内に配置される

サブネットは必ず一つのアベイラビリティゾーン(AZ)の中に作られる

サブネットはAZをまたいで作成できない

対象のサブネットに関連付けられたルートテーブルの送信先にインターネットゲートウェイを設定した場合、そのサブネットはパブリックサブネットと呼ばれる

上記以外のサブネットは全てプライベートサブネットと呼ばれる

ルートテーブルとは

利用料は無料

どこに接続するかのネットワーク経路を設定する

ルートテーブルはサブネットごとに割り当てる

インターネットゲートウェイとは

利用料は無料

VPCとインターネットとの境界線

インターネットゲートウェイをVPCにアタッチしルートテーブルの送信先に設定することで、インターネット接続できるようになる

基本的にインターネットゲートウェイはパブリックサブネットのルートテーブルに割り当てる

上記を踏まえたVPCの構築イメージ

東京リージョンのアベイラビリティゾーン 1aと1cを使用し、マルチAZ環境を構築可能にする

インターネットから直接アクセスできるパブリックサブネットと、インターネットからは直接アクセスできないプライベートサブネットを作成

ルートテーブルはパブリックサブネット用とプライベートサブネット用の二つを作成

パブリックサブネットからインターネットゲートウェイを経由してインターネット接続できるようにする

構築ステップ

① VPCを作成する
② サブネットを作成する
③ ルートテーブルを作成する
④ インターネットゲートウェイを作成する
⑤ パブリックサブネット用のルートテーブル送信先にインターネットゲートウェイを設定する

上記①～⑤を簡単に一括で行うにはVPC作成時に「VPC など」を選択し、必要な設定を行う。

VPCの一括作成

一括設定を行う事で、下記構成図のような
サブネット（パブリック・プライベート）の作成やルートテーブルの作成・紐づけなど自動で行ってくれる。

検索窓で「vpc」と調べて「VPC」サービスに遷移
右上に表示されているリージョンが正しいか確認
リージョンに問題がなければ「VPCを作成」を選択

作成するリソースは「VPC など」を選択

任意のプロジェクトの名前を記入。
ここで記入したnameに基づき、下層のサブネットワーク名等が自動的に入力される。

IPv4 CIDR ブロックはデフォルトの「10.0.0.0/16」でOK。
特別な要件がなければ、基本的に「IPv6 CIDR ブロックなし」でOK。

テナンシーは基本「デフォルト」でOK。

「デフォルト」は作成するEC2インスタンスは、他のユーザーと共有の物理サーバー上で実行されるということ。

「専有」は、作成するEC2インスタンスが存在する物理サーバーを自分専用とし、他ユーザーとは共有しない状態にするということ。
専有にすることで、他ユーザーのリソースの干渉等を受けず、よりセキュリティの高い状態になるが、コストが高い。

アベイラビリティゾーン (AZ) の数は、
冗長性を考えるのであれば、少なくとも「2以上」（2025年時点の推奨は3らしい）にする。
「AZ のカスタマイズ」は基本そのままでOK

パブリックサブネットの数は、EC2インスタンスをインターネットにアクセス可能にするために必要。
基本的にAZごとにEC2インスタンスを作成するため、AZと同じ数必要。
※インターネットに接続する必要がないのであれば、「0」でもOK。
プライベートサブネットの数は、インターネットアクセスを必要としないバックエンドリソース（DBとか）の数だけ必要。

例えば、wordpressであればDBが必要になるので、DBはプライベートサブネットに作成する。
また、プライベートサブネットのため、直接はインターネットに繋がっておらずセキュリティ的にも安全。

「サブネット CIDR ブロックをカスタマイズ」も基本的にデフォルトでOKだが、他で作成してるサービスのIPと被る用なら調整する。

基本的には「なし」でOK。

「NAT ゲートウェイ」とは、プライベートサブネットからあるリソースが、外部へ通信を行う際に必要となるリソース。こちらは構築すると利用されなくとも時間に応じて料金が発生する。

基本的には「S3ゲートウェイ」を選択。

VPCからS3にアクセスを行うためのリソース設定。
設定しても料金はかからないので、設定しておく。

「DNS ホスト名を有効化」「DNS 解決を有効化」は基本的にチェックでOK。

EC2

EC2とは？

EC2はAmazon Elastic Compute Cloudの略

AWSが管理するホストサーバーのハイパーバイザー上で動作する仮想サーバー

数分でサーバーを起動できる

EC2の対象OSはAmazon Linux, Red Hat, Windows Serverなど複数

EC2構築後にCPU、メモリ、ディスクの拡張などが柔軟にできる

使用した分だけ料金が発生する従量課金

12か月無料枠内であれば無料で構築可能

EC2の構築イメージ

セキュリティグループはSSHを自分のIPアドレスからのみインバウンド許可する

EC2をパブリックサブネット1aに構築し（複数のAZを持つのであれば、パブリックサブネット1cとかも構築）、インターネットゲートウェイ（IGW）を経由してSSHやHTTP接続する。

構築ステップ

① KMSのマネージド型キーを作成しESBの暗号化用キーを作成する
② セキュリティグループを作成する
③ EC2を作成する
④ EC2にSSH接続する

②～③は「インタンスの作成」で一括で出来る

KMSのマネージド型キーを作成しESBの暗号化用キーを作成する

KMSの利用は有料。
1つのキーにつき保管料として毎月約＄1くらい必要（2025年02月時点）
またKMSのAPIの利用料に応じて従量課金もあるが、
ESBの暗号化に使用するくらいであれば、ほぼ発生しない。

ESBを暗号化しておくことでデータをハッキングされても閲覧できなくなる。
案件によってはセキュリティ要件の高い環境を求められる場合があるので、
ESBに対してキーによる暗号化を行うのは有効な手段になる。
また、この対応はデータ削除を行う際も高いセキュリティ要件を満たす事ができる。

クラウドにおける安全なデータの廃棄

ストレージ領域をデフォルトで暗号化を行う設定とすることで第三者によるアクセスへの保護を実現します。そしてEBSやS3 Bucketを削除する際には、あわせて当該領域の暗号化に用いた鍵をAWS Lambdaを使用してKMSより削除します。これにより従来行っていた当該データの復号が困難になるとともに廃棄証明の代わりとして、暗号化による保護を実施した記録をお客様自身で自動的に取得、管理することができるようになります。鍵へのアクセスが無くなることで、当然AWSによっても、またお客様も廃棄されたデータへのアクセスはできなくなります。

https://aws.amazon.com/jp/blogs/news/data_disposal

下記の操作は「AdministratorAccess」の権限があるIAMユーザーで実行してください。

検索窓に「kms」と検索
表示されているリージョンが適切か確認し、問題なければ「キーの作成」を選択
ESBの暗号化用に作成するのであれば、「カスタマー管理型のキー」にする。
※「マネージド型キー」は削除する事ができないので、ESBを削除する時に、「キーも削除して復元化も不可の状態にする」という事ができない。

キーのタイプは「対象」を選択
キーの使用法は「暗号化および復元化」を選択
詳細オプションはデフォルトのままでOK
※「単一リージョンキー」を選択することにより、
EBSを他のリージョンにコピーしたりできなくなるが、その分、セキュリティ的な要件は高まる。
他リージョンにコピーが想定されるような案件でなければ、「マルチリージョンキー」にする必要ははい。

エイリアスは下記のような方式でキーの目的や管理を簡単に識別できるような名称にして、一意の内容にする。
・環境（例：dev, test, prod）
・使用目的またはプロジェクト名
例：dev-ebs-encrypt
　　→開発環境のEBS暗号化キー

エイリアスとは？
エイリアスを使用することで、キーをローテーションした場合など、エイリアスの紐づけを変更するだけで対応でき、アプリケーション側の更新が不要になります。

「確認にスキップ」を選択
※「ラベルを追加」以降の設定は要件によって必要な内容を設定

インスタンスの作成

下記の操作は「AdministratorAccess」の権限があるIAMユーザーで実行してください。

検索窓で「ec2」を検索
リージョンを確認
「インスタンスを起動」を選択

任意の名前を記入

命名ルールとして、
下記の内容を含めると管理しやすい
・環境
・用途
・プロジェクト名またはアプリケーション名
・インスタンスの番号またはロール

Amazon マシンイメージ (AMI)で選択するOSは参考記事も多い「Amazon Linux 2」を選択
※2025年2月時点
アーキテクチャはデフォルトの「64ビット（ｘ86）」でOK

インスタンスタイプは用途に応じたインスタンスを選択

キーペア（ログイン）は「新しいキーペアの作成」を選択

キーペア名は任意の名前を入力。
命名ルールとして、
下記の内容を含めると管理しやすい
・環境
・用途
・プロジェクト名またはアプリケーション名
・発行日や管理番号
キーペアのタイプは「RSA」を選択
プライベートキーファイル形式は「.pem」を選択
「キーペアを作成」を選択
※ダウンロードされるpemファイルはSSH接続の際に使用したりするので、厳重に保管しておく

キーペア名に新しく作成したキーペアが選択されているか確認

VPCは作成したいネットワークを選択
サブネットはVPC内のパブリックサブネットを選択
※複数のAZを作成しているのであれば、どのAZのサブネットで作成するか選択する
※今回は一般的なwebサイトの構築を想定しているので、パブリックサブネットを選択
パブリックIPの自動割当ては「有効化」を選択
※セキュリティ要件等で、即時にインターネットに接続させたくないのであれば「無効」にする。
※後程でElastic IPを設定するため、最終的にパブリックIPは使用しなくなる

「セキュリティグループを作成」を選択
※デフォルトのポリシーではセキュリティが弱いため
セキュリティグループ名は任意の名前を入力
管理しやすい名称にしておく。

インバウンドセキュリティグループのルールを設定。
要件に応じて追加する内容に変動はあるが、
少なくとも左図で設定している3つは設定が必要

タイプ: SSH
プロトコル: TCP
ポート範囲: 22
ソースタイプ: 特定のIPアドレス (例: あなたのオフィスや自宅のIPアドレス)

タイプ: HTTP
プロトコル: TCP
ポート範囲: 80
ソースタイプ:カスタム
ソース: 0.0.0.0/0

タイプ: HTTPS
プロトコル: TCP
ポート範囲: 443
ソースタイプ:カスタム
ソース: 0.0.0.0/0

高度なネットワーク設定はデフォでOK。

ストレージのボリュームは要件ごとに設定
ESBの暗号化のため、「アドバンスト」を選択

暗号化済みは「暗号化済み」を選択
KMS キーは「① KMSのマネージド型キーを作成しESBの暗号化用キーを作成する」で作成したキーを選択

高度な詳細では、終了保護を「有効化」しておく。
※これを有効化する事で、操作を誤ってインスタンスを削除してしまった際にも削除エラーを出してくれる

最後に「インスタンス起動」を選択し、
起動したインスタンスの初期化が完了すればOK。

EC2にSSH接続する

Tera Termを起動し、「ホスト」にEC2インスタンスのパブリック IPv4 アドレスに表示されているIPアドレスを入力し、「OK」をクリックします。

セキュリティ警告は「このホストをknown hostsリストに追加する」にチェックが入っていることを確認し、「続行」を選択

ユーザ名に「ec2-user」を入力し、「RSA/DSA/ECDSA/ED25519鍵を使う」にチェックを入れ右のアイコンを選択。
EC2インスタンス作成時に作成したペアキー（.pem）を指定。

接続画面が表示されればOK

Elastic IP アドレスの割当

「Elastic IP」とは、
IPアドレスの固定化を行い、永続的に静的なIPを付与するサービスのこと。

インスタンスを作成すると、自動でパブリックIPが付与され、
そのパブリックIPで、インターネットを介してインスタンスへ接続することが出来るようになります。

しかし、自動パブリックIPだとインスタンスを再起動する度にパブリックIPが変わってしまうため、
外部からのアクセスが頻繁にあるようなインスタンスの場合不便（SSHのホスト設定も変わる）なので、
IPを固定してしまう。

Elastic IPを紐づけているインスタンスが起動している場合、割当てているIPの利用料は無料。

ただし、Elastic IPを紐づけているインスタンスが停止している場合、料金が発生するので注意。
インスタンスを停止する場合、Elastic IPも紐づけを解除して削除する事で料金が発生しない。

EC2サービス内の「Elastic IP」を選択し、「Elastic IP アドレスを割り当てる」を選択

「Amazon の IPv4 アドレスプール」を選択
ネットワークボーダーグループに表示されているのが、自身が利用しているリージョンになっているか確認
「割り振る」を選択

管理のため、「Name」に分かりやすい任意の名前を付ける
作成したIPアドレスを選択されている状態で、「アクション」の「Elastic IP アドレスを関連付ける」を選択

リソースタイプは「インスタンス」を選択
インスタンスは紐づけたいインスタンス名を選択
プライベート IP アドレスは紐づけたいインスタンスのプライベートIPアドレスを選択

紐づけたインスタンスのパブリック IPv4 アドレスがElastic IPで割り振ったIPアドレスになっていればOK

Elastic IP アドレスの解放

インスタンスを停止している場合や、固定IPが不要になった場合、
割当てていたIPアドレスを開放する。
開放することによって料金が発生しない。

解放したいIPアドレスがインスタンスに紐づいている場合、まずは「Elastic IP アドレスの関連付けを解除」を選択

「関連付けを解除」を選択

関連付けを解除した後、「Elastic IP アドレスを開放」を選択

「解放」を選択

解放したIPアドレスが、一覧リストに表示されていなければOK

EC2インスタンスの停止

インスタンスを起動している間は、料金が発生するため使用していないのであれば停止しておく。

「インスタンスの状態」から「インスタンスを停止」を選択

確認画面が表示されるので、問題無ければ「停止」を選択

※ただし、インスタンスに関連図けている各種サービス（Elastic IP アドレスやEBSボリューム）については、料金が発生し続けるので注意。

「インスタンスの状態」が「停止済み」になっていればOK

ミドルウェアのインストール

nginxでのwordpressの構築を目的としたフローで進行

NginxとPHPインストール

sudo yum -y update

SSHに接続して、OSにインストール済みのパッケージを全てupdateするため、左記のコードを実行

sudo amazon-linux-extras install -y nginx1 php8.2

amazon-linux-extrasでNginxとPHP(ver8.2)をインストール

amazon-linux-extras | egrep 'nginx|php8.2'

インストール後の確認。enabledとなっていればインストール完了

sudo yum install -y php-gd php-mbstring php-xml

PHP関連のパッケージを追加インストール

php-gd : WordPressにおける画像処理
php-mbstring : WordPressでマルチバイト文字（日本語）を処理
php-xml : WordPressのバックアップデータ(.xml)を扱う際に使用

yum list installed | grep ^php- | sort

必要なモジュールがインストールされているか確認
下図キャプチャと同じ内容になっていたらOK

※赤枠の部分はインストール時のバージョン等で差異があるかもしれないので、下記キャプチャと同じ内容になっていなくてもOK。

Nginx設定

Nginxの設定は下記のファイルで編集を行う
/etc/nginx/nginx.conf

上記のファイルに対して、下記3つの調整を行う。

① client_max_body_size

クライアントがリクエストするボディサイズの最大容量を指定するもので、デフォルトは1MB。
デフォルトのままだと、WordPress管理画面からテーマをアップロードした時や、WordPressのプラグインを使用したバックアップ＆リストア時に「413エラー」が発生する場合があるため、500MBに設定。

② try_files

WordPressのパーマリンクを変更できるようにするために設定。
Nginxはこの設定がないと、パーマリンク変更後にWordPressサイトの記事にアクセスすると「404エラー」が発生する。

③ error_page 404

存在しないURLにアクセスした際に画面に表示される「404エラー (Not Found)」を設定するパラメータ。
デフォルトのままだと、WordPressのテーマ毎に用意されている404.php（「404エラー (Not Found)」画面）を読み込めない。

まずは作業前にNginxの設定ファイルをバックアップを取る

sudo cp -p /etc/nginx/nginx.conf /etc/nginx/nginx.conf_bk

Nginxの設定ファイルをvimで編集。

sudo vim /etc/nginx/nginx.conf

serverディレクティブ内を↓の「編集後」の状態に修正する。

■ 編集前

server {
    listen       80;
    listen       [::]:80;
    server_name  _;
    root         /usr/share/nginx/html;

    # Load configuration files for the default server block.
    include /etc/nginx/default.d/*.conf;

    error_page 404 /404.html;
    location = /404.html {
    }

    error_page 500 502 503 504 /50x.html;
    location = /50x.html {
    }
}

■ 編集後

赤文字の部分が追加、もしくは変更した点

server {
    listen       80;
    listen       [::]:80;
    server_name  _;
    root         /usr/share/nginx/html;

    # Load configuration files for the default server block.
    include /etc/nginx/default.d/*.conf;

    client_max_body_size 500M;

    location / {
            try_files $uri $uri/ /index.php?$args;
    }

    error_page 404 = @notfound;
    location @notfound {
    include fastcgi_params;
    fastcgi_index index.php;
    fastcgi_param SERVER_NAME $host;
    fastcgi_param SCRIPT_FILENAME $document_root/index.php;
    fastcgi_param QUERY_STRING error=404;
    fastcgi_pass php-fpm;
    }

    error_page 500 502 503 504 /50x.html;
    location = /50x.html {
    }
}

最後にnginx.confの構文チェックを行い、エラーがないことを確認しておく。

sudo nginx -t

下記のテキストが表示されれば問題無し。

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

PHP設定

PHPの設定ファイル/etc/php.iniを修正。

上記のファイルに対して、下記2つの調整を行う。

① post_max_size

POST送信全体の最大データ容量を指定するもので、デフォルトは8MB。

② upload_max_filesize

1つのアップロードファイルにおける最大ファイル容量を指定するもので、デフォルトは2MB。

上記2つのパラメーターがデフォルトのままだと、WordPress管理画面からテーマをアップロードした時や、WordPressのプラグインを使用したバックアップ＆リストア時にエラーが発生する場合があります。
そのため、Nginxで設定した値（今回の場合500MB）と同じにしておく。

まずは作業前にphp.iniの設定ファイルをバックアップを取る

sudo sudo cp -p /etc/php.ini /etc/php.ini_bk

「post_max_size」と「upload_max_filesize」の値を置換する。

sudo sed -i "s/post_max_size.*/post_max_size = 500M/" /etc/php.ini
sudo sed -i "s/upload_max_filesize.*/upload_max_filesize = 500M/" /etc/php.ini

最後に、意図した置換が起きているかvimdiffで修正箇所を確認。

vimdiff /etc/php.ini_bk /etc/php.ini

memory_limitについて

php.ini にはデータサイズに関連する設定として “memory_limit” というパラメータもあります。

これは、PHPが利用可能なメモリの最大容量を指定するもので、デフォルトは128MBです。

サイトの規模（大規模なサイトや高トラフィックのサイト）によっては、256～512MBくらいに増やした方が良いかも。

ちなみに、有名なレンタルサーバー会社であるエックスサーバーだと “memory_limit”, “post_max_size”, “upload_max_filesize” は全て同じ値の 1GB で定義されています。
（スタンダードプランの場合）

sudo sed -i "s/memory_limit.*/memory_limit = 256M/" /etc/php.ini

PHP-FPM設定

PHP-FPMの設定ファイル/etc/php-fpm.d/www.confを修正。
デフォルトだとApache向けの設定になっているため、Nginxでも使用できるように変更。

まずは作業前にwww.confの設定ファイルをバックアップを取る

sudo cp -p /etc/php-fpm.d/www.conf /etc/php-fpm.d/www.conf_bk

“user”と”group”の設定をapacheからnginxに置換

sudo sed -i -e "s/^user = apache/user = nginx/" -e "s/^group = apache/group = nginx/" /etc/php-fpm.d/www.conf

PHP-FPMのUNIXソケットにおけるLISTEN設定を以下の通りに変更
listen.owner = nginx
listen.group = nginx
listen.mode = 0660

sudo sed -i -e "s/^;listen.owner.*/listen.owner = nginx/" -e "s/^;listen.group.*/listen.group = nginx/" -e "s/^;listen.mode/listen.mode/" /etc/php-fpm.d/www.conf

“listen.acl_users”はACL (Access Control List: POSIX アクセス制御)の設定
Linuxのパーミッション管理（オーナー・グループ・その他）の拡張版のような機能
今回は使用しないのでコメントアウトする
sedで”;&”と指定すると、左で指定した文字列を変更せずに先頭に”;”を付与する

sudo sed -i "s/^listen.acl_users.*/;&/" /etc/php-fpm.d/www.conf

vimdiffで修正箇所を確認

vimdiff /etc/php-fpm.d/www.conf_bk /etc/php-fpm.d/www.conf

OOM Killer対策：PHP-FPMチューニング

LinuxでOSの空きメモリ容量が不足すると、”OOM Killer” という処理により、メモリを多く使用しているプロセスが強制的にkillされます。
WordPressインストール後、サイトへの同時リクエスト数が増えると、それを処理するための複数のPHP-FPMの子プロセスがサーバーに自動生成されます。

PHP-FPMの子プロセス数が多くなると、その分だけOSのメモリがたくさん使われるという動きになります。

EC2を [t2.micro] (1vCPU, メモリ1GiB) で作成した場合、WordPressを使い続けていると上記理由でOSのメモリが不足するケースがあります。

このため、PHP-FPMの子プロセス数が多くなりすぎないように設定値をチューニングします。

※下記のチューニングはあくまで、 [t2.micro] 環境でwordpressを運用する事を想定した場合のチューニングです。
一律に下記の調整を行ったら良いという訳では無く、チューニングを行う際は使用しているサーバーのスペックや、実際のトラフィック、導入しているプラグインの負荷等を考慮し、PHP-FPMのログ (error_log) を確認して、メモリ不足やその他のエラーの原因を特定し、調整を行ってください。

“pm.max_children” はPHP-FPMが作成する子プロセスの最大数
今回はデフォルトの “50” から “10” に減らす

sudo sed -i "s/^pm.max_children.*/pm.max_children = 10/"  /etc/php-fpm.d/www.conf

“pm.max_spare_servers” はアイドル状態でプーリングしているPHP-FPMの子プロセス数の最大値
この設定値よりも多くの子プロセスが立ち上がっていた場合、
余剰分の子プロセスはアイドル時にkillされメモリが開放される
今回はデフォルトの “35” から “8” に減らす

sudo sed -i "s/^pm.max_spare_servers.*/pm.max_spare_servers = 8/"  /etc/php-fpm.d/www.conf

vimdiffで修正箇所を確認

vimdiff /etc/php-fpm.d/www.conf_bk /etc/php-fpm.d/www.conf

NginxとPHP-FPMのサービス起動

上記の処理を全て終えたら、NginxとPHP-FPMのサービスを起動して
設定内容を反映させます。

NginxサービスとPHP-FPMサービスの起動中に /etc/nginx/nginx.conf, /etc/php.ini, /etc/php-fpm.d/www.conf をいずれかを修正した場合は、設定を反映させるため必ず以下のサービス再起動を実行してください。

Nginxを起動

sudo systemctl start nginx

PHP-FPMを起動

sudo systemctl start php-fpm

サービス起動後の確認(“–sort cmd”オプションでプロセス名でソート)

ps -ef --sort cmd | grep -v grep | egrep 'nginx|php'

下記キャプチャのように、nginxやphp-fpmのmaster processが起動していればOK

NginxとPHP-FPMのログ関連のオーナーとパーミッション変更

NginxとPHP-FPMのログディレクトリとログファイルに対し、オーナー（所有者）とパーミッション（権限）を明示的に設定。

Nginxログディレクトリのオーナーをnginxユーザーに、グループをrootグループに変更

sudo chown nginx:root /var/log/nginx/

Nginxログディレクトリに以下の権限を設定
オーナー : 読み取り、書き込み、実行
グループ : 読み取り、書き込み、実行
他ユーザー: なし

sudo chmod 770 /var/log/nginx/

Nginxのアクセスログとエラーログのオーナーをnginxユーザーに、グループをrootグループに変更

sudo chown nginx:root /var/log/nginx/access.log /var/log/nginx/error.log

Nginxのアクセスログとエラーログに以下の権限を設定
オーナー : 読み取り、書き込み
グループ : 読み取り
他ユーザー: なし

sudo chmod 640 /var/log/nginx/access.log /var/log/nginx/error.log

PHP-FPMログディレクトリのオーナーをnginxユーザーに、グループをrootグループに変更

sudo chown nginx:root /var/log/php-fpm/

Nginxを再起動

sudo systemctl restart nginx

PHP-FPMを再起動

sudo systemctl restart php-fpm

PHP接続確認

ここまで来たら、NginxとPHPの連携が問題ないかを確認。
phpinfoのページを作成して確認。

sudo sh -c "echo '<?php phpinfo(); ?>' > /usr/share/nginx/html/path.php"
sudo chown nginx:nginx /usr/share/nginx/html/path.php

Webブラウザから以下にアクセスして確認。

http://EC2のパブリック IPv4 DNS/path.php
作成したEC2インスタンスの右図、
赤枠部分の内容に置き換える。

PHP情報ページが表示されれば、NginxとPHPの連携は成功です。

path.phpは残しておくとセキュリティ的に危ないので表示を確認したら削除。

sudo rm /usr/share/nginx/html/path.php

ミドルウェアのサービス自動起動設定

EC2を再起動したあとも、必要なサービス（Nginx, PHP-FPM）が自動起動するように設定。

自動起動をenableに設定

sudo systemctl enable nginx php-fpm

2つのサービスが”enabled”になったことを確認

systemctl is-enabled nginx php-fpm

上記のようにenabledになっていればOK

独自ドメインの追加

AWS環境で独自ドメインを使用したい場合、Route53を使用します。
今回は、お名前ドットコムで取得したドメインをAWS環境で使用する事を想定。

検索窓で「Route53」を検索
DNS管理の「ホストゾーンの作成」を選択

ドメイン名に使用したい独自ドメインを入力
タイプは「パブリックホストゾーン」を選択
「ホストゾーンの作成」を選択

登録をするとドメインに関連付けされたNSレコード(ネームサーバ)４点とSOAレコードが表示されます。お名前.com側にNSレコードの設定が必要になるため、タイプ「NS」に表示されている4つの値をメモ。

次にお名前ドットコムの管理画面にログインして、「DNS設定/転送設定－ドメイン一覧」から設定したい親ドメインを選択

「DNSレコード設定を利用する」の「設定する」を選択

Route53で表示された4つのレコードを一つずつ追加
※なる早で反映させたいのであれば、TTLの値を300くらいにしてみる。
ただし、TTLの値を常に小さくしておくのは、DNSサーバーへの負荷が大きくなるため、ドメインの反映が確認出来たら、一般的な86400くらいに戻す。

登録をするとドメインに関連付けされたNSレコード(ネームサーバ)４点とSOAレコードが表示されます。お名前.com側にNSレコードの設定が必要になるため、タイプ「NS」に表示されている4つの値をメモ。

登録をするとドメインに関連付けされたNSレコード(ネームサーバ)４点とSOAレコードが表示されます。お名前.com側にNSレコードの設定が必要になるため、タイプ「NS」に表示されている4つの値をメモ。

対象ドメインのネームサーバがRoute53に切り替わっているかを確認する場合、
コマンドプロンプトでnslookupコマンドを使って確認。

nslookup -type=NS 対象ドメイン

左図のようにNSレコードがRoute53で登録したホストゾーンの内容になっていればOK。

NSレコードを設定して、ドメインのDNS管理をRoute 53に委譲している状態でも、
Route 53側にそのサブドメインがどのIPアドレスに向かうべきか定義するAレコードがなければ解決できないため、登録したホストゾーンにAレコードを追加する。

登録したホストゾーンを開いて「レコードを作成」を選択

レコード名は、ルートドメインを登録する場合は空白でOK
※Route53上で新規のサブドメインを作成するのであれば、追加したいサブドメインの文字列を入力
レコードタイプは「A-IPv4アドレスと～」を選択
値には「EC2インスタンスのパブリック IPv4 アドレス」を入力
ルーティングポリシーは「シンプルリーティング」を選択

タイプがAでレコードが追加されていたらOK

DNSが反映されるまで少し待って、Route53に登録したドメインで、Nginxの初期ページが表示されれば設定完了

今回のNSレコードの設定で詰まった事

今回は、「cnsr-dev.com」という親ドメインに「aws-ane.cnsr-dev.com」という
AWS検証用のサブドメインを新規作成して作業を行おうとしました。

親ドメインはお名前ドットコムで管理していたので、
お名前ドットコムのDNS設定でサブドメインのNSレコードを登録したものの、
待てど暮らせどNSレコードがAWSを向かず。。。

nslookupで表示された内容を改めて確認してみると、
親ドメインのネームサーバーがお名前ドットコムではなく
何故かxserverを指定していることに気が付く

親ドメインのネームサーバーをお名前ドットコムのネームサーバーに切り替えた所、
お名前ドットコムの管理画面のDNS設定で追加したNSレコードの値が反映されて、
Route53上でサブドメインを扱えるようになりました。

お名前ドットコムで管理しているドメインなんだから、
当たり前のようにお名前ドットコムで設定ができると思ってましたが、
ネームサーバーの設定が変わっているケースもあるので、
そこらへんは確認が必要だと思いました。

ACM（SSL証明書）

Route53で登録したドメイン使用してACMでSSL証明書を取得

検索窓で「amc」と検索し、「Certificate Manager」を選択
「証明書をリクエスト」を選択

「パブリック証明書をリクエスト」を選択

完全修飾ドメイン名にはRoute53で登録した証明書を発行する際に使用するドメイン名を指定。
NSレコードの登録まで行っているのであれば、Route53上でサブドメインの発行も可能なので、「この証明書に別の名前を追加」を選択し、*.example.comのような、（アスタリスク）をつけたドメインも追加しておく
検証方法は「DNS 検証 – 推奨」を選択
キーアルゴリズムは「RSA 2048」を選択
「リクエスト」を選択

証明書の一覧で先ほど作成した証明書のステータスが「保留中の検証」となっているので、「Route 53 でDNS レコードを作成」を選択

先ほど設定したドメインと、*（アスタリスク）を含むサブドメインにチェックが入っているのを確認して「レコードを作成」を選択

レコード作成が正しく処理されると、ACMによって追加された証明書のCNAMEレコードが追加されるはずなので、Route53に登録しているドメインのレコードを確認。

証明書の発行は数分で完了する。
改めて証明書を確認し、ステータスが「発行済」または「成功」になっていればOK
※「保留中の検証」から進まない場合、ドメインのレコードに証明書のCNAMEレコードを追加していない可能性があるので、まずはそこを確認

ELB（ロードバランサー）

Elastic Load Balancingの略。
サービスにアクセスが集中すると、サーバーの処理能力が低下して、最悪ダウンしてしまいます。
その時に、サーバーへの負荷を分散させる役割を果たすのがロードバランサーの目的です。

ロードバランサー使用時はIPでのサイト確認はできない。
FQDN名（ホスト名 + ドメイン名）で、アクセスする必要がある。

ELBを使用することで下記のようなメリットも発生する

自動的にShield（Ddos対策）も無料で付いてくる。
レスポンスの高速化
→　ALBで処理する事でEC2サーバーまでリクエストが飛ばないので、その分レスポンスが早くなる
セキュリティの向上・サーバーの負荷軽減
→　リクエストがEC2サーバーまで届かないので攻撃の回数や、EC2サーバー側での処理が減る

ただし、下記のようなデメリットも存在する

コストアップ
→　ALBのサービス分、費用が高くなる。トラフィックやデーター転送量によって変わる従量課金制
複雑な処理はできない
→　httpからhttpsのような単純なリダイレクトは可能だが、「old」のディレクトリがつくURLを「new」にリダイレクトするなどはできない。Apacheやnginx側での処理が必要

ターゲットグループを作成

検索窓で「ec2」を検索
「ターゲットグループ」を選択
「ターゲットグループの作成」を選択

ヘルスチェックプロトコルは「HTTP」を選択
ヘルスチェックパスは任意のパスを選択
※トップページをヘルスチェックに使用するなら「/」のままでOK
※ただし、wordpressの場合、トップページを指定する事は出来ない（wordpressの仕様として、index.phpからリダイレクトが発生するため、意図したチェックを実行できないため）
ヘルスチェックの詳細設定はデフォルトのままでOK
デフォルトの指定だと、上記で指定したパスのURLが200のレスポンスを返してきていたら、正常に動いていると判断するという設定。
「次へ」を選択

ターゲットとして向けるEC2インスタンスにチェックを入れ、「保留中として以下を含める」を選択
ターゲットを確認の欄に、選択したEC2インスタンスが表示される。
「ターゲットグループの作成」を選択

AWS&Shield

WAFの基本的な立ち位置としては、おまけのセキュリティ対策。
基本的にはアプリケーション側でセキュアな対応をするのがベストプラクティス。
WAFでのセキュリティ対策は、つぎはぎだらけのパッチ対策のようなもの。
WAFを入れる事で、強靭なセキュリティ対応になるというものではない。

また、正当なWebアクセスが、ある日突然、WAFによりブロックされるようになる事態もあり得うる。
そんなときはWAFコンソールからどのルールがブロックしているかを確認して、
除外の設定などを行う必要がある。
https://www.k-friendly.com/10374
https://www.sprocket.bz/blog/20220624-waf.html

WAFの誤検知は主に、フォームの入力時に発生する。
そのため、入力フォームでの事前確認も必要。

運用の取り決め

WAF運用体制にも事前の取り決めが必要。
WAFでの検知についてどのように対応するのかを決めておく（どれくらいの頻度で対応するのか、どのような対応をするのかなど）
※なぜなら、WAFに誤検知はつきもののため、クライアントによっては細かな対応を求めてくるかもしれないから。

クライアントによっては誤検知発生を直ちに検知して、それを精査するような運用が必要になってくるかもしれない（攻撃ではなく、誤検知であれば、誤検知を解除する設定が必要になる）
メールもしくはslackで通知を受け取れるようにしておき、誰かがそのアラートを精査する運用というのが、セキュリテイ対策および、誤検知にサイトブロック対策に必要とされる。

WAFブロックページをカスタイマイズして、問題が発生した場合の連絡先を記載しておく手はよくある
https://dev.classmethod.jp/articles/aws-waf-custom-response_bodies_html/

basic認証

WAFの設定でBASIC認証を設定する事ができる。
https://dev.classmethod.jp/articles/aws-waf-basic-auth/

IP制限

WAFの設定でIP制限を設定する事ができる。
https://dev.classmethod.jp/articles/how-to-use-aws-waf-v2-to-filter-incoming-traffic-based-ip-address/

wordpress運用時のマネージドルール

WAFは基本的にパターンごとに用意されているマネージドルールを適用するして運用する。
AWSの場合、ある程度無料で提供してくれているマネージドルールもあるが、サードパーティーが作成している有料のマネージドルールも存在する。
https://zenn.dev/jins/articles/c10fed5a57fc61
https://www.k-friendly.com/10374
　→どのルールを当てるか参照がしやすい
https://www.wafcharm.com/jp/blog/aws-waf-managed-rules/

管理画面の更新を攻撃と勘違いして、WAFが動作し、wordpressの更新が出来なくなったことがあった。
そのため、管理画面からの接続は除外しておく必要がある。

jasso運用時に最終的に適応していたルール

AWS-AWSManagedRulesCommonRuleSet
AWS-AWSManagedRulesKnownBadInputsRuleSet
AWS-AWSManagedRulesLinuxRuleSet
AWS-AWSManagedRulesPHPRuleSet
AWS-AWSManagedRulesUnixRuleSet
AWS-AWSManagedRulesSQLiRuleSet
AWS-AWSManagedRulesWordPressRuleSet

※jasso運用時、下記のルールは誤検知を起こしたため削除したが、セキュリティ的にはあっても良かった

AWS-AWSManagedRulesAdminProtectionRuleSet
AWS-AWSManagedRulesAmazonIpReputationList
AWS-AWSManagedRulesAnonymousIpList

RDS

AWSでDBを扱うのであれば、RDSを使用するのがおすすめ。
利用は有料。

EC2サーバーにmysql等のミドルウェアを入れてDBを運用する事も可能だが、
保守・セキュリティ・スケーラビリティ・バックアップ等の面からハードルが高い。

その点、RDSはAWSのマネージドサービスのため、
導入までに必要なタスク(OS、ストレージ、ネットワーク等の物理インフラの管理、ミドルウェアの導入、パッチ適用等)は、全てAWSによって管理、実行され、利用者側はDBの運用管理に手間をかけることなくDBを扱うことができる。
また、バックアップやマルチAZ化による冗長性、スペックやストレージのスケールアップなど、運用の状態によってさまざまなサービスを管理画面から簡単に扱う事が出来るようになる。

セキュリティグループの作成

検索窓で「EC2」と検索
「セキュリティグループ」を選択
「セキュリティグループを作成」を選択

セキュリティグループ名は分かりやすい任意の名前を入力
説明は、作成するセキュリティグループの簡易説明を任意で入力
VPCはRDSを紐づけるEC2インスタンスと同じVPCを選択

インバウンドルールを追加
タイプは「MYSQL/Aurora」を選択
ソースは「カスタム」を選択し、使用するEC2インスタンスにアタッチしているセキュリティグループと同じセキュリティグループを選択
※ec2インスタンスのIPを個別に設定する事も出来るが、その場合、再起動によりIPが変わったり、接続先が複数あったりした場合複数設定したりと管理が大変になる。

アウトバウンドルールはデフォルトのままでOK
最後に「セキュリティグループを作成」を選択

サブネットグループの作成

RDSを作成するには、シングル-AZ構成 / マルチ-AZ構成関係なしに2つ以上の異なるAZでサブネットを作成し、それを基にサブネットグループを作成する必要がある。

検索窓で「rds」を検索
「サブネットグループ」を選択
「DB サブネットグループを作成」を選択

名前は分かりやすい任意の名前を入力
説明は、作成するサブネットグループの簡易説明を任意で入力
VPCはRDSを紐づけるEC2インスタンスと同じVPCを選択

アベイラビリティーゾーンはVPCを作成する際に指定したAZを選択

サブネットはVPCを作成する際に、それぞれのAZで作成したプライベートサブネットを選択

指定内容を確認し、問題なければ「作成」を選択

パラメータグループの設定

RDSではDBの設定ファイルを直接編集できないので、
DBパラメータグループを設定することで設定ファイルを編集出来るようにする。

検索窓で「rds」を検索
「パラメータグループ」を選択
「パラメータグループの作成」を選択

パラメータグループ名には分かりやすい任意の名前を入力
※今回はRDSをmysqlのバージョン8で作成しようとしているため、「db-mysql-8-0」と入力
説明は分かりやすい任意の説明を入力
エンジンのタイプは「MySQL Community」を選択
※今回はRDSをMySQLで作成するため
パラメータグループファミリーは「mysql8.0」を選択
※RDSで作成するDBエンジンや、その時の主要バージョンに沿った内容を選択
タイプは「DB Parameter Group」を選択
※基本は「DB Parameter Group」でOKだが、
DBを「Multi-AZ DB Cluster」で作成したいなら、「DB Cluster Parameter Group」を選択。
「作成」を選択

パラメータの変更

上記の設定は基本のパラメータ設定となります。
パラメータの調整が必要な場合、作成後に調整が必要なパラメータを編集してください。

左図のようなパラメータを調整可能
※DBパラメータを変更したときに、
staticの場合はRDSインスタンスの起動後に変更が反映され、
dynamicの場合は動的に変更が反映されることを表しています。

オプショングループの作成

RDSではDBの設定ファイルを直接編集できないので、
DBパラメータグループを設定することで設定ファイルを編集出来るようにする。

検索窓で「rds」を検索
リージョンの確認
「オプショングループ」を選択
「グループを作成」を選択

名前は分かりやすい任意の名前を入力
例：db-optoin-mysql-8-0
エンジンは「myql」を選択
※今回はMySQLのver8を使用する予定なので
メジャーエンジンバージョンは「8.0」を選択

作成するとデフォルトのオプショングループも作成されますが、デフォルトのオプショングループは、削除も修正も出来ないので基本的に使わない

データベースの作成

検索窓で「rds」を検索
右上のリージョンが意図しているリージョンになっているか確認
「データベースの作成」を選択

「標準作成」を選択

エンジンのタイプは「MySQL」を選択
※要件にあったDBを選択する
エディションの確認
エンジンバーションは「MySQL 8.0.40」を選択
※要件にあったバージョンを選択する。
今回はwordpressを前提とするため、MySQL8以上ならOK（2025年2月時点の最新のwordpressの要件）

テンプレートは要件に近いのを選ぶ
※この後に選択するインスタンスの設定でAWS側がサジェストしてくるプランが変わるだけなので、どれでも特に差はない
可用性と耐久性は「マルチ AZ DB インスタンス」を選択
※要件によって選択。
基本的に、「単一＜マルチAZ インスタンス＜マルチAZ クラスター」の順番で冗長性が高い。

DB インスタンス識別子は分かりやすい任意の名称を入力
※例：dev-rds-mysql
マスターユーザー名にadminは使用しない。推測しにくい任意のユーザー名を入力
※例：devmasteruser
認証情報管理は「セルフマネージド」を選択
「パスワードを自動生成」にチェックを入れる

インスタンスは要件にあったインスタンスを選択

ストレージタイプは「汎用SSD（gp3）」を選択
ストレージ割り当ては要件にあった内容にする
追加のストレージ設定は「ストレージの自動スケーリングを有効にする」にチェック。
最大ストレージしきい値（自動でどこまで容量を拡張するか）はデフォルトの1000GBで問題ないが、要件に合わせて確認。
※際限なく容量を拡張してしまうと、料金が高くなるため注意が必要

コンピューティングリソースは「EC2 コンピューティングリソースに接続しない」を選択
ネットワークタイプは「IPv4」を選択
Virtual Private Cloud (VPC)はDBインスタンスを作成するVPC（EC2インスタンスと同じ）を選択
DB サブネットグループは、「サブネットグループの作成」で作成したDB用のサブネットグループを選択
パブリックアクセスは「なし」を選択
※「なし」にする事で外部のインターネットからの接続は不可になるのでセキュリティは高くなる。
外部から（VPCの外）接続する必要があるのであれば、「あり」にする。

VPC セキュリティグループ (ファイアウォール)は「既存の選択」を選択
既存の VPC セキュリティグループは「セキュリティグループの作成」で作成したセキュリティグループを選択
残りは左図の通り、デフォルトの内容でOK

データベース認証オプションは「パスワード認証」を選択

RDSインスタンスの詳細をモニタリングしたい場合、「拡張モニタリングの有効化」にチェック
※ただし、追加で料金が発生するようになる
設定は左図の通りデフォルトの値でOK

※基本モニタリングは無料で行われており、そこで重要なメトリクスは提供されている。そのため、拡張モニタリングは必須ではなく、要件による。
要件に細かな監視が無いのであれば「拡張モニタリングの有効化」は不要かも。

最初のデータベース名は空でもOK
※後から作成したDBに対しても、ここで設定する内容は反映される
DB パラメータグループは「パラメータグループの設定」で作成したグループを選択
オプショングループは「オプショングループの作成」で作成したグループを選択
「自動バックアップを有効にします」にチェックを入れる
バックアップ保持期限、実行時間等は要件に合わせる。
※「期限」はバックアップが実行される時間帯のしきい値のようなもの。
例：「開始時間」 0時で「期間」0.5時間の場合、
　　0時～0時30分の間でバックアップの処理が走る
「スナップショットにタグをコピー」にチェックを入れる
「バックアップレプリケーション」はチェック無しでOK

「暗号を有効化」にチェックを入れる
AWS KMS キーは「KMSのマネージド型キーを作成しESBの暗号化用キーを作成する」で作成したものを選択

ログのエクスポートは全てチェック無しでOK
※ただし、cloud watchを使った分析や詳細ログを長く保管しておきたい場合は、チェックを入れる。
要件による。

「マイナーバージョン自動アップグレードの有効化」にチェックを入れる。
メンテナンスウィンドウに任意の時間を指定
※週次で行われるDBインスタンスのメンテナンス時間を指定。指定しない場合は、AWSによってランダムに行われるため、サイト運用に支障がでるかもしれないから、影響の少ない時間帯を選択。

概算月間コストを確認し、問題なければ「データベースの作成」を選択

「データベースの作成」を選択すると画面が遷移する。データベース作成時、「パスワードを自動生成」にチェックを入れていた場合、「認証情報の詳細の表示」を選択

ポップアップで表示される「マスターパスワード」を確実にメモしておく
※ここでメモし忘れてしまうと、
再度RDSインスタンスを変更してパスワードを新しく作成する必要がある。

EC2からRDSに接続

SQLクライアントのインストール

EC2インスタンスにSSH接続して、下記のコードを実行

sudo yum -y install mysql

SQLクライアントをインストールのため、左記のコードを実行

RDSコンソールから、作成したRDSの「エンドポイント」をコピー

mysql -u devmasteruser -p -h dev-rds-mysql.cbqo0owemr5z.ap-northeast-1.rds.amazonaws.com

EC2インスタンスから、RDS MySQL（サーバー）に接続するため、左記のコードを実行
-u = ユーザーID
-h = 接続するホスト(エンドポイント)
パスワードの入力を求められたら、RDS作成時に作ったマスターパスワードを入力

左図のような接続完了コメントが表示されればOK

SHOW DATABASES;

接続確認のため、左記コードにて存在するDBを表示
下記のように、DBが表示されればOK

【ログインがうまくいかない場合】

作成したRDSのステータスは、利用可能状態か？

セキュリティグループやVPCは、正しく設定されていますか？
┣ セキュリティグループ：Webサーバーからのアクセスを有効にしているか確認
┗ VPC：Webサーバーと同じVPCにいるか確認

RDSを作成する際に指定したユーザーIDでログインしているか？

入力したパスワードは、正しいか？
パスワードが分からない場合は、下記手順にて再度設定

RDSインスタンスを選択し、「変更」を選択

「セルフマネージド」を選択
マスターパスワードを入力
「続行」を選択

「DBインスタンスを変更」をクリック
※基本的に即時反映

wordpress用のDBの作成

SSHでRDSに接続した状態で下記のコマンドを実行

CREATE DATABASE db_name CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

赤文字のDB名は推測されにくい任意の名称を入力

CREATE USER 'new_user'@'localhost' IDENTIFIED BY 'password';

DBにアクセスする新規DBユーザーを作成
赤文字のDBユーザー名、
パスワードは推測されにくい任意の名称を入力

GRANT ALL PRIVILEGES ON db_name.* TO 'new_user'@'localhost';

上記で作成したDBとユーザーの紐づけ
db_name = 作成したDB名
new_user = 作成したDBユーザー名

FLUSH PRIVILEGES;

上記の処理内容をDBに反映

wordpessのインストール

DBの接続以外は他のVPS環境にwordpressをインストールするのと同じ

ルートディレクトリに移動

cd /usr/share/nginx/html

デフォルトのnginxのファイルを全て削除

sudo rm -rf *

curlコマンドでwordpressをダウンロード

sudo wget https://ja.wordpress.org/latest-ja.zip

tarコマンドでダウンロードしたファイルを解凍

sudo tar zxvf latest.tar.gz

不要なファイルの削除

sudo rm latest.tar.gz

wordpessのディレクトリ名を変更（wordpress → wp）

sudo mv wordpress wp

ドキュメントルート配下の全ファイル/全ディレクトリのオーナーをnginxユーザーに、
グループをnginxグループに変更

sudo chown -R nginx:nginx /usr/share/nginx/html/

ドキュメントルート自体を含む、配下の全ディレクトリに以下の権限を設定
オーナー : 読み取り、書き込み、実行
グループ : 読み取り、書き込み、実行
他ユーザー: 読み取り、実行

sudo find /usr/share/nginx/html/ -type d -exec chmod 775 {} \;

ドキュメントルート配下の全ファイルに以下の権限を設定
オーナー : 読み取り、書き込み、実行
グループ : 読み取り
他ユーザー: 読み取り

sudo find /usr/share/nginx/html/ -type f -exec chmod 644 {} \;

wordpessのファイルがあるディレクトリに移動

cd wp

wp-config-sample.phpをコピーしてwp-config.phpを作成

sudo cp -p wp-config-sample.php wp-config.php

この記事を書いた人

姉川寛生

AWSについて

初期設定

セキュリティ設定

IAMの設定

IAMパスワードポリシーを強化

Security Token Service (STS)を東京リージョン以外は無効にする

IAMグループを作成

IAMユーザーを作成

支払い通貨をドルから日本円へ変更

代替の連絡先

Cost Management（コスト管理）の設定

コストエクスプローラーの有効化

予算の作成

AWS CloudTrailを設定

実際の画面

AWS環境の構築イメージ

VPC

サブネットとは

ルートテーブルとは

インターネットゲートウェイとは

上記を踏まえたVPCの構築イメージ

構築ステップ

VPCの一括作成

EC2

EC2の構築イメージ

構築ステップ

KMSのマネージド型キーを作成しESBの暗号化用キーを作成する

インスタンスの作成

EC2にSSH接続する

Elastic IP アドレスの割当

Elastic IP アドレスの解放

EC2インスタンスの停止

ミドルウェアのインストール

NginxとPHPインストール

Nginx設定

① client_max_body_size

② try_files

③ error_page 404

■ 編集前

■ 編集後

PHP設定

① post_max_size

② upload_max_filesize

PHP-FPM設定

OOM Killer対策：PHP-FPMチューニング

NginxとPHP-FPMのサービス起動

NginxとPHP-FPMのログ関連のオーナーとパーミッション変更

PHP接続確認

ミドルウェアのサービス自動起動設定

独自ドメインの追加

今回のNSレコードの設定で詰まった事

ACM（SSL証明書）

ELB（ロードバランサー）

ターゲットグループを作成

AWS&Shield

運用の取り決め

basic認証

IP制限

wordpress運用時のマネージドルール

jasso運用時に最終的に適応していたルール

RDS

セキュリティグループの作成

サブネットグループの作成

パラメータグループの設定

パラメータの変更

オプショングループの作成

データベースの作成

EC2からRDSに接続

SQLクライアントのインストール

【ログインがうまくいかない場合】

wordpress用のDBの作成

wordpessのインストール

この記事を書いた人

関連記事