- 概要
- 前提
- 独自ドメイン取得
- SSL準備(ACM)
- S3へバケット用意
- CloudFrontへS3ドメインを設定
- Route 53
- API Gatewayを独自ドメイン化
- 番外編：S3の独自ドメイン設定(CloudFront利用なしの場合)
- 番外編：間違ってACMをroot権限で作ってしまったら
- 番外編：Route 53/CloudFront/ACMの設定をしたはずなのにエラーが出る
- 総括
概要
AWSで独自のサイトを作る際に、申し込みフォームや会員サイトを作りたい場合、SSLが必要です。その手続をCloudFrontを用いて安めにやってしまいましょう。特にHTML等をS3に配備してそれをSSL化するなら、絶対必要です。本家に記載されているとおり、請求額は実際のCloudFrontの利用料金となります。非常にリーズナブルですね。ここではその設定方法を調査し、実際にやってみたのでまとめました。
前提
独自ドメイン名とそのサブドメイン名が共に決まっている前提ですすめます。
独自ドメイン取得
お名前.comやムームードメインで、これから制作するサイト用の独自ドメインを取得します。AWSで使うために必要です。
登録が完了したら、メールアドレス設定します。ここではお名前.comの例で説明します。
ドメインNaviにログイン(お名前IDはメールに記載)して、オプション設定から、左サイドメニューのレンタルサーバー→メール専用サーバーのお申込みからメールサーバ申し込みします。
その後サーバーNaviにログインし、画面左のサイドバーからご利用サービス確認を開きます。
すると共用サーバーの欄にコントロールパネルのリンクがあるのでログインします。
※コントロールパネルをブックマークして直接そこからログインしようとしても弾かれます。サーバーNaviにログインしてそこから移動しましょう。
コントロールパネルに移動したらメール設定→メールアカウントから
に記載されている5つのメールアドレスを登録します(黒塗りの部分が、申請した独自ドメイン)。
これでメールが届くようになりました。しかしいちいちここにログインしていたら面倒なので、gmailに転送するように設定しました。転送するにはメール設定→メール転送をクリック。↑で登録した5つのメールアドレスは転送状態が無効になっているので、アクションの変更ボタンをクリックして普段使っているメールアドレスを入力します。
転送出来ることを、実際に上記いずれかのメールアドレスにテストメールを送って自分に届くことでチェックすること。
ここまで問題なければACM申請に進みます。
SSL準備(ACM)
ACMの申請については事前に
ここを読み込んだ方がいいですね。証明書自体の料金は要らないらしい。
注意点として、この作業をrootアカウントでやってはいけません！CloudFrontで後で証明書を設定する時、選択できなくなります。予め、作る前に自分の権限がIAMで用意した権限になっていることを確認すること！
確認できたら↓↓
申請はAWS Certificate Manager（簡単に SSL/TLS 証明書を作成、管理、配置） | AWSから。SSLをつける独自ドメインは事前取得が必要。
まだ発行済証明書がないので入力フォームが出るはずです。ドメイン名*に取得済みドメイン名を入力します。もし既存の証明書を利用するなら、証明書のインポートボタンをクリックします。ここでは新規で作ったドメインを利用する方向で進めます。
新たに取得したadmin@○○等のメールアドレスが有効になっていることが確認できているのなら、次へボタンを押して確定しちゃいましょう。
ここまでうまくいっていれば下画像の様なメールが来るはずです。
※ここでは5つのメルアドに届くメールすべて1つのgmailにまとめて転送させています。
メール(どれか1つで良い)に記載されているURLにアクセスして遷移先でI Approveをクリックすると下記画面が出て手続き完了です。
念のためCertificate Managerにアクセスしてみると、下記の通り証明書が発行されていることがわかります。
この証明書、画面からはダウンロードできないようです。
S3へバケット用意
今お名前.comで用意した独自ドメイン名をバケット名にして登録します。まだ実データは配備しなくて大丈夫です。ここの名前が間違っているとココから先の設定がうまくいきません。
CloudFrontへS3ドメインを設定
CloudFrontを開き、Webの方のGet Startedボタンをクリック。
Create Distributionの項目を下記の通り埋めていきます。
Origin Settings
Origin Domain Name：事前に作成したS3のバケット名(自動で出てくる)を選択します。
Origin ID：↑を入れれば自動で入力されます。
今回はCloudFront以外からのS3へのアクセスを禁じるので、下記を参考にして設定しました。
Origin Access Identity：Create a New Identity
Comment：何でもいいですが、ここではデフォルト入力例に従って「access-identity-バケット名」とでもしましょう。
Grant Read Permissions on Bucket：Yes, Update Bucket Policy
Alternate Domain Names：ここに独自ドメインを入れる。事前にACM申請の時設定したドメイン名がドロップダウンに表示されています。
Alternate Domain Names：サブドメインを含めた独自ドメイン
それ以外はデフォルトでOK
独自ドメインのための続きはRoute 53で設定します。
Default Cache Behavior Settings
ここは特段いじりません。
Distribution Settings
ここも特段いじりません。
オプションの項目にHTTP/2とかIPv6とか専門知識が出てきますが一応知識としてあったほうがいいので簡単に勉強を。
入力が終わったらCreate Distributionボタンをクリック。
Behaviorsの設定もします。使うファイルはHTML/JS/CSS/画像(形式によって異なる)なので、それぞれ追加しましょう。HTTP to HTTPSのredirectを選択。
Route 53
を参照して進めます。サービスからRoute53をクリックして、トップ画面からDNS managementをクリックし、Created Host Zoneをクリック。画面右側のフォームに下記の通り入力して、Createをクリック。
Domain Name：お名前.comで取得した独自ドメイン
comment：なんでもいいです。
Type：Public Hosted Zone
登録後の例↓
Route 53への登録が終わったら、今度はお名前.comのコントロールパネルまで移動して、NSレコード4つをDNS登録します。続きは↑の記事の通りで大丈夫です。
設定の反映に結構時間がかかるので、こういう設定は最初に一通り完了させておいたほうが気が楽です。
S3に配備したファイルのSSL化は以上となります。
念のため下記の通りになるかチェックを。
- S3に何かファイルを配備して、プロパティに出るURLをクリックしてみましょう。中身が表示出来たはずです。
- CloudFrontで設定した独自ドメイン/ファイル名のURLにアクセスしてみましょう。中身が表示出来たはずです。
API Gatewayを独自ドメイン化
S3の設定とは別にAPI Gatewayでも独自ドメイン利用の設定をする必要があります。どうせなら合わせましょう。
ココは後で書きます（たぶん
番外編：S3の独自ドメイン設定(CloudFront利用なしの場合)
S3でのファイル公開～独自ドメインアクセスは
にまとまっていて分かりやすいのでココにそってやると良いでしょう。
こちらはACM, CloudFrontが不要で、S3とRoute53のみの設定で出来ます。
番外編：間違ってACMをroot権限で作ってしまったら
下画像の様にCustom SSL Certificateが選択できなくなります。
こうなると面倒。やることはACMで証明書を発行し直しになります。作成直後すぐ気づけたなら作り直せばいいのですが、Route 53の設定を終わった後だとやっかいです。
- まずお名前.comのドメインNaviのネームサーバ変更で、最初にadmin@ドメイン名などのメールアドレスを登録したコントロールパネルのドメイン(dnsXX.gmoserver.jpの様な名前)に戻す必要があります。最大で24~72hかかります。
- 次に再度メールがadmin@ドメイン名などのメールアドレスにメールを送って、メールが届くことを確認してください。問題なければ、ACMの申請をやり直します。
- ACMで証明書を無事発行できたら、再度ドメインNaviでRoute 53で設定したNSレコードを使ってネームサーバ変更してください。
- CloudFrontのEditからCustom SSL Certificateが選択可になっていることが確認できればOKです。
番外編：Route 53/CloudFront/ACMの設定をしたはずなのにエラーが出る
の原因を辿ってみてください。感覚的にこの中だとCloudFrontの設定ミスが一番起こりやすいです。
総括
今回はインフラ寄りの知識が多かったです(寧ろそれしかなかった)。そもそもAWS全体的にそんな感じっていうか。。ただ言われたとおりのプログラムを書くだけのザ・プログラマにはちと辛いサービスであることは間違いありません。
もっともこれはインフラに造詣が深い人間が書いた記事ではないので、無駄がありそうです。もっとうまい方法を見つけたら修正します。
他の記事を沢山参照しまくらないと作れないよ本当。トホホ┐(´д｀)┌
