東京リージョンに新たにアベイラビリティゾーンを追加 | Amazon Web Services
というブログが2018-01-25に出ていました。執筆日(2018-01-25)現在、本家の https://aws.amazon.com/blogs/ には同様の記事はないようです。
既に2AZ使えている環境の場合の確認方法
$ aws ec2 describe-availability-zones --output text
AVAILABILITYZONES ap-northeast-1 available ap-northeast-1a
AVAILABILITYZONES ap-northeast-1 available ap-northeast-1c
AVAILABILITYZONES ap-northeast-1 available ap-northeast-1d
-> ap-northeast-1a/ap-northeast-1cが使えていた場合、ap-northeast-1dが追加されるようです。そのため、3AZsでコンピュートができるはずです。
既に3AZ使えている環境の場合の確認方法
$ aws ec2 describe-availability-zones --output text
AVAILABILITYZONES ap-northeast-1 available ap-northeast-1a
AVAILABILITYZONES ap-northeast-1 available ap-northeast-1b
AVAILABILITYZONES ap-northeast-1 available ap-northeast-1c
AVAILABILITYZONES ap-northeast-1 available ap-northeast-1d
-> ap-northeast-1a/ap-northeast-1b/ap-northeast-1cが使えていた場合、ap-northeast-1dが追加されるようです。が、いつも通り、実務上はVPCで使えなかったAZは引き続き使えないので、3AZsでコンピュートすることになるようです。
4AZ導入後の新規アカウント
ap-northeast-1a, ap-northeast-1b, ap-northeast-1c, ap-northeast-1dの中か3AZsが利用可能になるのか、ap-northeast-1dは必ず含まれるような具合になるのかは試せていないので分かりませんが、確認しておきたい要素ではありますね。
課題
(1) 参照できないケース
$ aws ec2 describe-availability-zones --output text
Could not connect to the endpoint URL: "https://ec2.ap-norheast-1.amazonaws.com/"
というようにコケるAWS Accountがあるようです。AWS, AWS CLI, AWS SDK, Amazon EC2, Amazon VPCのいずれも詳しくないので、時間が経つのを待っていれば解決するのかアカウントの問題なのか分かりませんので、しばらく待つことにします。
(2) 4AZs
Web console (Amazon Web Servicesの用語ではManagement Consoleと表現される気がする) では、上記のCLI (API) をコールしているため、
となってしまうので、誤って使えないAZを選んでしまうと
というようなら、エラーに遭遇してしまう。
「既に3AZ使えている環境」=「これから4AZ使えそうに見える環境」の方は従前通り注意が必要です。と言っても、Management Consoleから触ってVPC/Subnetを構築する人はいないので、多分誰も困らないでしょう。
これにより実現できること
これでようやくAWS Tokyo (ap-northeast-1) で3AZないと高SLAが実現できないアプリケーション・ソフトウェアが動かせる日がやってきました。
Google Cloud Platform (GCP)のGCEでのasia-northeast-1では2016年秋より使えていましたので、私の状況としてこちらで困っていませんでした。最近になって、AzureでもAzure AZが2017年末頃から提供開始されていたよう（伝聞）なので、AWSでも（少なくとも結果的に）それに追従する形で実現に至ったようです。
今後も積極的に3AZを活用したコンピューティングで高可用性を実現していきたいと思える瞬間でした。