AWS移行の際に注意すべき点
AWS移行の際に注意すべき点:
ここ数年AWSのインフラ設計~構築~運用をやってきましたが、これからAWSを導入してみよう、使ってみようと言う方のために、その知見を少し公開
AWSのアカウントの開設の際、クレジットカードが必要です。個人はともかく法人利用の際は導入時にそれなりの障壁となりますので、注意が必要です。NTT東日本のリセールを通してアカウントを開設すればクレカが不要らしいですが、このような請求代行がいくつかあるので、それらを利用するのも良いかもしれません。
https://business.ntt-east.co.jp/service/publiccloud/
AWSは従量課金であるため、使った分だけ請求がきます。テストでちょっとだけ使った仮想サーバを立ち上げっぱなしで放置、退職した社員が作成した今は使ってもいない放置された仮想サーバ、誰がなんのために作ったのかよくわからないインスタンスなどなどを放置していますと、請求料金がガンガン上がっていきます。不要なサーバやデータは削除する、使っていない時は停止するなどまめなリソース管理が必要です。
一般的に端末に割り振りできないネットワークアドレスとブロードキャストアドレス以外にAWSではネットワークアドレスに 1~3 を足した次の3つのIPアドレスが予約アドレスとして使えません。
事例(数値はサンプルで、他のネットワークアドレスでも同等です)
Zone Apexとは、 tanuki.com などサブドメイン抜きのドメイン名そのものをさしますが、よくウェブサーバでホスト名を付けない短いURLで運用されているのを見かけるかと思います。
ELB(ロードバランサー)などAWSの一部のサービスは、DNSラウンドロビンで冗長化されていたり、IPアドレスが固定されていなかったりするため、立ち上げたインスタンスはIPアドレスではなくamazon所有ドメインのFQDNを使って利用します。
立ち上げたELBなどのサービスに自社ドメインを対応させて利用する際には、Aレコードではなく、CNAMEレコードで自社ドメインをAmazonから渡されたFQDNに対応させる運用となりますが、DNSの仕様上、Zone Apexの文字列をCNAMEレコードとして登録することができません。
この問題を解決するためにAmazonが独自にカスタマイズしたDNSサービスであるRoute53を利用して、Aliasレコードと呼ばれるAWS独自のレコードで運用すれば自社ドメインのZone ApexとELB等のAmazonから渡されたFQDNを関連付けることができます。しかし、DNSやドメイン運用ポリシー等の問題でRoute53を利用できない場合があります。こういう場合、自社ドメインで短いURLでの運用はあきらめるか、もしくは、リダイレクトなどなんらかの仕組みをかまして実現するしかありません。いずれにしても、フォークリフトですでに短いURLで運用されているサービスをAWSへ上げる場合は注意が必要です。
詳細を知りたい方はRFCを読んでください
https://www.ietf.org/rfc/rfc1912.txt
AWSのVDIサービスであるWorkSpacesですが、OSはWindowsではなく、Windows Server OSです。ですので、手持ちのソフトウェアがサーバOSをサポートしておらず、使いたいソフトウェアが利用できないという場合がありますので注意が必要です。また、デフォルトでは英語版が起動するため、日本語パックをインストールしたりOSの言語設定を日本語に変えるなどある程度の作業が発生してしまいます。
AWSのセミナーでは x86/amd64 用のOSは自作のOSも含めてすべてAWSで利用できると説明を受けましたが、2019年現在、Oracle Solaris (x86/amd64版)のAMIはラインナップされていません。昔はOpenSolarisが公開されていましたが、今は公開中止となったようです。現状、AWSでSolarisは使えないか、使えたとしても簡単には利用できなさそうです(ライセンス周りやAMIのベース構築など)。
以上、AWSで注意したい点をいくつかピックアップしました。
ここ数年AWSのインフラ設計~構築~運用をやってきましたが、これからAWSを導入してみよう、使ってみようと言う方のために、その知見を少し公開
アカウントの開設
AWSのアカウントの開設の際、クレジットカードが必要です。個人はともかく法人利用の際は導入時にそれなりの障壁となりますので、注意が必要です。NTT東日本のリセールを通してアカウントを開設すればクレカが不要らしいですが、このような請求代行がいくつかあるので、それらを利用するのも良いかもしれません。https://business.ntt-east.co.jp/service/publiccloud/
利用料金と請求書の確認
AWSは従量課金であるため、使った分だけ請求がきます。テストでちょっとだけ使った仮想サーバを立ち上げっぱなしで放置、退職した社員が作成した今は使ってもいない放置された仮想サーバ、誰がなんのために作ったのかよくわからないインスタンスなどなどを放置していますと、請求料金がガンガン上がっていきます。不要なサーバやデータは削除する、使っていない時は停止するなどまめなリソース管理が必要です。
AWSで使えないアドレス
一般的に端末に割り振りできないネットワークアドレスとブロードキャストアドレス以外にAWSではネットワークアドレスに 1~3 を足した次の3つのIPアドレスが予約アドレスとして使えません。事例(数値はサンプルで、他のネットワークアドレスでも同等です)
アドレス | 説明 | |
---|---|---|
10.0.0.0/24 | ネットワークアドレス | 一般的に使用できない |
10.0.0.1/24 | 仮想ルータ | AWSでは使用できない |
10.0.0.2/24 | DNSリゾルバ | AWSでは使用できない |
10.0.0.3/24 | AWS予約 | AWSでは使用できない |
10.0.0.255/24 | ブロードキャストアドレス | 一般的に使用できない |
Zone Apex が使えない事例
Zone Apexとは、 tanuki.com などサブドメイン抜きのドメイン名そのものをさしますが、よくウェブサーバでホスト名を付けない短いURLで運用されているのを見かけるかと思います。名前 | 説明 |
---|---|
tanuki.com | Zone Apex |
tokyo.tanuki.com | サブドメイン付き |
立ち上げたELBなどのサービスに自社ドメインを対応させて利用する際には、Aレコードではなく、CNAMEレコードで自社ドメインをAmazonから渡されたFQDNに対応させる運用となりますが、DNSの仕様上、Zone Apexの文字列をCNAMEレコードとして登録することができません。
この問題を解決するためにAmazonが独自にカスタマイズしたDNSサービスであるRoute53を利用して、Aliasレコードと呼ばれるAWS独自のレコードで運用すれば自社ドメインのZone ApexとELB等のAmazonから渡されたFQDNを関連付けることができます。しかし、DNSやドメイン運用ポリシー等の問題でRoute53を利用できない場合があります。こういう場合、自社ドメインで短いURLでの運用はあきらめるか、もしくは、リダイレクトなどなんらかの仕組みをかまして実現するしかありません。いずれにしても、フォークリフトですでに短いURLで運用されているサービスをAWSへ上げる場合は注意が必要です。
詳細を知りたい方はRFCを読んでください
https://www.ietf.org/rfc/rfc1912.txt
WorkSpaces の制限
AWSのVDIサービスであるWorkSpacesですが、OSはWindowsではなく、Windows Server OSです。ですので、手持ちのソフトウェアがサーバOSをサポートしておらず、使いたいソフトウェアが利用できないという場合がありますので注意が必要です。また、デフォルトでは英語版が起動するため、日本語パックをインストールしたりOSの言語設定を日本語に変えるなどある程度の作業が発生してしまいます。
Solaris は公開されていない
AWSのセミナーでは x86/amd64 用のOSは自作のOSも含めてすべてAWSで利用できると説明を受けましたが、2019年現在、Oracle Solaris (x86/amd64版)のAMIはラインナップされていません。昔はOpenSolarisが公開されていましたが、今は公開中止となったようです。現状、AWSでSolarisは使えないか、使えたとしても簡単には利用できなさそうです(ライセンス周りやAMIのベース構築など)。以上、AWSで注意したい点をいくつかピックアップしました。
コメント
コメントを投稿