はじめに
クラウドソーシングを活用してマーケティングサイトを作ることになりました。
マネージメントしてくれる方に相談してみると、サイトの構築を行ってくれるエンジニアの割合として、WordPressだと安定して見つかるということで、今回はサーバーレスではなく、サーバーありのシステムになりました。
当面はクラウドソーシングの方々にお任せするということですが、当然、オーナーは当社なので契約や支払が発生しますし、セキュリティや運用も考えると、現在の開発と本番で活用しているAWSでなんとかしたい。コストや可用性を考えた結果、Lightsailで以下のような構成にすることにしました。
準備
主役は、Lightsail WordPressで、実際には、WordPressを入れてから試行錯誤したのですが、できるだけ手戻りなく、再現可能な手順として残すことにします。
Amazon Organizations
AWSアカウントは、AWSとの契約の単位と考えると良いと思います。AWSとの契約の単位なので、AWS資産のオーナーであり、請求先になります。
ですから、開発と本番を別のAWSアカウントにしておけば、開発だと思って、うっかり本番を更新するようなリスクを低減することができますし、開発は研究開発費、本番は製造原価の支払手数料としたいという場合もAWSアカウントの役割を経理担当者が知っていれば正しく計上してもらえます。
といっても、請求書がバラバラに送られてきて全部揃ったかどうかわからなくなったり、契約の一覧が管理できないのも困ります。Amazon Organizationsでこれらの問題は解決できます。（しばらく見ない間に機能が増えていたので、また勉強しておきます）
今回は、外部の方に操作して頂くので、セキュリティ面からも会計面からも独立したAWSアカウントをAmazon Organizationsから作成しました。
S3
地味ですが、AWSの成功の最大の要因の一つはS3だと思います。今回もお世話になります。
今回は、WordPressの可用性向上のため、ロードバランサーによる多重化を行います。このためコンテンツを保持するファイルシステムとデータベースを共有することにします。（WordPressについては、入門書の一夜漬けですが）画像や動画を保持するファイルシステムをS3に代替することによって共有化だけでなく、信頼性も向上し、さらにこれをCloudFrontにキャッシュすることで、WordPressの負荷低減とダウンロードの高速化ができ（るそうなのでがんばり）ます。
WordPressからS3を使うために、WP Offload Media Liteを使いました。このプラグインを使った構築を説明しているページの多くは公式を含めて、「パブリックアクセスを許可しろ」とか「AmazonS3FullAccessを付与しろ」とか「マジか…」な説明が多かったのが、この記事を書いた理由の一つでもあります。
S3のセキュリティがガバガバな説明が多いのは、CloudFrontを使っていないからです。CloudFrontを使うのであれば、デフォルトのとおり「パブリックアクセスをすべてブロック」でバケットを作るだけでOKです。
AWS Certificate Manager
最近は、HTTPとHTTPS混在にすると、ブラウザがいろいろと余計なお世話をしてくれるますし、利用者の安全を確保するため、独自ドメインとそのサーバー証明書で安全なHTTPSによって公開します。
CloudFront用の証明書は「バージニア北部」で取得しましょう。DNS検証にしてRoute53に表示されたCNAMEを登録すると検証されます。
CloudFront
当社のSaaSもS3をCloudFrontで公開しているのですが、最初に設定した2019年か2020年当時は、設定がとても面倒だった記憶があります。しかしながら、今では、設定ページも日本語化されていますし、日本語で説明したページも多いので、それほど難しくないと思います。
「ディストリビューションを作成」するのですが、S3オリジンにするには、「オリジンアクセス」をOrigin access Control settingsにして「コントロール設定を作成」します。「WAF」と「設定」は後でもできのでお好みで良いですが、上のACMで証明書を作った方は、「代替ドメイン名」と「カスタムSSL証明書」を設定します。
ディストリビューションの作成が完了するタイミングで、S3用のバケットポリシーも作成してくれるので、ありがたくコピーして、S3のバケットのアクセス許可からパケットポリシーへ行って貼り付けます。
こんな感じのパケットポリシーになります。
{
"Version": "2008-10-17",
"Id": "PolicyForCloudFrontPrivateContent",
"Statement": [
{
"Sid": "AllowCloudFrontServicePrincipal",
"Effect": "Allow",
"Principal": {
"Service": "cloudfront.amazonaws.com"
},
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::■■■■■■/*",
"Condition": {
"StringEquals": {
"AWS:SourceArn": "arn:aws:cloudfront::■■■■■■:distribution/■■■■■■"
}
}
}
]
}
IAM
WP Offload Media Liteは、IAMユーザー権限でS3に接続するので、「AWSマネジメントコンソールへのユーザーアクセスを提供する」をOFFにしたユーザーを作成します。
その前に、以下のような「AmazonS3FullAccess」でない限定されたポリシーを作成しておきます。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject",
"s3:DeleteObject"
],
"Resource": "arn:aws:s3:::■■■■■■/*"
},
{
"Sid": "VisualEditor1",
"Effect": "Allow",
"Action": [
"s3:GetBucketPublicAccessBlock",
"s3:ListBucket",
"s3:GetBucketLocation"
],
"Resource": "arn:aws:s3:::■■■■■■"
},
{
"Sid": "VisualEditor2",
"Effect": "Allow",
"Action": "s3:ListAllMyBuckets",
"Resource": "*"
}
]
}
昔からできたかどうか記憶が定かでないのですが、今はグループ経由ではなくポリシーを直接ユーザーに付与することもできるので、今回のような権限範囲が特殊なユーザーは書き換えられる恐れが少ないグループなしが良さそうです。
このユーザーの「セキュリティ認証情報」から「アクセスキーを作成」しておきます。この値を後でWordPressに設定します。
SES
メールです。これまでも後になってから「お問い合わせフォームからのお問い合わせは、どこにお知らせしますか？」など聞かれて「最初から言ってよ」となることがありましたので、今回は予め準備しておきます。
SMTP設定から「SMTP認証情報の作成」をしますが、ここでIAMに切り替わりますので、IAMでユーザー登録できるユーザーで操作してください。
ここで表示される「SMTP ユーザー名」と「SMTP パスワード」は、後ほどWP Mail SMTPに設定するのでcsvファイルをダウンロードするなどして残しておいてください。この「SMTP ユーザー名」はIAMの「アクセスキー」ですが「SMTP パスワード」は「シークレットアクセスキー」ではありません。
ご参考までに、このユーザーの権限は以下のとおりです。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ses:SendRawEmail",
"Resource": "*"
}
]
}
最初に設定した2019年か2020年当時は、まだ東京にはSESがなくてバージニア北部に作りましたが、今では東京でできます。良い時代になったものです。
ただ、この過去の遺物が設定されているAWSアカウントを見ながら、ロールの切り替えしながら設定したためSESがバージニアで、SESから飛んだIAMがグローバルでIAMの画面を見ながら、一生懸命コピペを繰り返して、３時間ほどロスしました。ご注意ください。また、「SMTP パスワード」が「シークレットアクセスキー」ではないことは、ここからもわかります。
おわりに
ここまでマーケティングサイトの基礎となる環境を構築してきましたので、次回は、いよいよマーケティングサイトを構築します。
Discussion