この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
みなさま Xin chao !
クラウドを利用するメリットの一つとして、必要な量と必要な期間だけ利用することができるというものがあります (一定期間の利用をコミットするリザーブドインスタンスや Savings Plans などを除く)。 ハードウェアの残存リース期間や廃棄費用などについて考える必要がないため、不要になったシステムを閉鎖する際のハードルは低いと思います。 AWS 上に構築した Web サイトの役目が終わり、サイトを閉鎖した後、そのサイトへのアクセスについて、みなさんどうしているでしょうか？
サイトを閉鎖したのだから使用していた AWS リソースは削除し、アクセスされてもエラーが返るだけだから、それで OK という考え方もあると思いますが、今回は、閉鎖した Web サイトにアクセスしたら、関連する別のサイトにリダイレクトするように設定してみたいと思います。
リダイレクトを実現する方法
今回は、以下の 2 つの方法を試してみます。
できる限り最少の設定変更ですぐにリダイレクトを実現したい場合には方法1. で、ある程度の設定変更を行う余裕がありリダイレクトを実現するために要するコストを抑えたい場合には方法2. で行うことが可能です。
方法1. ALB のリスナールールで設定 (変化点・小, 維持コスト・大)
少し前の以下のアップデートで、ALB のリスナールールだけでリダイレクトが実現できるようになっています。
弊社ブログにも、やってみた系の記事が投稿されています。
この方法のメリットは、既存の AWS 構成からの変化点が小さいことです。 具体的に言うと、Route 53 等のホストゾーンのレコード定義や、ALB のデプロイ状況はそのままで、ALB のリスナールールの変更のみでリダイレクトを実現できます。
一方デメリットは、ALB の機能を使ってリダイレクトを実現しているため、ALB の利用費が課金されることにあります。 ALB の場合、デプロイしている時間に対して課金される利用費があるため、仮に閉鎖後のサイトに 1 件もアクセスがなかったとしても、リダイレクトを維持するために 17.496 USD / 月 (＝0.0243 USD × 24 時間 × 30 日間, 東京リージョン) の課金は発生します。 閉鎖したサイトに対して、この課金が発生することを許容できない場合もあるかと思います。
Elastic Load Balancing 料金 | Elastic Load Balancing 製品ページ
方法2. CloudFront＋S3 で設定 (変化点・大, 維持コスト・小)
S3 を使ったリダイレクトはいくつかの方法がありますが、今回は S3 バケット単位で設定するリダイレクションルールで行います。 S3 で行うリダイレクトについては、以下のブログをご参照ください。
この方法のメリットは、CloudFront および S3 のいずれもデータ転送量とリクエスト数に応じた課金がベースとなるため、ALB でリダイレクトを実現する方法1. に比べて、AWS 利用費を軽減できる可能性が高いことにあります。
Amazon CloudFront の料金 | Amazon CloudFront 製品ページ
Amazon S3 の料金 | Amazon S3 製品ページ
一方デメリットは、新たに CloudFront を構築したり、S3 バケットや Route 53 の設定が必要になるなど、変化点が大きいことにあります。 特に、これまで CloudFront を使ったことがない環境では、若干ハードルが高く感じられるかもしれません。
前提
以下のような前提でリダイレクトを設定してみます。
- 個別の製品やブランド等のサイトを想定した Web サイト (https://masawo.classmethod.info/) は、ALB＋EC2＋RDS で構築
- サービスの提供は既に終了し、十分な期間 Web サイトを閉鎖する旨を周知済み
- 完全閉鎖後の Web サイトへのアクセスは、事業会社 Web サイト (https://classmethod.jp/) のトップページにリダイレクトする
- リダイレクトの対象は HTTP および HTTPS でのアクセスとする
やってみた
今回は、初めに手軽にリダイレクトを設定できる方法1. を行い、その後のコスト削減のために方法2. でのリダイレクトに移行してみます (もちろん最初から方法2. でリダイレクトを設定することも可能です)。
リダイレクト設定前の状態 (Web サイトの閉鎖を周知中)
閉鎖する Web サイトは、すでに提供するサービスを停止し、EC2 で稼働する Web サーバー上のコンテンツでサイトの閉鎖を周知している状態です。
RDS はすでに使用していないため、必要に応じて最終の状態でスナップショットを取得したうえで、RDS のインスタンスは削除済みとなっています。
ALB でリダイレクトを設定 (方法1)
設定完了後は、このようになります。
ALB リスナールールを設定する
ALB の HTTPS リスナールールを編集します。 変更前の状態ではデフォルトアクションで、Web サーバーが稼働している EC2 が所属するターゲットグループ (masawo-rd-prd-alb-tg) にトラフィックを転送しています。
閉鎖する Web サイトに関連するアクション (今回の場合デフォルトアクションのみ) を以下のように編集し、classmethod.jp のトップページに HTTPS でリダイレクトするように変更して保存します。 実際の環境では、閉鎖する Web サイト以外のアクションが定義されている場合もあるため、それらには変更を加えないよう、十分注意しながら編集します。
- リダイレクト先
- HTTPS, 443
- カスタムホスト、パス、クエリを使用
- ホスト : classmethod.jp
- パス : /
- クエリ : (空欄のまま)
- 301 - 完全に移動されました
動作確認してみる
閉鎖する Web サイト (https://masawo.classmethod.info/) にアクセスし、事業会社の Web サイト (https://classmethod.jp/) にリダイレクトされることを確認します。
使用しなくなった EC2 を削除する
ALB によるリダイレクトの動作が確認出来たら、Web サーバーが稼働していた EC2 を停止することが可能です。 必要に応じて最終の状態で AMI を取得したうえで、インスタンスを削除します。 また、ALB のターゲットグループも削除可能です。
CloudFront＋S3 でリダイレクトを設定 (方法2)
方法2. の場合、CloudFront および S3 バケットの設定の他に、Route 53 (または他の DNS サーバー) ホストゾーンのレコード設定変更と、ACM による証明書 (CloudFront で使用) の発行も必要になります。
S3 バケットを作成する
リダイレクトに使用する S3 バケットを新規に作成します。 バケット名は特に指定はありません (今回は masawo-rd-prd-bucket を作成)。
S3 バケットでリダイレクトを設定する
作成した S3 バケットのプロパティを開き、"静的ウェブサイトホスティング" の [編集する] をクリックします。
静的ウェブサイトホスティングを以下のように設定し、保存します。
- 静的ウェブサイトホスティング : 有効にする
- ホスティングタイプ : 静的ウェブサイトをホストする
- インデックスドキュメント : index.html (註 : エラーで弾かれなければ何でも構いません)
- リダイレクトルール : (以下のように設定)
{
{
"Redirect": {
"HostName": "classmethod.jp",
"Protocol": "https",
"ReplaceKeyWith": ""
}
}
}
"ホスティングタイプ" で "オブジェクトのリクエストをリダイレクトする" を選択していないのは、リダイレクトルールを使って事業会社のトップページにリダイレクトさせるためです。 "オブジェクトのリクエストをリダイレクトする" を選択した場合、閉鎖する Web サイトにアクセスした際の URL パスを維持したまま事業会社の Web サイトにリダイレクトします (例. https://masawo.classmethod.info/hogehoge → https://classmethod.jp/hogehoge)。
なお、S3 バケットの "ブロックパブリックアクセス" は変更を加えていないため、有効 (＝パブリックアクセスできない) のままになっています。
S3 バケットに設定したリダイレクトの動作を確認してみる
用意された "バケットウェブサイトエンドポイント" の URL にアクセスし、事業会社の Web サイト (https://classmethod.jp/) にリダイレクトされることを確認します。 リダイレクトがうまくいかない場合、静的ウェブサイトホスティング (特にリダイレクトルール) の設定を再度ご確認ください。
なお、この URL で使用されているドメイン名 (今回の例では masawo-rd-prd-bucket.s3-website-us-east-1.amazonaws.com) は、この後の CloudFront の設定で使用します。
ACM で CloudFront 用の証明書を発行する
HTTPS でアクセスするために CloudFront で使用する証明書を ACM で発行します。 CloudFront で使用する証明書は、バージニア北部リージョン (us-east-1) の ACM で発行する必要があります。
証明書をリクエストする AWS リージョン (AWS Certificate Manager 用) | Amazon CloudFront デベロッパーガイド
今回証明書は、masawo.classmethod.info および www.masawo.classmethod.info の両方で使用できるように発行しています。
CloudFront を設定する
新規のディストリビューションを作成していきます。 [Create Distribution] をクリックします。
続けて [Get Started] をクリックします。
Origin Settings を設定します。
- Origin Domain Name : (S3 "バケットウェブサイトエンドポイント" のドメイン名を入力) (今回の場合 masawo-rd-prd-bucket.s3-website-us-east-1.amazonaws.com)
- Enable Origin Shield : No (Yes にした場合、Origin Shield 利用費が課金されます)
- その他項目は既定値のままとします
ここで注意点があります。 Origin Domain Name を設定する際、入力欄をマウスでクリックすると、S3 バケットの一覧が表示され、クリックひとつで S3 バケットを選択することができますが、ここで選択できるドメイン名は "バケットウェブサイトエンドポイント" のドメイン名とは異なるので、"バケットウェブサイトエンドポイント" のドメイン名をコピー / 手入力しましょう。
Default Cache Behavior Settings は、いずれも既定値のままとします。
Distribution Settings を設定し [Create Distribution] をクリックします。
- Price Class : Use Only U.S., Canada and Europe (今回はコスト重視なので最も安価な料金クラスを選択しています)
- Alternate Domain Names (CNAMEs) : (閉鎖する Web サイトのドメイン名を入力) (今回の場合 masawo.classmethod.info および www.masawo.classmethod.info)
- SSL Certificate : Custom SSL Certificate (example.com)
- 証明書 : (前の手順の ACM で発行した CloudFront で使用する証明書を選択)
- その他項目は既定値のままとします
Status が "In Progress" → "Deployed" になるまで待ちます。
CloudFront デフォルトドメイン名で S3 に設定したリダイレクトの動作を確認してみる
HTTP で CloudFront Distribution の "Domain Name" (今回の場合 http://dXXXXXXXXXXXo.cloudfront.net/) にアクセスし、事業会社の Web サイト (https://classmethod.jp/) にリダイレクトされることを確認します。 リダイレクトがうまくいかない場合、再度 CloudFront (特に Origin Settings) の設定をご確認ください。
なお、この "Domain Name" は、この後の Route 53 の設定で使用します。
Route 53 ホストゾーンのレコードを変更する
レコード名として、閉鎖する Web サイトのドメイン名 (今回の場合 masawo.classmethod.info または www.classmethod.info) が設定されているレコードを選択し、[編集] をクリックします。
変更前のレコードは、以下のように ALB へのエイリアスとして登録されていると思います。
レコードを以下のように変更し [変更を保存] をクリックします。
- レコード名 : (変更しない)
- 値/トラフィックのルーティング先 :
- CloudFront ディストリビューションへのエイリアス
- 米国東部 (バージニア北部)
- (作成した CloudFront Distribution の "Domain Name") (今回の場合 dXXXXXXXXXXXo.cloudfront.net)
- その他項目は既定値のままとします
同じように、もう 1 つのレコードも変更します。
変更後、レコード名として、閉鎖する Web サイトのドメイン名が設定されているレコードは、以下のようになります。
閉鎖した Web サイトの URL でリダイレクトの動作を確認してみる
閉鎖した Web サイトの URL にアクセスし、事業会社の Web サイトにリダイレクトされることを確認します。 今回の場合、以下のいずれの URL でアクセスしても、事業会社の Web サイトのトップページ (https://classmethod.jp/) にリダイレクトされます。 リダイレクトがうまくいかない場合、再度ホストゾーンのレコード設定をご確認ください。
- http://masawo.classmethod.info/
- http://www.masawo.classmethod.info/
- https://masawo.classmethod.info/
- https://www.masawo.classmethod.info/
- http://masawo.classmethod.info/hogehoge/
- https://masawo.classmethod.info/fugafuga.html
使用しなくなった ALB を削除する
CloudFront＋S3 によるリダイレクトの動作が確認出来たら、ALB を削除することが可能です。
おわりに
以上、閉鎖した Web サイトにアクセスした際に、別の Web サイトへリダイレクトさせる 2 つの方法を試してみました。
上記手順の中では触れませんでしたが、このリダイレクトを有効にしている間は、閉鎖した Web サイトで使用していたドメイン名 (今回の場合 masawo.classmethod.info) の更新を止めることはできません。 つまり、手順の中で触れた ALB または CloudFront＋S3 の利用費の他に、ドメイン更新のタイミングでドメイン更新費が課金されます。 .jp ドメインの場合、毎年ドメイン更新のために 90 USD が課金されます。
課題となるのは、いつまでリダイレクトの設定、およびドメインの更新を続けるべきか？ ですが、閉鎖した Web サイトへのアクセスをどうすべきか？ (別の Web サイトにリダイレクトするのか、何も対処せずにエラーで返すのか) と同様に、いろいろな考え方があると思います。
個人的には、グループ会社や関係組織等の各 Web サイトに貼られたリンクがすべて削除され、かつ、それ以外に PR 等で取り上げられた外部の各種 Web メディアに貼られたリンクが削除されるまで、可能であれば続けた方が良いと考えます。 また、ドメインの更新 (＋Route 53 ホストゾーンの維持) については、そのドメイン名が忘れ去られるまで続けたいところです。 理由は、期限切れとなったドメインが第三者に取得され、そのドメインを使って悪意を持った Web サイトが構築された際の、製品やブランドイメージへの影響を防ぐためです。
新規のドメインを取得すべきかどうか、および、取得したドメインの Web サイト閉鎖後の扱いについては、Web サイトを構築する段階で考えておくことが理想です。 新しい Web サイトなのだからという考え方ではなく、Web サイト閉鎖後のことまで考慮したうえで、新規のドメインを取得すべきか、既存ドメイン (のサブドメインまたは一部階層) を使用すべきか、検討していただければと思います。
10
