ここ数年AWSのインフラ設計～構築～運用をやってきましたが、これからAWSを導入してみよう、使ってみようと言う方のために、その知見を少し公開
アカウントの開設
AWSのアカウントの開設の際、クレジットカードが必要です。個人はともかく法人利用の際は導入時にそれなりの障壁となりますので、注意が必要です。NTT東日本のリセールを通してアカウントを開設すればクレカが不要らしいですが、このような請求代行がいくつかあるので、それらを利用するのも良いかもしれません。
利用料金と請求書の確認
AWSは従量課金であるため、使った分だけ請求がきます。テストでちょっとだけ使った仮想サーバを立ち上げっぱなしで放置、退職した社員が作成した今は使ってもいない放置された仮想サーバ、誰がなんのために作ったのかよくわからないインスタンスなどなどを放置していますと、請求料金がガンガン上がっていきます。不要なサーバやデータは削除する、使っていない時は停止するなどまめなリソース管理が必要です。
AWSで使えないアドレス
一般的に端末に割り振りできないネットワークアドレスとブロードキャストアドレス以外にAWSではネットワークアドレスに 1～3 を足した次の３つのIPアドレスが予約アドレスとして使えません。
事例（数値はサンプルで、他のネットワークアドレスでも同等です）
| アドレス | 説明 | |
|---|---|---|
| 10.0.0.0/24 | ネットワークアドレス | 一般的に使用できない |
| 10.0.0.1/24 | 仮想ルータ/L3スイッチ | AWSでは使用できない |
| 10.0.0.2/24 | DNSリゾルバ | AWSでは使用できない |
| 10.0.0.3/24 | AWS予約 | AWSでは使用できない |
| 10.0.0.255/24 | ブロードキャストアドレス | 一般的に使用できない |
EBSの接続と速度
家庭用のパソコンの場合、SATAやUSB3.0、IEEE1394(FireWire)などでマザーボードと接続されていますが、EBSは下に貼り付けた画像の通り、ローカルエリアネットワーク上に存在するストレージで、インターネットやLANの通信と帯域を共有しています。一般的なネットワークの通信とEBSへの通信を加味してデザインする必要がありますね。
図はAWS公式サイトより引用
EBSなどAWSのストレージの関係を示した図です。各ストレージの特徴を抑え、上手に設計したいですね。
EC2のSwap領域
EC2インスタンスをデプロイするとSwap領域を持たない構成でデプロイされることが多いです(一部のインスタンスタイプはSwapを提供しているようです)。メモリのサイジングをしっかりと行っていれば、Swapがなくとも問題はないのですが、それでも想定外のスパイクによりメモリ不足に陥ることがあります。Linuxの場合、メモリがフルになりSwap領域が存在していないとOOM Killerが作動し、(利用者から見て)ランダムにプロセスを強制停止します。
Swap領域に頼る運用はよくありませんが、ないならないに困ったことになりますので、ユーザーデータやスクリプト等でデプロイ後にスワップ領域を作成しておいて上げると安心です。Swap領域はEBSにも作れるのですが、EC2インスタンスストアに作るのがベターではないでしょうか。
RDSの運用
AWSのたくさんある売りのうちの一つ、マネージドサービスのRDBサーバを提供するRDS。マルチAZで冗長化されていたり、バックアップなどをあまり意識しなくても良いとか、すぐに使えるとかいろいろメリットがあるのですが、実務で導入する際には、いくつか注意点があります。
・原則として設定はウェブベースのマネージメントコンソールから作業を行う
・RDSインスタンスへのSSH接続はできない(やり慣れたコマンド、設定手順は使えない)
・SSHでログインできない(⇒監視エージェントのインストールなどもできない)
・運用手法はオンプレ時代と異なる(楽にはなるが手順が変わってくる)
・Timezone関連のパラメータが一部UTCだったり、細かいところで使いたいパラメータが変更できない
・ログの取り扱いが面倒（1時間単位でローテーションしているログが24時間で消えるなど）
上記もどんどん改善もされるでしょうが、ログを処理するために別のインスタンスでシェルスクリプト作ってテストして定期実行させたり、ログ処理用のlamdbaファンクション作って定期実行したり、なんだかんだ楽になったところとしなくて良い苦労に振り回されたり・・ですね。
SMTPの制限
AWSを踏み台にスパムメールを配信する人がいるので、SMTP のアウトバウンドはデフォルトではソフトリミットがかけられています。SMTPのゲートウェイとなるサーバのEIPを決定し、自社のAレコードと対応させてからAWSに申請することでこのソフトリミットが解除されます。
Zone Apex が使えない事例
Zone Apexとは、 tanuki.com などサブドメイン抜きのドメイン名そのものをさしますが、よくウェブサーバでホスト名を付けない短いURLで運用されているのを見かけるかと思います。
| 名前 | 説明 |
|---|---|
| tanuki.com | Zone Apex |
| tokyo.tanuki.com | サブドメイン付き |
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
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で注意したい点をいくつかピックアップしました。