AWSライトユーザーのbabaです。
AWS Organizationは大変便利な機能ですよね。一括請求ができるため、以下のようなメリットを得られます。
- アカウント単位で分離されるため、IAMで個別に設定するよりも、セキュリティ面や操作ミス対策を強固にできる。
- アカウント単位で請求書を出せるため、正確な金額の把握や、受託案件でお客様にサーバ実費を請求するのもやりやすい（コストタグは手間がかかる割に転送料金など配分できない要素が多く、コストの把握には不十分）。
OrganizationAccountAccessRoleでユーザ切り替えできるため、細かくアカウントを分割しても、毎回ログアウト→ログインする必要もなく操作性が良い。- 個別のアカウントにクレジットカードを登録しなくても一括請求できるので、管理上会社のクレジットカードを持てないメンバーにアカウント管理権限ごと預けることが容易。
また、簡易的な利用では、 OrganizationAccountAccessRole を使うだけで、rootユーザのパスワードを設定しないまま運用できるのも地味に便利です。rootユーザにはMFAを設定したくなりますが、アカウントの数だけ登録しているとGoogle Authenticator (Authy好きじゃないんです) がいっぱいになってしまいます。
最近（ようやく）CloudFrontの署名付きCookieを発行するための公開鍵登録にroot権限が不要になったので、随分rootが必要なケースが減りました。
⚓ 自分の運用
BPSでは、件数が多い受託開発ではお客様のAWSアカウントを使うことが多いため、自社サービスや開発用が中心で、管理しているアカウント数はそれほど多くありません（2桁に余裕で収まる程度）が、それでもこの機能なしではやっていけない程度には便利に使っています。
アカウントの切り替えも簡単
マネジメントコンソール右上の切り替えは、直近5件しか履歴が出ないので、以下のようなURLをアカウント数分だけブラウザブックマークに入れています。
https://signin.aws.amazon.com/switchrole?account=000000000000&roleName=OrganizationAccountAccessRole&displayName=sub-account1&color=99BCE3
⚓ 気になる点
大変便利なOrganization機能ですが、運用していくと細かい不満も色々でてきます。
⚓ 無料利用枠が使えない
AWSはやたらと強く無料利用枠を宣伝してきますが、これはOrganizationで一括請求をしている場合、全体で1アカウントとみなされます。そのため、1年以上運用している組織では、新規アカウントであっても大半の無料利用枠が使えなくなります。
また、無期限無料の利用枠も共有されるため、たとえばCloudWatch-Defaultのダッシュボードを作っただけで3ドル請求されます。少数のサーバのメトリクスを監視する程度ならほとんど無料枠内だろう、と思って油断すると馬鹿にならない金額になるので注意が必要です。
一括請求を有効したアカウントを作るとこんなメールが来る（しかも無料利用枠のページには一括請求の制限が書いていない）ので無料利用枠が使えそうに見えますが、騙されてはいけません。
仕様としてそういうものであること自体はまあ良いのですが、宣伝方法は誇大広告なので改善を期待したいところです。
現時点で取れる対策：無料利用というキーワードを脳内NGワードで無視するようにしています。
これらの表示は脳内フィルタで無視する
⚓ RIやSavingPlansを共有すると、実コストの把握が困難になる
デフォルトでは、マスターアカウントで購入したリザーブドインスタンス(RI)やSaving Plansはメンバーアカウントに共有されます。これにより、各アカウント内では使用量にばらつきがあるケースでも、全体を通した使用量で効率的にRI/SavingPlansを購入できるため、素晴らしい仕組みに見えます。
ただしこの方法を取ると、当然なのですがマスターアカウントに大量の請求がかかり、メンバーアカウントは安くなります。各アカウントごとにかかったコストが曖昧になるため、AWSアカウント分離のメリットの1つが失われてしまいます。
コスト計算のために以下のどちらかが実現できれば良いのですが、
- A) 割り引かれたRI/SavingPlansの利用料金を、実際のアカウントごとの適用分で案分する
- B) 各メンバーアカウントで、割引適用前の「定価の」コストを求める（割引額は全体での節約分と考え、個別コスト計算では考慮しない）
Aは前払いがあるので実現不能です。
Bはできそうに見えますが、実際にやろうとするとかなり大変です。まず、RI/SavingPlans適用前の料金は、Cost Explorerや請求書で確認することはできません。AWSサポートに確認したところ、以下の方法を案内されました。
⚓ 方法1. 請求書の明細から手計算する
「アカウント毎の料金明細」タブをクリックすると、アカウント単位でRI が適用された時間とインスタンスタイプが確認できるので、これを料金表と照らし合わせて自分で計算する。
これを1個ずつ計算する
まあ、やればできると思いますが、正直やりたくないです。
⚓ 方法2. コストと利用状況レポート (CUR) を使う
海外の担当部署に確認とのことで、2週間近くかけて満を持して案内された方法です。
コストと使用状況レポート(CUR)を使うと、詳細なログがS3に記録されるので、 pricing/publicOnDemandRate と pricing/publicOnDemandCost を元に計算すれば金額が求められます。
この方法の大きな欠点は、「金額を計算するためにCURを使うとS3にデータが保存されるため、その利用料金が発生する」「データは非常に細かいログ形式なので、計算するスクリプトを組まないと利用は困難」という点です。
ただコストを知りたいだけで、なんでこんな負担を追わなくてはならないのか...
これを処理するスクリプトを自分で書く
複数アカウントで孤立的にRIを運用できるメリットよりも、コストが隠蔽されて解約忘れのリスクが増えるデメリットが上回ると感じています。というか、方法1は面倒なのでより良い方法を2週間かけて探してくれたらしいけど明らかに方法1より面倒ですね。
現時点で取れる対策：良い運用が作り出せるまで、当面マスターアカウントでRIを買うのはやめようと思います。
※なお、「Billing の設定」→「RI と Savings Plans の割引共有」から、メンバーアカウントごとに共有有無の設定は可能です。特に、受託案件で実費を請求する約束になっている場合など、正確な把握が必要な場合は無効化しておくと良いでしょう。
⚓ クレジットの共有をすると、実コストの把握に手間がかかるようになる
AWSでクレジット（クレジットカードではありません）を登録することがあると思います。たとえば、AWSパートナー登録では一定数のみクレジットが受け取れます。ケースによりますが、これは事実上前払いデポジットのようなものと考えられます。
一括請求のマスターアカウントにクレジットを登録すると、メンバーアカウントの利用分も含めてクレジットから消費されていくようになります。
問題は、クレジットを登録すると、請求書に記載の金額が「クレジット適用後の金額」になってしまうことです。確かにAWSからの「請求書」としてはそれで正しいのですが、前払いを消費しているのであってコストが安くなったわけではないので、各アカウントの費用としてはクレジット適用前を知る必要があります。特に、受託案件で実費を後日請求するようなアカウントでは、実際に発生したコストを請求できないと赤字になってしまいます。
AWSサポートに確認したところ、以下の2つの方法があることがわかりました。
⚓ 方法1. 請求書を展開する
メンバーアカウントにログインして請求書を表示し、印刷用に展開すると、 注意: クレジットの $000 が請求書の各製品に適用されました と表示されます。これを請求額に加算することで、実際にかかったコストを知ることが出来ます。
確実な方法ですが、メンバーアカウントごとにアカウントを切り替えてこの手順を繰り返す必要があり、多少手間がかかります。
⚓ 方法2. Cost Explorerを使う
コストエクスプローラーでは、「料金タイプ」→「クレジット」を切り替えることで、クレジット適用前後のコストを表示できます。また、アカウント単位でグルーピングもできるため、概要の把握にはこれが最も便利です。
設定で切り替えができる
ただしこの方法、計算誤差が発生します。Cost Explorerと実際の請求では計算方法が違う（実際の請求は0.01USD単位で切り上げや丸めが行われる）ため、数円程度の誤差が発生します。問い合わせたところ「正確な金額を知る必要があるケースではCost Explorerは使わないように」との回答をもらったのですが、普通仕事なら金額は正確にしないとまずいでしょう...
また、些細なことですが、Cost Explorerの表はtableタグが不思議な作りなのでコピペしづらく、CSVダウンロードすると行と列が逆になるので、地味にストレスが溜まるんですよね。
なお、RI/SavingPlansと違って、クレジットはメンバーアカウント単位で共有有無を切り替えることはできません。全メンバーアカウントに対して共有を止めるのはBillingの設定ページでできるのですが、一部のアカウントだけ止めることが出来ないため、受託案件で実費を後日請求するスタイルのアカウントが混ざっていると、運用が面倒になります。
⚓ 営業メールがたくさん来る
アカウントの数だけ、re:Inventなどの営業メールがたくさん届きます。Unsubscribeすれば良いのですがたくさんあると面倒で、毎回後回しにしてしまいます。
⚓ 終わりに
どれも「そういうもの」と言われればそれまでですし、各種APIが整備されているのだから開発者なら自動化して仕組みを作るべきだというのも正しいと思います。
ただ、AWSは所詮1ベンダーのサービスですし、利用者として声を上げていくことも必要なはずです。
個人的な感覚として、AWSは基本的にボトムアップ的な、提供側の都合でまずサービスが開始され、ユーザのフィードバックを受けて改善していく印象があります。例えばLambdaとRDSをそれぞれ提供しておいて、組み合わせるとコネクション数が溢れて相性が悪いという問題について、しばらく「EC2でコネクションプールするインタンスを立てる」というどう考えてもバッドノウハウとしか思えない（マネージドのメリットどこいった）方法が色々紹介されていた時期もありましたが、しばらくしたらRDS Proxyという解決策が提供されました（RDS ProxyがAuroraのリーダーエンドポイントに繋げないという欠陥も、遠くないうちに対応されるでしょう）。
この「最初は不完全でも改善していける」というのがAWSの良いところだと思っていますので、改善に期待しています。
CloudWatch Eventが重複起動することがあるひどいバグも、いい加減さっさと直してほしいです。これを仕様と言い張るのはだめでしょう。
