AWSアカウントに関しては、多ければ多いほど良いという傾向があります。同じ組織に複数のアカウントを作成することで、リソースの分離、チームの分離、コンプライアンス管理などの分野で様々なメリットが得られます。
しかし、複数のAWSで運用することは、いくつかの険しい課題ももたらします。バックアップとリカバリ、ネットワーク構成、IAMセットアップのようなタスクの処理に苦労することなく、AWSへのマルチアカウントアプローチの利点を享受したいのであれば、これらの課題を管理するための計画を持つことが重要です。
複数のAWSアカウントを設定する理由と、マルチアカウントAWS戦略に伴う課題を克服する方法についてのガイダンスになればと考えます。
目次
AWSアカウントの理解
まず、Amazon Web Services(AWS)クラウドにおけるアカウントの仕組みと、AWSが複数のアカウントを管理するためにサポートする組織構造の種類について、基本的なことから説明です。
AWSでは、アカウントはクラウドリソースを作成、管理できるエンティティです。デフォルトでは、1つのアカウントはそのアカウントにリンクされたリソースのみをコントロールできます。つまり、あるアカウントでログインして、別のアカウントが所有するクラウドリソースを変更することはできません。
AWSでは、企業が複数のアカウントを作成することができます。オプションとして、企業は複数のアカウントをOU(Organizational Unit:組織単位)にまとめることができます。OUにアカウントを割り当てると、OUレベルですべてのアカウントにポリシーを適用できます。
さらに、AWSはランディングゾーンという概念をサポートしている。1つのランディングゾーンに複数のOUやアカウントを含めることができる。ランディングゾーンは、マルチアカウント環境を集中管理するもう一つの方法である。ランディングゾーンは、OUだけよりもポリシーの割り当てをよりきめ細かく制御することができる。
AWSにおけるアカウントの仕組みや、同じ組織内で複数のアカウントを管理するためにAWSがサポートしているエンティティの種類などの詳細については、このトピックに関するドキュメントを参照してください。
複数AWSアカウントのメリット
組織に複数のAWSアカウントを作成することを義務付けるルールはありません。必要であれば、アカウントを1つだけ設定し、チーム全員で共有することもできます。
しかし、AWSリソースを作成・管理する従業員がほんの一握りでない限り、複数のAWSアカウントを作成した方がメリットがある可能性が高くなります。複数のアカウントを自由に使えるようにすることで、様々な利点が生まれます。
リソースの分離
おそらく複数のAWSアカウントの最も明白な利点は、リソースを分離できることです。これにより、悪意のあるユーザや侵害されたアカウントが潜在的に引き起こす可能性のある害を減らすことができます。また、アクセスすべきでないユーザによるリソースの偶発的な変更や削除を防ぐのにも役立ちます。
例えば、互いにクラウドのリソースにアクセスする理由がない2つの別々のエンジニアリング・チームがある場合、それぞれのチームに別々のアカウントを設定することで、グループが互いの業務を妨害することがなくなります。
さまざまなレベルのセキュリティ管理
複数のアカウントを作成することで、組織内のさまざまなユーザーやグループに対して、それぞれのニーズに応じて異なるセキュリティ・ポリシーを定義できます。
例えば、財務部門が所有するクラウドリソースにはより機密性の高いデータが含まれる可能性があるため、アプリケーションの構築やテストを行う開発者が管理するリソースよりも厳しいセキュリティ管理が必要になります。
きめ細かなコンプライアンス管理
これと同様に、コンプライアンス指令は、組織内のさまざまなグループにさまざまな形で影響を及ぼす可能性があります。たとえば、欧州連合(EU)に拠点を置く部門は、GDPRによって、同等のコンプライアンスルールがない法域で活動する部門よりも厳しいコンプライアンス義務に直面する可能性があります。この場合も、複数のアカウントを設定することで、各グループが適切なレベルのセキュリティやその他の管理を受けるようにすることが容易になります。
コスト追跡
デフォルトでは、AWSはアカウント単位でクラウドの請求データを報告します。つまり、組織内の異なるユーザグループに対して複数のアカウントを持っている場合、各グループのクラウド支出を簡単に追跡することができます。
クラウドコストを監視するためのツールは他にもありますが、アカウントレベルでコストを分解することは、全員が同じアカウントを共有する場合よりも詳細な請求に関する洞察を得るための簡単な方法です。
低リスクのクラウドテスト
複数のアカウントを持つことで、テストや実験を行うワークロードと、安定稼働が必要なワークロードを分けることができます。例えば、複数のAWSアカウント(1つは本番用、もう1つは開発/テスト用)を作成することで、開発チームは新しく構築したアプリケーションを本番環境に移行する前にテストできる環境を構築できます。
確かに、ネットワークレベルで分離するなど、AWS上でワークロードを分離する方法は他にもあります。本番環境と開発/テスト環境を区別するために、必ずしも複数のアカウントが必要なわけではありません。しかし、複数アカウントはそのレベルの分離を達成するための1つの方法であり、かなり簡単で確実なソリューションです。
複数のAWSアカウントの課題
一方で、複数のAWSアカウントを維持することにはデメリットもある。主な課題は以下の通りです:
データのバックアップとリカバリ: 複数のAWSアカウントにまたがるデータのバックアップとリカバリーの方法を見つけるのは難しいかもしれません。すべてのアカウントからデータをバックアップする方法を見つける必要があります。場合によっては、あるアカウントのデータを別のアカウントでリストアする必要があるかもしれません(最初のアカウントがハッキングされた場合など)。このような作業は、マルチアカウント・シナリオ用に設計されていないデータ保護ツールを使用している場合、特に困難になる可能性があります。
ネットワーク・ポリシーの管理: 多くの場合、AWS内の異なるアカウントで作成されたリソースが相互作用できるようにしたいものです。そのためには、あるアカウントから別のアカウントにデータを移動できるようにするネットワーク設定が必要です。しかし、アカウントが重なりすぎないように、ネットワークの分離を強制したい場合もあるでしょう。その結果、マルチアカウント戦略でのネットワーク管理は非常に複雑になる可能性があります。
IAMの設定: これと同様に、異なるアカウントでリソースへの共有アクセスを設定するには、複雑なIAM(Identity and Access Management)設定が必要になります。あるアカウントが所有するリソースに他のアカウントがアクセスできるように、IAMポリシーを記述する必要があります。これは十分に可能ですが、すべてのリソースが単一のアカウントに属している場合のIAMポリシー管理よりも難しくなります。
要するに、AWSでアカウントが増えるということは、少なくとも管理性の観点からは問題が増えるということです。
AWSで複数のアカウントを扱うためのベストプラクティス
AWSの管理者として、あなたのゴールは、複数のAWSアカウントを管理する複雑さが、複数のアカウントが提供する利点を上回らないようにすることです。以下のベストプラクティスは、可能な限り最良の結果を達成するのに役立ちます。
アカウント設定の一貫したポリシーを確立する
組織は、新しいアカウントをいつどのように作成するかを定義する明確なガイドラインを設定すべきです。例えば、社内の部署ごとにアカウントを設定する。個々の従業員が独自のアカウントを必要とする状況はあるのか。部署によっては、テスト用と本番用など、複数のアカウントが必要になるのでしょうか?
これらの質問に対する答えは、組織の性質やビジネスの優先順位によって異なります。しかし、アカウント作成ルールをどのように定義するにしても、首尾一貫した計画を立てておくことは、気まぐれにアカウントを作成することで、ビジネスの一部に少なすぎるアカウントが残ったり、他の部署に必要以上のアカウントが残ったりすることを避けるために不可欠です。
一貫性のある意味のあるアカウント名を作る
アカウントを作成する際は、アカウント名からそのアカウントの目的と範囲がわかるようにします。そうすれば、アカウントに設定を適用する際に、そのアカウントが何をするためのものなのかを調べる必要がなくなります。
例えば、dev1やdev2のような名前のアカウントを作るのではなく、dev-testingやdev-productionのような用語を使う等。
複数アカウント管理の自動化
複数のアカウントをOUやランディングゾーンに手動で構成することは可能です。しかし、複数のアカウントを効率的に管理するには、Control Towerのような自動化ツールの活用を検討してください。Control Towerを使用すれば、複数のアカウントを迅速にセットアップして整理できます。ビルトインのセキュリティ、コンプライアンス、その他のコントロールを備え、各アカウントのニーズに基づいて簡単に適用できます。
クロスアカウントのディザスタリカバリを可能に
前述したように、あるアカウントの認証情報が漏洩したランサムウェア攻撃のような事故により、あるAWSアカウントで作成または管理されたデータが、そのアカウントでデプロイできなくなるシナリオに遭遇する可能性があります。その場合、クロスアカウントディザスタリカバリを実行する能力を持つことが最も重要です。
クロスアカウント・ディザスタリカバリでは、あるアカウントが所有するデータを別のアカウントで管理する環境に自動的にリストアできるため、身代金を支払うことなく迅速に業務を復旧できます。
マルチアカウント災害復旧のテスト
マルチアカウントのバックアップとリカバリツールの構成に加えて、複数のアカウントを含むディザスタリカバリ訓練を定期的に実行することがベストプラクティスです。例えば、バックアップを使用して1つのアカウントのデータだけをうまく復旧できるかどうかをテストするのではなく、クロスアカウントの復旧を実行しなければならないシナリオをシミュレートします。
これは、ディザスタリカバリテストのみを目的としたアカウントを設定し、ディザスタリカバリテストアカウントが所有する環境に別のアカウントのデータをリストアしようとすることで可能です。
N2WSを使用した複数のAWSアカウントでの成功
AWSで保持するアカウントが多ければ多いほど、リソースの分離やきめ細かい制御の定義が容易になります。しかし、アカウントが増えることは、管理の複雑さにもつながります。
この課題を軽減するには、アカウントの作成、アカウントの命名ポリシー、データのバックアップとディザスタリカバリなどの分野でソリューションを導入していることを確認してください。そうすれば、複雑さが組織の足を引っ張ることなく、複数のアカウントを最大限に活用できるようになります。
N2WSは、複数のAWSアカウントでビジネスを成功に導きます。ユーザは、1つのコンソールで多くのアカウントのすべてのバックアップ操作を管理することができます。ボタンをクリックするだけで、ユーザーフレンドリーなUIと複数のクライアントの環境に簡単にアクセスできるため、個々の要件に基づいたカスタムソリューションを簡単に構築できます。マルチクライアント、マルチAWSアカウント、マルチアベイラビリティゾーンに対応する信頼性の高い一貫したバックアップソリューションは、どのような状況下でもデータを保護するだけでなく、ユーザにより多くの収益と機会をもたらします。
N2WSはまた、クロスアカウント機能を使用して、即時かつ完全なランサムウェア保護を提供します。アカウントがハッキングされたり、クラウドプロバイダーが大失態を犯し、本番アカウント全体が消去されたりした場合、N2WSは本番環境全体をスピンアップし、バックアップデータをコールドストレージに移動してコストを最適化する機能などのオプションを提供します。
関連トピックス
- Amazon S3 Glacierにバックアップする方法
- リポジトリの同時実行タスク数のカウントについて[Veeam Backup & Replication]
- Veeam Backup for Azure V3の新機能について
- ローカルPC以外のSQLServerに接続する際の注意点【VMWare専用 バックアップ & レプリケーションソフト Veeam】
- AWSにおけるN2WS Backup & Recoveryのポジショニング
- PSTへのエクスポート機能付きClimb Cloud Backup for Microsoft 365 とGoogle Workspace
- CloudBerry BackupでのSoftLayer Cloud Storage アカウントのレジスタ方法
- CloudBerry Backupのコマンドラインインターフェイスについて
- 【CloudBerry Backup】niftyクラウドストレージの登録方法
- 【Veeam Backup for AWS 3.0新機能】Amazon RDSのバックアップ対応