Amazon Route53で転送を設定しようとしています。私の最後のDNSサービス(Nettica)では、リクエストを「aws.example.com」から「https://myaccount.signin.aws.amazon.com/console/」にルーティングできました。
この機能はRoute53でサポートされていますか?
Netticaはこれをどのように達成しますか?特別なA、CNAME、PTR、またはTXTレコードを挿入しますか?
Amazon Route53で転送を設定しようとしています。私の最後のDNSサービス(Nettica)では、リクエストを「aws.example.com」から「https://myaccount.signin.aws.amazon.com/console/」にルーティングできました。
この機能はRoute53でサポートされていますか?
Netticaはこれをどのように達成しますか?特別なA、CNAME、PTR、またはTXTレコードを挿入しますか?
回答:
私はSauravが説明したのとまったく同じ問題に直面していましたが、Route 53とS3以外を必要としないソリューションを見つける必要が本当にありました。私は自分のブログのハウツーガイドを作成し、自分の行動を詳しく説明しました。
これが私が思いついたものです。
Amazon S3とAmazon Route 53で利用可能なツールのみを使用して、http://url-redirect-example.vivekmchawla.comをhttpsにある「MyAccount」にエイリアスされたAWSコンソールのサインインページに自動的に転送するURLリダイレクトを作成します://myaccount.signin.aws.amazon.com/console/。
このガイドでは、AmazonからのURLだけでなく、任意のURLへのURL転送の設定について説明します。特定のフォルダー(この例では「/ console」など)への転送を設定する方法、およびリダイレクトのプロトコルをHTTPからHTTPS(またはその逆)に変更する方法を学びます。
S3管理コンソールを開き、[バケットの作成]をクリックします。
バケット名を選択します。このステップは本当に重要です!バケットには、転送用に設定するURLとまったく同じ名前を付ける必要があります。このガイドでは、「url-redirect-example.vivekmchawla.com」という名前を使用します。
最適な地域を選択してください。わからない場合は、デフォルトのままにします。
ロギングの設定について心配する必要はありません。準備ができたら「作成」ボタンをクリックするだけです。
次のXMLスニペット全体を貼り付けます。
<RoutingRules>
<RoutingRule>
<Redirect>
<Protocol>https</Protocol>
<HostName>myaccount.signin.aws.amazon.com</HostName>
<ReplaceKeyPrefixWith>console/</ReplaceKeyPrefixWith>
<HttpRedirectCode>301</HttpRedirectCode>
</Redirect>
</RoutingRule>
</RoutingRules>
上記のXMLの動作について知りたい場合は、「ルーティングルールを指定するための構文」のAWMドキュメントにアクセスしてください。ボーナステクニック(ここでは取り上げません)は、宛先ホストの特定のページに転送することhttp://redirect-destination.com/console/special-page.html
です。<ReplaceKeyWith>
この機能が必要な場合は、要素についてお読みください。
Amazonがこのバケット用に自動的に作成した静的ウェブサイトホスティングの「エンドポイント」をメモします。これは後で必要になるので、URL全体を強調表示し、コピーしてメモ帳に貼り付けます。
注意!この時点で実際にこのリンクをクリックして、リダイレクトルールが正しく入力されているかどうかを確認できますが、注意してください。その理由は...
<Hostname>
リダイレクトルールのタグ内に間違った値を入力したとしましょう。たぶんmyaccount.amazon.com
、の代わりに誤ってタイプしたのかもしれませんmyaccount.signin.aws.amazon.com
。リンクをクリックしてエンドポイントURLをテストすると、AWSはブラウザーを間違ったアドレスにリダイレクトします。
間違いに気付いたら<Hostname>
、リダイレクトルールでを編集してエラーを修正します。残念ながら、もう一度リンクをクリックしようとすると、誤ったアドレスにリダイレクトされる可能性が高くなります。<Hostname>
エントリを修正しても、ブラウザは以前の(不正な!)エントリをキャッシュしています。これは、ChromeやFirefoxなどのブラウザーがデフォルトでキャッシュするHTTP 301(永続的)リダイレクトを使用しているために発生します。
エンドポイントURLをコピーして別のブラウザーに貼り付ける(または現在のブラウザーのキャッシュをクリアする)と、更新された<Hostname>
エントリーが最終的に正しいものであるかどうかを確認する別の機会が得られます。
安全のため、エンドポイントURLとリダイレクトルールをテストする場合は、Chromeの「シークレットモード」などのプライベートブラウジングセッションを開く必要があります。シークレットモードでエンドポイントURLをコピー、貼り付け、テストします。セッションを閉じると、キャッシュされたものはすべて消えます。
[Create Record Set]をクリックすると、Route53管理コンソールの右側にある[Create Record Set]ウィンドウが開きます。
[名前]フィールドに、S3バケットに名前を付けるときに使用したURLのホスト名部分を入力します。URLの「ホスト名の部分」は、ホストゾーンの名前の左側にあるすべてのものです。S3バケットに「url-redirect-example.vivekmchawla.com」という名前を付け、ホストゾーンは「vivekmchawla.com」であるため、入力する必要があるホスト名の部分は「url-redirect-example」です。
このレコードセットのタイプとして「CNAME-正規名」を選択します。
[値]には、ステップ3で作成したS3バケットのエンドポイントURLを貼り付けます。
「Create Record Set」ボタンをクリックします。エラーがないと仮定すると、ホストゾーンのレコードセットのリストに新しいCNAMEレコードが表示されます。
新しいブラウザタブを開き、先ほど設定したURLを入力します。私にとっては、それはhttp://url-redirect-example.vivekmchawla.comです。すべてが正常に機能した場合は、AWSサインインページに直接移動する必要があります。
myaccount.signin.aws.amazon.com
リダイレクトの宛先URLとしてエイリアスを使用したため、Amazonはアクセスしようとしているアカウントを正確に認識し、そこに直接アクセスします。これは、従業員や請負業者に短くてクリーンなブランドのAWSログインリンクを提供する場合に非常に便利です。
私は個人的にさまざまなAWSサービスが大好きですが、DNS管理をAmazon Route 53に移行することを決めた場合、簡単なURL転送の欠如はイライラすることがあります。このガイドがホストゾーンのURL転送の設定を少し簡単にしてくれたことを願っています。
詳細については、AWSドキュメントサイトの次のページをご覧ください。
乾杯!
AWSサポートはより簡単なソリューションを指摘しました。これは基本的に、@ Vivek M. Chawlaによって提案されたアイデアと同じですが、よりシンプルな実装です。
AWS S3:
aws.example.com
Redirect all requests to another host name
URLを選択して入力します。
https://myaccount.signin.aws.amazon.com/console/
AWS Route53:
Yes
。エイリアスをに変更します。Alias
Target
フィールドをクリックし、前のステップで作成したS3バケットを選択します。リファレンス:アマゾンウェブサービスを使用してドメインをリダイレクトする方法
AWS公式ドキュメント:Amazon Route 53を使用してドメインを別のドメインにリダイレクトする方法はありますか?
Redirect all requests to another host name
オプションはまだ存在しますか?バケットのプロパティに移動すると、表示されません。
nginxを使用して、awsサインインページへの301リダイレクトを処理することができました。
nginx confフォルダーに移動します(私の場合は、有効なconfファイル/etc/nginx/sites-available
へのシンボリックリンクを作成し/etc/nginx/sites-enabled
ます)。
次にリダイレクトパスを追加します
server {
listen 80;
server_name aws.example.com;
return 301 https://myaccount.signin.aws.amazon.com/console;
}
nginxを使用している場合は、ゾーンの頂点(example.com)を処理するために追加のサーバーブロック(Apacheの用語ではvirtualhosts)があるか、またはセットアップされている可能性があります。それらの1つがデフォルトのサーバーとして設定されていることを確認してください。
server {
listen 80 default_server;
server_name example.com;
# rest of config ...
}
Route 53で、A record
for aws.example.com
を追加し、ゾーンの頂点に使用されているのと同じIPに値を設定します。
以下の私の元の答えはまだ有効であり、そのままではAmazon Route 53を介してDNSベースのURL転送が利用できない原因を理解するのに役立つかもしれませんが、その間に紹介したVivek M. Chawlaの非常にスマートな間接ソリューションをチェックすることを強くお勧めしますAmazon S3によるウェブサイトリダイレクトのサポートと自己完結型サーバーの実現、したがってAWS内での無料のソリューションはそれだけです。
Netticaはこのためのカスタムリダイレクトソリューションを実行している必要があります。これが問題です。
aws.example.com
forのようなCNAMEエイリアスを作成することもできますmyaccount.signin.aws.amazon.com
が、DNSはconsole
この例のようにサブディレクトリのエイリアスを公式にサポートしていません。
https://myaccount.signin.aws.amazon.com/
(私が試したところ)、デフォルトでこれを単純に行うようには見えないのは残念です。加えて、彼らの側で設定するのはかなり簡単なはずです。そのため、いくつかのDNSプロバイダーは、サブディレクトリへのリダイレクトを可能にするカスタムソリューションを実装しているようです。私は、彼らが基本的に自分のドメインのCNAMEエイリアスを促進していて、すぐにHTTP 3xx Redirectionを介してそこから最終的な宛先にリダイレクトしていると思います。
したがって、同じ結果を得るには、これらのリダイレクトを実行するHTTPサービスを実行する必要があります。これは、当然期待される単純なソリューションではありません。多分/うまくいけば誰かがまだよりスマートなアプローチを思い付くことができます。