AWSで複数環境運用のベストプラクティスを紹介！マルチアカウントで安全に環境を運用しましょう😎

AWSクロスアカウント AWSサーバーレス特集 AWSセキュリティ

2021.03.19

この記事は公開されてから１年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは！

みなさま、AWS でマルチアカウントをうまく活用できておりますでしょうか？今回はマルチアカウントな運用方法にどのぐらいのメリットがあるのか、ベストプラクティスをご紹介しながら語っていきます！

読み応えたっぷりですのでぜひ最後までお付き合いください！

想定する読者

これからマルチアカウントでの運用を考えている管理者
複数の AWS アカウントを利用するメリットを知りたいヒト
本番環境への影響を最小限に抑えたいヒト
ユーザー管理を楽にしたいヒト

はじめに

マルチアカウントのメリット/デメリット

マルチアカウントで AWS を運用するのって何がお得なの？と思われる方もいらっしゃるのではないでしょうか？

そのためマルチアカウントを語る前に、いくつかのメリットを確認しておきましょう。

メリット

各環境ごとに AWS アカウントを用意するため、本番環境などに対するヒューマンエラーが起こりにくい
1年無料枠の恩恵を各アカウントで受けられる
アカウント単位で制約（ポリシー）を作れる
各 AWS アカウント内にわざわざユーザーを作らなくて良い（ SSO ユーザーを利用）
アクセスキーをユーザーに管理させないので、社員が退職などで会社との関係がなくなったあと、 AWS を不正利用しないようにできる
一括請求が可能となる（ルートアカウントに請求が行われる）

管理が楽になったり、セキュリティが向上したりすることが、マルチアカウントを運用する主なメリットになります。

では次にデメリットにも触れてみましょう。

デメリット

管理するアカウントが増える
アカウント跨ぎのリソース操作および連携を行う必要性が出てくる
運用方法を誤ってしまうと、余分なリソースを作成してしまう
上限緩和申請は各アカウントごとに行わなければならない
１アカウントにつき、１メールアドレスが必要（ AWS ControlTower は１つのメールアドレスで運用可能、後述）

複数の AWS アカウントを運用するので、当然のデメリットとなります。これらを事前に理解したうえで、マルチアカウントの運用を考えていきましょう。

マルチアカウントにおける三種の神器

ベストプラクティスを語る前に、マルチアカウントの運用で利用する3つの AWS サービスをご紹介させてください！

この3つをうまく活用することがある種のベストプラクティスにもなりますので、ぜひひとつずつお読み頂ければと思います。

AWS Organizations

組織のすべてのアカウントを一元的に管理、組織フォルダを作成し、その配下にアカウントを作成していく形で管理する。最大5つの階層まで作成できる。
一括請求を利用できる(ルートアカウントが支払う)
複数の AWS アカウントに対してポリシーを適用できる(サービスコントロールポリシー)
AWS Single Sign-On、CloudFormation StackSetsが利用できる

AWS Organizations はマルチアカウントの管理に必須の AWS サービスです。これを利用することにより、一括請求の管理、AWS アカウントの組織化、アカウント単位のポリシー設定を行うことができます。

また、AWS Single Sign-On や CloudFormation StackSets を利用するには、AWS Organizations を有効にしていることが前提条件となりますので、マルチアカウントの管理において必要不可欠の存在となります。

AWS Single Sign-On（AWS SSO）

複数のアカウントにシングルサインオンできる( AWS Organizations で管理しているアカウントのみ対象)
各アカウントに IAM ユーザーを作成する必要がなくなる、SSO ユーザーによって各アカウントへのアクセスが可能
権限セットを利用して、アクセスコントロールが可能
グループやユーザーごとにアクセスできるアカウントを選択することができる

AWS Single Sign-On、以下略して AWS SSO は、その名の通り複数の AWS アカウントなどに対してシングルサインオンを行うことができます。もちろん AWS 以外のサービスにも利用することができます。

マルチアカウントで運用する場合のユーザー管理に必須のサービスとなります。具体的なベストプラクティスは後述いたします。

CloudFormation StackSets

1つの CloudFormation テンプレートを複数のアカウントにデプロイできる
各アカウントに共通して必要な IAM ロールや ACM などのリソースがある場合などに利用する

各アカウントごとに必要なリソースを手動で作成するのは少々面倒です。そんなときに CloudFormation StackSets を利用します。これを用いることで、各アカウントに必要な共通のリソースを簡単にデプロイできます。

ベストプラクティス集

それではマルチアカウントの運用におけるベストプラクティスをご紹介いたします。ぜひ参考にしてください。

アカウントは目的ごとに作成する

AWS Organizations は組織( OU )を作成して、その配下に AWS アカウントを置くような形で組織ディレクトリを作成していきます。組織ディレクトリは最大 5階層まで作成することが可能です。

キューブのアイコンが AWS アカウント
一番下の AWS アカウントはルートディレクトリ直下

この組織ディレクトリを設計するうえで大切なのが、AWS アカウントを目的ごとに作成するということです。例えば、本番・開発などの環境別に作成したり、組織の部門別に作成したりします。

リソースが増えて誤ってほかのリソースを操作しそうだからもうひとつ作ろう、コストを節約するためにチーム内で3つぐらい持っておこう、こういった考えは望ましくありません。

SSO ユーザー管理のタスクが余計に増えたり、AWS アカウントごとの目的がよくわからないまま運用してしまったりするため、AWS アカウントは必ず目的に応じて作成しましょう。

各 AWS アカウントに個人が利用する IAM ユーザーは作成しない

マルチアカウントでは、AWS SSO ユーザーを利用することがベターです。これには主に2つの理由があります。

1つ目は、ユーザー管理を複雑にしないためです。AWS SSO を有効にした状態では IAM ユーザーを作成しなくても、AWS SSO ユーザーでユーザー作成やアクセス管理ができるので各アカウントでの IAM ユーザーは不必要となります。

権限セットと呼ばれるロールやグループにユーザーを分けることで、アクセスできる AWS アカウントに制限を加えたり、必要な権限を制限できたりするので、マルチアカウントの運用では AWS SSO を主に利用しましょう。

2つ目は、個人にアクセスキーを持たせないためです。通常 AWS アカウントでIAM ユーザーを作成すると、個人の操作でアクセスキーを作成できます。ですがこの運用方法では、アクセスキーを不正利用されてしまう可能性を残してしまうことになります。例えば、社員が退職したあとに管理者が IAM ユーザーを削除し忘れていた場合、作成したアクセスキーは有効のままですので危険です。

この問題を解決するのが AWS SSO でのユーザー管理となります。AWS SSO では以下のようにユーザーに対して一時的なアクセスキーを発行します。

AWS SSO はマネジメントコンソールまたは CLI でのアクセスのどちらかを選択できます。
上記は CLI でのアクセスを選択したときに表示される画面です。

このアクセスキーは最大で12時間の有効期限を設定できます。運用上、毎回 AWS で作業するたびに認証情報のセットが必要となりますが、セキュリティ向上のメリットもあります。

CloudFormation StackSets を利用する

例えば CloudFront で HTTPS を利用する場合、ACMが us-east-1 リージョンに1つ必要です。すべてのアカウントで CloudFront を利用する場合、すべてのアカウントにひとつずつ ACM が必要ということになります。

こういった各アカウントで共通しているリソースなどは積極的に Cloud Formation StackSets を利用して、手動での作成を回避しましょう。なおデプロイ先の AWS アカウントは選択できますので、その点はご安心ください。

また serverless framework や Terraform などを利用している方は、各環境ごとに必要なものはすべてデプロイしているので必要がないという場合もあります。

そのため何を CloudFormation StackSets で作成するのかは、マルチアカウントの運用ルールを決めてから利用したほうがよいかと思います。作成前に AWS リソースのコード管理について整理しておきましょう。

サービスコントロールポリシー( SCP )を活用する

AWS Organizations にはサービスコントロールポリシー(以下、SCP )と呼ばれるアカウント単位でのポリシーがあります。これを活用することでヒューマンエラーを防ぐことが可能です。

例えば、東京リージョン以外でリソースを作成させたくない場合などには、以下のように制限をします。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAllOutsideEU",
      "Effect": "Deny",
      "NotAction": [
        "cloudfront:*",
        "iam:*",
        "route53:*",
        "support:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": [
            "ap-northeast-1"
          ]
        }
      }
    }
  ]
}

このようにして作成した SCP を、アカウントや組織( OU )ごとにアタッチすることで AWS アカウント内での操作を制限することが可能となります。なお、組織( OU )にアタッチした場合は、配下の AWS アカウントすべてに適用されるので注意してください。

また例え Administrator のアクセス権限が割り当てられているユーザーであっても、SCP の内容が優先されますので、その点も踏まえて制限を設けるようにしましょう。

Route53 で各環境のホストゾーンをまとめて管理する

利用されている環境にもよりますが、Route53 を利用している場合に複数のAWS アカウントで同じ Route53 のホストゾーンが必要な場合などがあると思います。そんなときはメインの Route53 のみにホストゾーンを作成し、各アカウントで作成したリソースのレコードを登録することで運用していきましょう。

以下の図をご覧ください。

上記のようにメインの AWS アカウントの Route53 にレコード登録を集中させることで、各アカウントで Route53 を利用することができます。

設定方法は簡単です。特別なことは何もせずに、別アカウントで作成した AWS リソースのレコードを、Route53 に登録するだけです。

上記の図で言うと、dev1 環境に作成した CloudFront と ACM のレコード情報を控えたあと、prd 環境の Route53 でレコードを作成します。これにより設定したドメイン名にトラフィックが通るようになります。

Route53 は外部のレコードも登録できるので、アカウント内に登録する AWS リソースがなくてもレコード情報が間違っていなければ問題ありません。

番外編：AWS ControlTower について

記事の執筆時点では、東京リージョンで利用できませんが、マルチアカウント運用のベストプラクティスを知らなくても簡単に作成できる AWS サービスがあります。それが AWS ControlTower です。

簡単にまとめると以下のような特徴があります。

ベストプラクティスに従って自動でマルチアカウント環境を作成してくれる
デメリットは自動でやってくれることが多すぎて、必要のないものまで作成される可能性があること

自動でマルチアカウント環境を作成してくれる！といえば聞こえはよいのですが、作成されるリソースやマルチアカウントの設計をある程度理解していないと、知らぬ間に不要なリソースを持ってしまい余分にコストがかかってしまう可能性がありますので、その点はご注意ください。

ここで述べている不要なものというのは、ログアーカイブ用と監査用の AWS アカウントを作成したり、いつくかのルール( AWS ControlTower ではガードレールを指す)を作成したりすることを指しています。

東京リージョンにまだ対応していないことと、マルチアカウント運用への理解および AWS ControlTower への理解が必要なことから、現時点においては慎重に検討されたほうがよいかと思われます。こちらは今後のアップデートや東京リージョンの対応に期待ですね。

まとめ

今回はマルチアカウント運用についてのナレッジを出し惜しみせず執筆いたしました。ぜひ参考にしていただければ幸いです。

このブログでは、マルチアカウント運用以外にも、AWS のサーバーレスサービスについての記事をどんどん公開しておりますので、ご興味のある方はほかの記事もご覧いただければと思います。

マルチアカウントの運用に関する設計は、お気軽にお問い合わせください。

AWS サーバーレスの開発でお悩みなら
ラーゲイトまでご相談ください

開発前の懸念やサーバーレスの不明点、小さな悩みまでお気軽にご相談ください

お問合せはこちら

目次

AWSで複数環境運用のベストプラクティスを紹介！マルチアカウントで安全に環境を運用しましょう😎

想定する読者