さくらインターネットからAmazon Route 53へのドメイン移管

コスト削減と勉強の為にさくらインターネットからAmazon Route 53へ
ドメイン移管をしてみました。

こちらのブログを参考にさせていただきました。
ありがとうございました！おそらくこのブログがなかったらできなかったかもしれないです。
http://tnil.hatenadiary.jp/entry/20150202


1. ホストゾーンを作成する【Amazon Route 53】
http://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/MigratingDNS.html#Step_CreateHostedZone

移管対象のドメイン名でホストゾーンを新規で作成します。


2. さくらで取得したドメインのネームサーバ情報を変更する【さくらインターネット】
https://help.sakura.ad.jp/app/answers/detail/a_id/2083

WHOISのネームサーバ1,2,3,4にRoute53で作成したホストゾーンのNSレコードに変更する


3. gTLDドメイン転出手順を実施する【さくらインターネット】
https://help.sakura.ad.jp/app/answers/detail/a_id/2073

上記手順により、転出手続きを行います。
問い合わせの欄は*があるところのみ記入すれば大丈夫です。


4. gTLDドメインのRegistrant Emailを変更する【さくらインターネット】
https://help.sakura.ad.jp/app/answers/detail/a_id/1499

私の場合は、JPRS管理のドメインだったので、
以下の手順で、登録者のメールアドレスを自分のメールアドレスに変更しました。

https://help.sakura.ad.jp/app/answers/detail/a_id/2069

Amazon Route 53からのメールがwhoisのRegistrant Email宛に承認メールを
送信するのですが、さくらインターネットは自分で宛先のEmailを変更する必要が
あるとのことでした。


■■1日後■■
手順3で依頼した手続きの完了メールが届きます。(3営業日以内)
このメールに記載されているオースコードがこのあとの手続きに必要です。


5. ドメインの移管登録を実施する【Amazon Route 53】
http://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/domain-transfer-to-route-53.html#domain-transfer-to-route-53-proc

ここの手順4から16を実施します。


6. ドメイン移管のメールを受信し、承認する【Amazon Route 53】
Transfer confirmation for the domain "ドメイン名"という件名のメールがくるので、
メール本文にあるリンクをクリックし、承認を行う。


7. ドメイン移管のメールを受信し、承認する【JPRS】
レジストラトランスファーアウト意思確認のご案内という件名のメールがくるので、
メールの本文にあるリンクをクリックし、承認を行う。


8. ドメイン移管のメールを受信し、承認する【Amazon Route 53】
Verification of your contact dataという件名のメールがくるので、
メール本文にあるリンクをクリックし、承認を行う。


9. ドメイン移管完了のメールを受信する【Amazon Route 53】
Transferring the domain ドメイン名 to Route 53 succeededという
件名のメールがくると移管が完了します。


10. Amazon Route 53でレコード追加

EC2にアサインしたEIPのAレコードを追加する。(Nameはwwwなど適当につける)
移管前はZone Apexで名前解決をしていたので、移管後も名前解決できるように
Aliasのレコードを作成する。

Zone Apexで名前解決するためのAliasレコードの作成は、以下の通りです。

"Name"は何もいれない
"Type"はA-IPv4 addressのまま
"Alias"はYesを選択
"Alias Target"に先に設定したEIPのAレコードを選択する
(入力するところをクリックすると選択可能な一覧が表示される)

これで、以前と同じように名前解決できるようになりました。

移管前と移管後の料金の比較です。

移管前
ドメイン使用料　1852円/年

移管後
ドメイン使用料　10$/年
ホストゾーン　　0.5$/月
標準的クエリ　　0.4$(100万クエリごと)/月

移管後は20.8$/年なので、コストを下げるつもりが逆にちょっと上がってますね…

Amazon Route 53 料金
http://aws.amazon.com/jp/route53/pricing/

AWSをスマホから操作する(AWS Console)

スマホからAWSのマネジメントコンソールにログインしたいなと思って調べていたら、
AWS Consoleというアプリがあるそうで、さっそくインストールしてみました。

AWS Console モバイルアプリ
https://aws.amazon.com/jp/console/mobile/

利用用途としては、現在、AWSである一定の金額が課金されるとメールがくるように
設定しているので、メールを受信した時に状況をすぐに確認して対応できるということですね。

ただ、設定とかは細かすぎて見にくいのと、操作できるサービスが主要なものだけですので、
補助的な使い方がいいと思います。
このアプリは無料ですので、試してみてはいかがでしょうか。

AWS上での通信制御方法について

インターネットからAWSのサーバーへの通信で、ある送信元からの通信をブロックしたいときにはどのような方法があるかを考えてみました。

AWS内で通信を制御できるところは以下になります。

1. ネットワークACL
2. セキュリティグループ
3. OSの機能
　　windowsであれば、windows Firewallなど
　　Linuxであれば、iptablesなど

1.のネットワークACLはインバウンドとアウトバウンドをステートレスで制御でき、ホワイトリストとブラックリスト方式となっています(CiscoルータのACLと同様の機能)。ブラックリスト方式のため、遮断させるネットワークを指定することができます。

2.のセキュリティグループでは制御が難しい可能性があります。
セキュリティグループはホワイトリスト方式で全ての通信をブロックした状態から許可したい通信を追加していきます。もし、セキュリティグループで送信元が全てで許可していた場合には、許可したいルールを全て入れることになるため、セキュリティグループのルール数の上限に達してしまう可能性があり、実装が難しくなります。

Amazon VPC 制限
http://docs.aws.amazon.com/ja_jp/AmazonVPC/latest/UserGuide/VPC_Appendix_Limits.html

3.のOSの機能ですが、通信を遮断することは可能です。ですが、サーバーのCPUやメモリのリソースを通信の遮断の処理に割り当ててしまうため、通信量によっては正常なサービスが提供できなくなる可能性があると考えられます。

結論としては、ネットワークACLで制御するのがよいとは思います。
ただ、選択肢としてOSの機能で制御もできるので、例えば、お客様の希望やOS上で遮断したログを確認したい時などは、OSで制御するでもよいのかと思います。