はじめに
「自分の技術サイトを持ちたい」と思ったのが、SAMEKORO LABを始めたきっかけでした。記事を書くだけならブログサービスでも十分ですが、今回は置き場所も見た目も自分で決めたくて、AWS上に作ることにしました。
この記事は、独自ドメインを取り、そのURLでサイトが開くまでの記録です。細かなクリック手順より、どのサービスを何のためにつなぎ、どこで楽しくなったのかを残します。
独自ドメインを持つのは、思っていた以上に楽しかった
最初は、配信用に発行されるURLでも見られるなら十分だと思っていました。でも、サイト名を決めたら samekorolab.com も欲しくなりました。
独自ドメインが付くと、自分の場所に住所ができる感覚があります。たったひとつURLが変わるだけなのに、急に「自分のサイトだ」と思えるのが不思議でした。
まだ作りかけでも、その住所から画面が開くとうれしいものです。自分だけの秘密基地に、ようやく表札が付いたような気分でした。
作るなら、自分らしい見た目にしたかった
見た目は、暗い青を基調にした深海モチーフにしました。サメや泡、上から差し込む光を入れ、静かに潜っていく雰囲気を目指しています。
画面右上には深度を切り替えるボタンも付けました。押すと背景の明るさや光の見え方が変わります。なくても困らない機能ですが、こういう遊びを入れられるのは個人サイトならではです。
今回使ったAWS構成
構成を考え始めたときは、独自ドメインを取れば作業の山を越えられると思っていました。ところが役割は分かれていて、どこから手を付けるか少し迷いました。
今回使ったのは、DNS（ドメイン名と接続先を結びつける仕組み）と、それを管理するAmazon Route 53（ドメインの取得やDNS設定を行うサービス）、Amazon CloudFront（Webサイトのデータを配信するサービス）、Amazon S3（ファイルを保存するサービス）です。さらに、HTTPS（通信を暗号化してサイトへ接続する仕組み）に必要な証明書を管理するAWS Certificate Manager、略してACM（HTTPS用の証明書を管理するサービス）も使いました。
独自ドメインは暗号化通信で開けるようにしました。構成を図にすると、次の流れです。
Amazon Route 53独自ドメイン / DNS
Amazon CloudFront配信 / HTTPS
Amazon S3HTML・CSS・画像を保存
AWS Certificate ManagerCloudFrontへTLS証明書を提供閲覧者が samekorolab.com を開くと、Route 53がCloudFrontへ案内し、CloudFrontがS3にあるファイルを届けます。ACMで用意した証明書はCloudFrontへ設定します。
図にして矢印を追うと、「名前」「配信」「保存」「証明書」がようやくひと続きになりました。コンソールを行き来している間はばらばらに見えていた役割が、ここで腑に落ちました。
Route 53でsamekorolab.comを取得した
ドメイン名はサイト名に合わせて、迷わず samekorolab.com にしました。短くて覚えやすく、見た瞬間にSAMEKORO LABだと分かるところが気に入っています。
申し込み後、登録済みドメインとして確認できるまでは少し待ちました。待っている間は、文字列を一つ選んだだけなのに妙にそわそわしました。料金や完了までの時間はドメインや時期で変わるため、申し込み画面とAWSからの完了メールで確認しています。
登録済みになった瞬間は「これで開ける」と思いましたが、まだ接続先を決める作業が残っています。取得後は、DNS設定で samekorolab.com の接続先をCloudFrontへ向けました。ドメイン取得と配信先への案内は別だと考えると、ようやく整理できました。
サイトを公開するまでに必要だったもの
作業前は「ドメインを取ってS3へ置けば終わりかな」と考えていました。実際には、次の役割をつなぐ必要があります。
samekorolab.comを取得する- DNS設定でCloudFrontへ向ける
- S3へHTML、CSS、JavaScript、画像を置く
- CloudFrontからファイルを配信する
- ACMで独自ドメイン用の証明書を用意する
実際は「これで終わりかな」と進むたびに次の役割が出てきました。最後につながったとき、公開とは設定を埋めることではなく、この流れを作ることなのだと分かりました。
途中では、証明書を先に用意するのか、CloudFrontの設定をどこまで進めるのかで何度か行き来しました。それでも、各サービスの役割が分かっていれば、今どこを確認しているのかは見失わずに済みます。設定項目を覚えるより、流れをつかむほうが自分には合っていました。
S3とCloudFrontでサイトを公開した
サイトのファイルはS3へ置きました。ただし、S3自体をWebサイトとして直接公開する形にはしていません。
公開はCloudFrontに任せ、OAC（CloudFrontからだけS3へアクセスさせる仕組み）を使いました。閲覧者はCloudFrontへアクセスし、S3はCloudFrontから求められたファイルを返します。
権限や接続先には確認する場所が多く、ここは思ったより手が止まりました。構成を選んだ理由と確認内容は、第2回で詳しく振り返ります。
ACMでHTTPS化した
ACMでは、独自ドメインでHTTPS通信を行うための証明書を用意しました。CloudFrontで使う証明書なので、今回の環境では us-east-1 で作成しています。
DNS検証を終えた時点で証明書の作業は終わった気がしましたが、CloudFrontへ設定して初めて配信に使えます。コンソールを行き来して少し迷ったものの、「このドメインを管理している」と確認し、安全に接続するための流れだと分かると落ち着いて追えました。
独自ドメインで表示できた瞬間
ひと通り設定を終え、ブラウザで https://samekorolab.com を開きました。アドレスバーに自分で選んだドメインが出て、深海モチーフの画面が表示された瞬間は、思わず何度かリロードしました。
中身はまだ増やしている途中でも、名前と画面がそろうと急にサイトらしく見えます。この瞬間のうれしさは、ブログサービスではなく自分で作ろうと思った理由そのものでした。
実際に作ってみて感じたこと
一番の収穫は、AWSの各サービスが一つの配信経路として見えるようになったことです。深度を変える遊びのように、自分が面白いと思うものをそのまま入れられたのも、個人サイトならではでした。
公開した時点で完成というより、ようやく土台ができた感覚でした。記事を増やしながら見せ方を直し、必要ならAWS側の構成も見直す。小さな変更を自分のペースで重ねられることが、このサイトを持つ一番の楽しさかもしれません。
まとめ
samekorolab.com を取得し、Route 53、CloudFront、S3、ACMをつないでSAMEKORO LABを公開しました。自分で選んだ住所から、自分で作った画面が開いたときの達成感はかなり大きかったです。
これから記事や検証結果を少しずつ増やし、このサイトをのんびり育てていきます。次回は、S3を直接公開せず、CloudFrontとOACで静的サイトを配信した構成をもう少し詳しく書きます。