AWS: 請求代行の個別アカウントからOrganizationsへの移行検討

概要

部署で古くから請求代行サービスで管理されていたAWSアカウント群を会社契約の AWS Organizations へ移行検討をしている話です。検討時の

• 検討概要
• 想定外だったこと

について書いていこうと思います。

私の立場としては会社内のいち部署で情シス的な業務をしています。会社全体の情報システム組織は別に存在して、そちらから部署環境の移行に関しての相談と検証を依頼されたという経緯です。

現在も検証継続中で検証中の状態はAWSベストプラクティスに沿ってない部分などがあるのですが、対応を進めていっています。

移行元環境：請求代行サービス配下の個別AWSアカウント群

移行元は請求代行サービス配下の個別AWSアカウント群で以下のような状態でした。

• 組織・rootアカウント
  • 所属組織は請求代行サービス提供会社の組織
  • 各AWSアカウントのrootアカウントは請求代行サービス提供会社が保持
• サービス・利用管理(請求代行サービス提供会社のポータルでの対応)
  • 料金管理周り（例：金額確認、予算アラート、請求書取得)
  • 請求書払い。クレジットカード払いと支払いタイミングが違う
  • AWSアカウントの作成/削除
  • サポート、制限緩和、一部操作
• AWSアカウント・ユーザ設定
  • AWSアカウント引き渡し時に一部アカウント、監査・セキュリティ系の設定有
  • ユーザアカウントはJumpアカウントからのスイッチロール方式(部署で設定)
• 特典・付帯サービス
  • 利用料割引有り
  • クラウド保険付き

上記の状態で私は主に以下の業務をしていました。

• 請求代行サービス提供会社のポータル管理
• 同ポータルでの申請・問い合わせ代行
• Jumpアカウントの管理
• 部署のAWSユーザアカウントの管理

上記の業務都合上、全AWSアカウントに最低 ReadOnlyAccess の権限がありました。

移行先(予定)環境：情報システム部署管理のAWS Organizations

情報システム部署のAWSアカウントが入っていたものの、他の部署のAWSアカウントはない状態でした。つまりまだ AWS Organizations におけるマルチアカウント管理ポリシーは作られていない状態でした。

移行検証にあたって

AWS Organizations における管理アカウントは情報システム部署が管理、他部署のアカウントはメンバアカウントとすることは異論のないところでしたが、諸々決めなければいけない事がありました。

• ある程度目途がついたもの
  • 請求代行サービス提供会社が担当していた役割/機能を誰がどこまで担当するのか？
  • 移行作業にあたっての要考慮事項は何なのか？
• 議論継続中のもの
  • 組織管理は誰がどこまでやるのか？
  • 部署のメンバアカウント群の部署側管理者にはどこまで権限を付与するのか？

議論継続中のものは一度に対応するには量が多く、また、今後の管理・運用業務も増えるため検証を元に徐々に決めていっている状態です。

今回はある程度の目途がついた内容について記載します。

請求代行サービス提供会社が担当していた役割/機能について

情報システム部署と各部署での対応に分ける案で検証を進めることにしました。

• 情報システム部署の対応事項
  • 組織・rootアカウントの管理
    • 所属組織は情報システム部門の組織
    • メンバアカウントの root アカウントは管理アカウントからの一元管理にする
  • サービス・利用管理
    • AWSアカウントの作成/削除は社内承認管理のシステムで対応
  • AWSアカウント・ユーザ設定
    • アカウント、監査・セキュリティ系の設定
• 各部署の対応事項
  • サービス・利用管理
    • 料金管理周り（例：金額確認、予算アラート、請求書取得)は一旦各部署での対応
    • 請求書払いの対応
    • サポート、制限緩和申請はAWSに直接依頼
  • AWSアカウント・ユーザ設定
    • アカウント、監査・セキュリティ系の設定
    • ユーザアカウントはJumpアカウントからのスイッチロール方式(部署で設定)

双方の対応に「アカウント、監査・セキュリティ系の設定」が入っていますが、組織で集約するものはお互いに何を設定して何がどこで見えてどう通知になるのか、というところが分かっていなかったので一旦そうなりました。

また、検証の段階では全社利用の IdP との連携コストが見込めなかったので AWS Identity Center を有効にはせず、ユーザアカウント管理は既存の部署ごとの管理を踏襲することになりました。

移行作業にあたっての要考慮事項

検討した内容は多くあるのですが、事前に想定していなかった内容を3つ挙げます。

移行当月の請求発生個所

今回の移行では

• 請求代行の組織配下
• スタンドアロンアカウント(移行先に移管するまでの一時的な状態)
• 移行先の組織配下

の順での移行になります。

請求代行の組織配下からの転出のさいに有効な請求先を設定する必要があるのですが、今回の検証では以降の月は以下3か所からの請求が発生しました。

アカウントの状態	請求先
請求代行の組織配下	請求代行組織の請求設定先
スタンドアロン	アカウント転出時に設定した請求先
移行先の組織配下	移行先の組織の請求設定先

にはスタンドアロン状態なのが同時間内であればスタンドアロンの請求先には請求されない記載があるのですが、アカウントごとに時間を合わせて対応するのは難しいケースもあるように思います。

ただし、請求代行サービス提供業者ごとに今後の対応が異なる可能性はありますが、アカウント転送機能が追加されたので、今後この問題は緩和される可能性があります。

AWSからのメール通知の送信先

アカウント転出時に連絡先を入力するのですが、いくつかの通知はrootアカウントのメールアドレスにしか届いていないようでした。気が付いたのは AWS Marketplace に関する通知で他にもあるかもしれません。請求代行サービスを利用していたときはサービス側がハンドリングしてくれていて気が付かなかったのだと思います。

元々メンバーアカウントの各部署担当者への連絡はアカウントに登録する連絡先メールアドレスの想定だったのですが、rootアカウントのメールアドレス(会社のグループウェアのML)に追加する対応に変更する必要がありそうでした。

他組織から転入してきたメンバーアカウントの管理者に対する制約の設定

今回のメンバーアカウントは他組織から転入してきたものなので、それぞれのアカウントに管理者がいます。

また、最初から現在の組織にいたわけではないので、組織の管理アカウントからアクセスするためのIAMロールを個別で作成する必要があります。何もしないとこのIAMロールは元の管理者が削除できてしまいます。

先述した通り、組織の管理方針が定まっていない状態ではありますが、アカウントの管理設定・請求関連の設定と合わせてサービスコントロールポリシーを使って制約を付ける必要があるという理解です。

おわりに

なかなか進まないことも多いのですが、コスト・アカウント管理・セキュリティ統制など多方面で対応が必要な内容を含んでいるので頑張って進めていこうと思います。