「ガバナンス」「命名規則」「運用ルール」を事前に決めておく　ウェザーニューズはAWSマルチアカウントをどのように運用したか

充実してきたマルチアカウント向けサービス

小野晃路氏（以下、小野）：最初はじゃあどうしようかっていうのもあったんですが、いろいろマルチアカウント向けのサービスが充実してきました。（スライド参照）これは2017年のサミットの資料です。マルチアカウントをやられる方は、こんな構成あるんだって見た方も多いと思うんですよね。私もこれをけっこう参考にしました。

支払いアカウントとか、ロギングとか、セキュリティとかいろいろ書いていますが、「あ、こういうかたちでアカウントを分ければいいんだな」っていうのを知ることができました。そのためには先ほどのOrganizationsや、その中でSCPですね、Service Control Policy、CloudTrail、GuardDuty、Control Towerとかいろいろサービスが出てきたわけですね。

そこで、マルチアカウント向けの対応ができるよねというのが1つ。それから2つ目はネットワーク的なお話です。Transit Gatewayは2018年のリーンイベントで発表されましたよね。オンプレと複数のアカウント間のVPCの接続、これが管理しやすくなるということです。

リーンイベントの2017でDirect Connect Gatewayが発表されて、複数リージョンで閉域、Direct Connect1本使えば接続可能になりました。これはいいサービスだということでDirect Connect Gatewayを準備したんですよね。

2018年末ぐらいに開通するように準備していたら、2018年のリーンイベントでTransit Gatewayが発表されて、もっといサービスが出てきてしまって、ちょっと焦ったんですけど。

これでVPC間の接続が管理しやすくなったので、つい最近ウェザーニューズもこのTransit Gatewayを使った構成をやっと準備できるようになりました。これが2つ目。

IAMユーザーもスイッチRoleも面倒くさい

あともう1つはAWS SSO、Single Sign-Onですね。何回か前のZOZOの光野さんがこれについてお話ししたと思うんですけど、複数のアカウントのログインを一元管理できるサービスです。MicrosoftのADとかを使って一元管理できるのですが、ウェザーニューズはADではなく、G Suiteでアカウント管理をしています。ですから、G SuiteでSAML認証をしようと思ったんですよ。いろいろ試しましたが、実はアカウント間で細かい権限設定が面倒くさそうだなと思いました。

どうしようかと思いましたが、結局はAWS SSOでのユーザー管理を選択しました。でも、今CLIで一覧情報が取れないので、僕的には目先でなんとかならないかなぁと思っています。

たぶんこういう話もみなさん聞かれているかもしれませんが、IAMユーザーとかスイッチRoleとか、そういった方式があると思うんですよね。なぜ選択しなかったかというと、僕なりの結論は、要は両方とも複数アカウント間で入って設定しなくちゃいけないってことです。

IAMユーザーは管理者も利用者側もそのアカウントごとに1個1個設定します。MFAを設定するときに、利用者側は自分のMFAのパスワードがアカウントごとにたくさんできるのが嫌じゃないですか？　私もそうで、ちょっとこれは嫌だなぁっていうのが1つ。

スイッチRoleも入り口のアカウントがあって、そこからスイッチRoleして別のアカウントにっていう構成でできるのですが、結局スイッチRoleもスイッチRoleする先のアカウントに設定をしなくちゃいけないということで面倒くさい。SSOは1つのマスターアカウントで設定管理ができるので、「あ、これは絶対いいや」というところで使っています。

マルチアカウント利用に向けて

次は、実際の運用ではどうしたかという話です。マルチアカウントの運用に向けていろいろなことを検討しました。実は、もともとウェザーニューズの中に運用ガイドライン、標準ガイドが準備できていなかったという背景があります。

そこで、いろいろなところを決めていかなくちゃいけないねっていうときに、AWSのプロフェッショナルサービスを利用しました。要は社内にそんなにノウハウがない。マルチアカウントでクラウド利用を推進していこうってなったときに、短時間でできるかって言うと、それは無理だろう、厳しいというのもあり、プロフェッショナルサービスの利用で時間と質を買うことにしました。

その中で決めていったのが、これからあとの話です。1つはガバナンスの決定っていうところで。AWSを利用するためにガバナンスをガチガチに重視する方法を取るのか。いやいや利用者側にAWSの利用権限をお任せして、そこでやっていく権限委譲型。あとはバランス型。

ガチガチでガバナンスを設定して利用者もガチガチで使うのは、ウェザーニューズという会社には向かないので、これはなし。

では、ユルユルで利用者側にお任せしていいかと言うと、さすがにそれも厳しいだろういうことでバランス型になりました。ガードレール方式ですかね。先ほどのコンフィグの設定をする話と同じなのですが、最低限やっちゃいけないことをルール化したバランス型を選択しています。

あとはですね、アクターの整理っていうのをやりました。これはどんなタイプの利用者がいるかをまとめました。アプリの開発担当、開発の責任者ですね。各事業部の管理者は、事業部ごとにコスト管理をするとかがあると思うので、これも定義しています。

あとは監視を担当する人たち。インフラを管理する、インフラネットワークとかそういったところをやる人たち。それからセキュリティ。AWS全体のコストを見るっていうところ。それぞれの役割の人たちがいて、それぞれに応じて必要な権限セットがあるよねっていうことで最初に定義しました。

アカウントの命名規則を決めておく

また、アカウントを複数作るときの命名規則というのを決めておきました。環境、所属、目的みたいなかたちで。環境っていうのは、要は運用環境なのか開発環境なのかみたいなことですね。

あとは所属チーム。事業部だったりチームだったりっていうので、ウェザーニューズの場合は海関係とか空関係とかいろいろなチームがあるので、そういったチームですね。あとはそのチームごとに、システムごとにもうちょっと細かくアカウントを分けたいニーズもあるだろうということで、システムごとでも分けられるようにしています。

メールもこういったかたちで、メールアドレスの命名規則も作りました。ただメールは、運用アカウントと開発アカウントで結局作ったりすると思いますが、2個も3個も作るのは嫌じゃないですか。

なので、{+env}を使って分けています。メールアドレスは1つだけれど、{+prod}とか{+dev}を付けて、1つのメールアドレスで受け取ることができるようにこの名前の付け方をしています。

あとはですね、VPCの払い出しCIDRの検討というところです。オンプレとかほかのVPC、ほかのチームとのデータのやり取りとかっていうのがあるので、VPCのCIDRがバッティングしないように、そこはインフラ管理、ネットワーク管理チームがどのCIDRを払い出すかを決めて割り振ることを今やっています。

マスターアカウントの管理

あとはマスターアカウント、ここらへんの管理のところです。インフラ側としてはマスター、それから基盤管理、それからセキュリティ、ログみたいなかたちのアカウントで分けています。利用者側は運用とか開発、検証、こんな感じのアカウントを作っています。

あとネットワーク構成ですね。ちょっと（スライドには）簡単に書きすぎているんですけど。オンプレがまだまだありますので、オンプレ環境とデータのやり取りがあります。先ほどTransit Gatewayという話をしましたが、若干Transit Gatewayの推進コストが高いというのもあって、データの配信周りに関してはDirect Connectでまずはデータ配信用のVPCにオンプレから送ります。

必要な別のシステムに関してはVPCピアリングをしてデータを送っています。そうは言ってもこのままだとシステムごとのアカウントがオンプレとは疎通できなくなってしまうので、こういったところをTransit GatewayとDirect Connect Gatewayをつないだかたちのネットワークでオンプレとも一応通信できるようにしています。

ここに共通基盤と書いてあるのは認証周りや、あとは社内のDNSを引くっていうところを、ここの、Route 53のDNSフォワーダをこちらに設定して社内のIPを引けるようにっていう構成にしています。