こんにちは、akiyoko です。
Mezzanine は Python製の WordPress風フルスタックCMSフレームワークですが、個人的にブログサイト（将来的には ECサイトを増設予定）を本番運用するために、昨年12月頃から調査をしてきました。
それ以来いろいろと企画やら調整を地道に進めてきましたが、この 7月にようやく本番運用に漕ぎ着けることができました。
それを記念して（？）AWS の初期設定から Mezzanine の本番デプロイ、ちょっとした運用設定までの記録を一旦ここでまとめておきたいと思います。
かなり長くなるので、
の 4本に記事を分けました。
今回はその 1本目、「その１：AWS 環境構築」について説明します。
AWS 環境構築として実施した内容としては、
- IAM 設定（ルートアカウント・admin ユーザの設定）
- VPC 設定（1ネットワーク＋ 1サブネット）
- EC2 設定（Ubuntu 14.04 LTS インスタンスの起動）
- Amazon SES 設定（ドメイン認証、送信制限の解除申請）
となります。
1. IAM の初期設定
基本方針として、AWS ルートアカウントは原則使用せず、AdministratorAccess 権限を持たせた管理者ユーザー「admin」を新たに作成して利用することとします。
なお、ルートアカウントは、MFA（二段階認証）でセキュリティを強化しておきます。
（参考）
- AWSアカウントを取得したら速攻でやっておくべき初期設定まとめ - Qiita
- AWSアカウントを取得してから行う初期設定 - Qiita
- AWSアカウントを取得したら速攻でやっておくべき初期設定まとめ - Qiita
- AWS 権限管理のベストプラクティスについて考えてみた | はったりエンジニアの備忘録
1. 1. ルートアカウントに MFA 導入
1.1.1. スマホに仮想MFAアプリケーションをインストール
まず、Android に
- Google 認証システム（下表の「Google Authenticator」）
- QRコードスキャナー（1.1.2. の手順で必要）
というアプリをインストールします。
なお、仮想MFA アプリケーションの一覧はこちらです。
私は Android ユーザなので Android を使っていますが、その他のスマホを使っている場合は適宜別のアプリを検討してください。
| Android | Google Authenticator、Authy 2 段階認証 |
| iPhone | Google Authenticator |
| Windows Phone | Authenticator |
| Blackberry | Google Authenticator |
（IAM - Multi-factor Authentication より）
1.1.2. AWS Management Console での設定
[IAM] > [Dashboard] から、[Security Status] > [Activate MFA on your root account] > [Manage MFA] を選択します。
[A virtual MFA device]（仮想 MFA デバイス）を選択。
[Don't show me this dialog again] を選択して次へ。
以下の QRコードを 1.1.1. でインストールした「Google 認証システム」アプリでスキャンして、アプリをルートアカウントと紐付けます。
これで、AWS ルートアカウントでのログイン時にアプリで払い出されるワンタイムトークンが必要になるため、不正ログインに対するセキュリティが向上します。
1.2. パスワードポリシーの変更
[Dashboard] から、[Security Status] > [Manage Password Policy] をクリックします。
ここで、パスワードポリシーを
- パスワードの最小長：8
- 英大文字、英小文字、数字の組み合わせ
- ユーザーにパスワードの変更を許可
とします。
有効期間、再利用禁止などのポリシーは今回設定していませんが、ニーズがあり次第、適宜設定することとします。
1.3. IAMユーザ、IAMグループの管理
1.3.1. IAMユーザ作成
管理者ユーザ「admin」を作成します。
アクセスキーを CSV（credentials.csv）でダウンロードしておきます。
User Name,Access Key Id,Secret Access Key "admin",AKIxxxxxxxxxxxxxxxxx,xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
次に、作成したユーザの [Security Credentials]（認証情報）タブから、自動作成パスワードを払い出して設定します。
［Manage Password］をクリック。
「Assign an auto-generated password」をチェックして、［Apply］をクリック。
念のため、パスワードを CSV（admin_pass_credentials.csv）でダウンロードしておきます。
User Name,Password,Direct Signin Link "admin",xxxxxxxxxxxx,https://53xxxxxxxxxx.signin.aws.amazon.com/console
なお、adminユーザには二段階認証は設定しません。 *1
1.3.2. IAMグループ作成
adminユーザのための管理者グループ「admin」を作成します。
完全な管理者アクセス権限（AdministratorAccess）ポリシーをアタッチします。
次に、admin グループに admin ユーザを追加します。
作成したグループを選択して、「Add Users to Group」をクリック。
追加したいユーザ（ここでは「admin」）を選択して、「Add Users」をクリック。
1.3.3. admin で再ログイン
以下、adminユーザで操作します。
一旦ログアウトし、
https://{AWS Account ID}.signin.aws.amazon.com/console
から、admin ユーザでログインします。なお、「AWS Account ID」は、AWSアカウントに紐づく 12桁の数字で、My Account ページの［Accout Settings］からも確認できます。
ログインしたら、リージョンを「Tokyo」にしておきます。
2. VPC の初期設定
以前に書いた 「AWS体験ハンズオン ～セキュア&スケーラブルウェブサービス構築～」に参加してきました - akiyoko blog で実現したような、
- 別アベイラビリティゾーンに Webサーバを冗長構成して、ELB を使ってロードバランシング
- プライベートなサブネットに RDS を配置（且つ、別アベイラビリティゾーンにレプリケーション）
は行わず、最小限の構成にしています。
今回構築する構成の最終形は、このようになります。
2.1. VPC の作成
CIDR が「10.0.0.0/16」の VPC を作成します。
[VPC] > [Your VPCs] から、「Create VPC」ボタンをクリック。
以下を設定します。
| Name tag | P1 |
| CIDR block | 10.0.0.0/16 |
| Tenancy | Default |
【注意】
このままの設定では、あとでインスタンスを起動して sudo を実行した際に、下記のエラーが出るので（コマンド自体は実行されているっぽい）、DNS Hostnames の設定を「Yes」に変更します。（すでに EC2インスタンスを起動していた場合には、再起動が必要です。）
$ sudo ls sudo: unable to resolve host ip-10-0-0-80
（参考）amazon web services - AWS error - sudo: unable to resolve host ip-10-0-xx-xx - Stack Overflow
2.2. Subnet の作成
CIDR が「10.0.0.0/24」のサブネットを作成します。
[Subnets] から、「Create Subnet」ボタンをクリック。
以下を設定します。
| Name tag | P1 Public #1 |
| VPC | P1 |
| Availability Zone | ap-notrtheast-1a |
| CIDR block | 10.0.0.0/24 |
2.3. Internet Gateway の作成
インターネットゲートウェイを作成します。
[Internet Gateways] から、「Create Internet Gateway」ボタンをクリック。
名前を「P1 Public #1」に設定。
作成した Internet Gateway を選択して「Attach to VPC」ボタンをクリックし、作成した VPC を選択して、Internet Gateway を VPC に紐付けます。
[Route Tables] から、作成した VPC の Route Table を選択して、Routes を編集します。
以下を設定します。
| Destination | 0.0.0.0./0 |
| Target | 作成した Internet Gateway を選択 |
これで VPC の設定は完了です。
3. EC2 インスタンスの起動
3.1. SSH鍵の作成
まず、SSH鍵を作成します。
[EC2] > [Key Pairs] から、「Create Key Pair」をクリック。
キーペア名は、「aws_p1」としました。
作成すると、自動的に鍵がダウンロードされます。
ダウンロードした SSH鍵を .ssh 以下に配置します。
（以下の操作は Mac を想定しています。）
$ mv ~/Downloads/aws_p1.pem ~/.ssh/
$ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/aws_p1.pem
$ ls -l@ ~/.ssh/aws_p1.pem
-rw-------@ 1 akiyoko staff 1696 6 5 17:35 /Users/akiyoko/.ssh/aws_p1.pem
com.apple.metadata:kMDItemWhereFroms 199
com.apple.quarantine 68
$ xattr -d com.apple.metadata:kMDItemWhereFroms ~/.ssh/aws_p1.pem
$ xattr -d com.apple.quarantine ~/.ssh/aws_p1.pem
$ ls -l@ ~/.ssh/aws_p1.pem
-rw------- 1 akiyoko staff 1696 6 5 17:35 /Users/akiyoko/.ssh/aws_p1.pemここで、ダウンロードした際によく分かんない attribute（Extended Attributes と言うものらしい）が付いてしまっているので、削除しています。
（参考）EA (Extended Attributes) の消し方
3.2. EC2インスタンス用の Security Group 作成
EC2インスタンスに付与する Security Group を作成します。
以下を設定します。
| Security group name | P1 Webserver #1 |
| Description | P1 Webserver #1 |
| VPC | P1 |
| Type | Protocol | Port Range | Source |
| SSH | TCP | 22 | My IP |
| HTTP | TCP | 80 | My IP |
| HTTPS | TCP | 443 | My IP |
3.3. EC2 インスタンス用の IAM Role の作成
EC2インスタンス作成時に IAM Role を設定して起動するため、先に作成しておきます。
IAM Role の名前は「ec2-prod」（本番 EC2インスタンス用の Role という意味）としておきます。
「Role Type」は「Amazon EC2」を選択。
完全な管理者アクセス権限（AdministratorAccess）ポリシーを選択します。
「Create Policy」をクリックして、IAM Role の作成は完了です。
3.4. EC2インスタンスの起動
EC2インスタンスを起動します。
「Ubuntu Server 14.04 LTS」を選択。
インスタンスタイプは（必要に応じていつでもスケールアップできるので、最初は）「t2.micro」でよいでしょう。
以下を設定します。
| Network | P1 |
| Subnet | P1 Public #1 |
| IAM role | ec2-prod |
| Enable termination protection | 「Protect against accidental termination」にチェック |
インスタンス名を「P1 Webserver #1」とします。
3.2. で作成した Security Group を設定します。
3.1. で作成した SSH鍵を設定して、インスタンスを起動します。
3.5. Elastic IP の紐付け
最後に、起動した EC2インスタンスに Elastic IP を紐付けます。
［Elastic IPs］>［Allocate New Address］をクリック。
「Yes, Allocate」をクリックして、Elastic IP を払い出します。
払い出した Elastic IP を選択し、［Actions］>［Associate Address］をクリック。
3.4. で起動したインスタンスを選択して「Associate」をクリックし、Elastic IP を紐付けます。
ここで念のため、疎通確認しておきます。
$ ssh -i ~/.ssh/aws_p1.pem ubuntu@52.xx.xx.xx
4. SES の設定
最後に、メールの設定です。
なおここで、AWS 外のレジストラ（ここでは お名前.com）で独自ドメイン「akixxxx.com」を管理していることを前提しています。
まず最初に、Amazon SES は Tokyo リージョンでは対応していないため *2、「Oregon」リージョンに移動します。
4.1. ドメイン認証
［Domain］ > ［Verify a New Domain］でドメインを認証します。
Domain に「akixxxx.com」を指定します。
送信用の TXTレコードと受信用の MXレコードが表示されます。
4.2. 送信用 TXTレコードと受信用 MXレコード設定
レジストラ（お名前.com）上でドメインNavi にログインし、上記の送信用の TXTレコードと受信用の MXレコードを設定します。
［ドメイン設定］ > ［ネームサーバーの設定］>［DNS関連機能の設定］から、該当ドメインをチェックして「次へ進む」をクリック。
［DNSレコード設定を利用する］>［設定する］をクリック。
以下を設定します。
| ホスト名 | TYPE | TTL | VALUE | 優先 | 状態 |
| _amazonses.akixxxx.com | TXT | 3600 | （AWS Management Console の Domain Verification Record の値を貼り付け） | 有効 | |
| akixxxx.com | MX | 3600 | （AWS Management Console の Email Receiving Record の値を貼り付け） | 10 | 有効 |
なお、MXレコードの優先度は「10」にします（そのまま貼り付けるとダメ。「10」と「inbound-smtp.us-west-2.amazonaws.com」に分割する）。
2時間ほどすると、「Amazon SES Domain Verification SUCCESS」というメールが来ます。
ドメインのステータスが「verified」になっていることが確認できます。
4.3. SES 送信制限の解除申請
ステータスが「verified」になったら、「Request a Sending Limit Increase」の申請をします。
申請内容は以下の通り。
| Regarding（内容） | Service Limit Increase（サービス制限の増加） |
| Limit Type（制限タイプ） | SES Sending Limits（SES送信制限） |
| Region | US West (Oregon) |
| Limit | Desired Daily Sending Quota（希望する一日あたりの送信クォータ） |
| New limit value | 10000 |
| Mail Type（メールの種類） | System Notifications（システム通知） |
| Website URL | （メール送信を使用するシステムのURLを指定） |
| My email-sending complies with the AWS Service Terms and AUP（私は AWS サービス利用規約と AUP に準拠してメールを送信します） | Yes |
| I only send to recipients who have specifically requested my mail（私は明確にリクエストされた受信者にのみメールを送信します） | Yes |
| I have a process to handle bounces and complaints（バウンスや苦情を処理するプロセスがあります） | Yes |
| Use Case Description（申請理由の説明） | アカウント登録やパスワード変更など、システムを利用するユーザへの通知に利用します。メール送信は基本的にシステムからの自動送信となり、ユーザ自身が登録したメールアドレス宛に送信するため、バウンスはほとんど発生しません。予想されるユーザ数は当面のところ、○○程度と見込んでいます。（あくまでサンプルですので、状況に合わせて適宜書き直してください。） |
| Support Language | 日本語 |
| Contact method | Web（しか選択できません） |
6時間くらい後に承認メールが届きました。
Congratulations! After reviewing your case, we have increased your sending quota to 50,000 messages per day and your maximum send rate to 14 messages per second in AWS Region US West (Oregon). Your account has also been moved out of the sandbox, so you no longer need to verify recipient addresses.
AWS Management Console 上はこのようになっています。
（参考）Amazon SESによるメール送信環境の構築と実践 | Developers.IO
まとめ
今回、AWS 環境構築として、
- IAM 設定（ルートアカウント・admin ユーザの設定）
- VPC 設定（1ネットワーク＋ 1サブネット）
- EC2 設定（Ubuntu 14.04 LTS インスタンスの起動）
- Amazon SES 設定（ドメイン認証、送信制限の解除申請）
を実施した内容を記載しました。
次回は、Mezzanine 本番設定の第二弾として、「その２：Mezzanine テーマのカスタマイズ」について記載します。
参考本
AWS 関連で比較的新しくて良さげな本を紹介します。
Amazon Web Services 定番業務システム12パターン 設計ガイド
- 作者:川上 明久
- 発売日: 2016/06/15
- メディア: 単行本
*1:というか、1台のスマホにつき紐付けられるユーザは 1つだけなのかな？？
*2:「米国西部（オレゴン）」のほか、「米国東部（バージニア北部）」「欧州（アイルランド）」でも SES を利用できますが、今回は日本から物理的に一番近そうな米国西部を選択しました。（参考）https://docs.aws.amazon.com/ja_jp/ses/latest/DeveloperGuide/regions.html
東京リージョンに対応しました。（参考）Amazon SES 東京リージョン対応のお知らせ | Amazon Web Services ブログ
