翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# マルチアカウント戦略
AWS では、[マルチアカウント戦略](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html)と AWS 組織を使用して、ビジネスアプリケーションとデータを分離および管理することをお勧めします。マルチアカウント戦略を使用することには[多くの利点](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/benefits-of-using-multiple-aws-accounts.html)があります。
+ AWS API サービスクォータの引き上げ。クォータは AWS アカウントに適用され、ワークロードに複数のアカウントを使用すると、ワークロードで使用できる全体的なクォータが増加します。
+ よりシンプルな Identity and Access Management (IAM) ポリシー。ワークロードとワークロードをサポートするオペレーターに独自の AWS アカウントのみへのアクセスを許可すると、最小特権の原則を達成するためにきめ細かな IAM ポリシーを作成する時間を短縮できます。
+ AWS リソースの分離が改善されました。設計上、アカウント内でプロビジョニングされたすべてのリソースは、他のアカウントでプロビジョニングされたリソースから論理的に分離されます。この分離境界により、アプリケーション関連の問題、設定ミス、または悪意のあるアクションのリスクを制限する方法が提供されます。1 つのアカウント内で問題が発生した場合に、他のアカウントに含まれるワークロードへの影響を軽減または排除することができます。
+ [AWS マルチアカウント戦略ホワイトペーパー](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/benefits-of-using-multiple-aws-accounts.html#group-workloads-based-on-business-purpose-and-ownership)で説明されているその他の利点
以下のセクションでは、集中型または分散型の EKS クラスターアプローチを使用して EKS ワークロードにマルチアカウント戦略を実装する方法について説明します。
## マルチテナントクラスターのマルチワークロードアカウント戦略の計画
マルチアカウント AWS 戦略では、S3 バケット、ElastiCache クラスター、DynamoDB テーブルなどの特定のワークロードに属するリソースはすべて、そのワークロードのすべてのリソースを含む AWS アカウントに作成されます。これらはワークロードアカウントと呼ばれ、EKS クラスターはクラスターアカウントと呼ばれるアカウントにデプロイされます。クラスターアカウントについては、次のセクションで説明します。専用ワークロードアカウントにリソースをデプロイすることは、kubernetes リソースを専用名前空間にデプロイする場合と似ています。
その後、ワークロードアカウントは、必要に応じてソフトウェア開発ライフサイクルやその他の要件別にさらに分類できます。たとえば、特定のワークロードには、本番稼働用アカウント、開発用アカウント、または特定のリージョンでそのワークロードのインスタンスをホストするためのアカウントを含めることができます。[詳細については](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-workload-oriented-ous.html)、この AWS ホワイトペーパーを参照してください。
EKS マルチアカウント戦略を実装するときは、次のアプローチを採用できます。
## 一元化された EKS クラスター
このアプローチでは、EKS クラスターは という 1 つの AWS アカウントにデプロイされます`Cluster Account`。[サービスアカウント (IRSA) または EKS Pod ID の IAM ロール](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html)を使用して一時的な AWS 認証情報を配信し、[AWS Resource Access Manager (RAM)](https://aws.amazon.com/ram/) を使用してネットワークアクセスを簡素化することで、マルチテナント EKS クラスターにマルチアカウント戦略を採用できます。 [https://docs.aws.amazon.com/eks/latest/userguide/pod-identities.html](https://docs.aws.amazon.com/eks/latest/userguide/pod-identities.html)クラスターアカウントには、VPC、サブネット、EKS クラスター、EC2/Fargate コンピューティングリソース (ワーカーノード）、および EKS クラスターの実行に必要な追加のネットワーク設定が含まれます。
マルチテナントクラスターのマルチワークロードアカウント戦略では、AWS アカウントは通常、リソースグループを分離するメカニズムとして [kubernetes 名前空間と一致します](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/)。マルチ[テナント EKS クラスターにマルチアカウント戦略を実装する場合は、EKS クラスター内のテナント分離のベストプラクティス](tenant-isolation.md)に従う必要があります。
AWS 組織`Cluster Accounts`には複数の を含めることができ、ソフトウェア開発ライフサイクルのニーズに合った複数の を持つこと`Cluster Accounts`がベストプラクティスです。非常に大規模なワークロードでは、すべてのワークロード`Cluster Accounts`で使用できる十分な kubernetes と AWS サービスクォータを確保するために、複数の が必要になる場合があります。
\|上記の図では、AWS RAM はクラスターアカウントからワークロードアカウントへのサブネットの共有に使用されます。次に、EKS ポッドで実行されているワークロードは、IRSA または EKS Pod Identity とロールチェーンを使用してワークロードアカウントのロールを引き受け、AWS リソースにアクセスします。
### マルチテナントクラスターのマルチワークロードアカウント戦略の実装
#### AWS Resource Access Manager とのサブネットの共有
[AWS Resource Access Manager](https://aws.amazon.com/ram/) (RAM) を使用すると、AWS アカウント間でリソースを共有できます。
[AWS Organization で RAM が有効になってい](https://docs.aws.amazon.com/ram/latest/userguide/getting-started-sharing.html#getting-started-sharing-orgs)る場合は、クラスターアカウントからワークロードアカウントに VPC サブネットを共有できます。これにより、[Amazon ElastiCache](https://aws.amazon.com/elasticache/) クラスターや [Amazon Relational Database Service (RDS)](https://aws.amazon.com/rds/) データベースなどのワークロードアカウントが所有する AWS リソースを EKS クラスターと同じ VPC にデプロイし、EKS クラスターで実行されているワークロードで使用できるようになります。
RAM 経由でリソースを共有するには、クラスターアカウントの AWS コンソールで RAM を開き、「リソース共有」と「リソース共有の作成」を選択します。リソース共有に名前を付け、共有するサブネットを選択します。次へを再度選択し、サブネットを共有するワークロードアカウントの 12 桁のアカウント IDs を入力し、次へを再度選択して、リソース共有の作成をクリックして終了します。このステップの後、ワークロードアカウントはそれらのサブネットにリソースをデプロイできます。
RAM 共有は、プログラムで作成することも、Infrastructure as Code を使用して作成することもできます。
#### EKS ポッド ID と IRSA の選択
re:Invent 2023 で、AWS は EKS 上のポッドに一時的な AWS 認証情報を配信する簡単な方法として EKS Pod ID を起動しました。IRSA と EKS Pod ID はどちらも、一時的な AWS 認証情報を EKS ポッドに配信するための有効な方法であり、引き続きサポートされます。ニーズに最適な配信方法を検討する必要があります。
EKS クラスターと複数の AWS アカウントを使用する場合、IRSA は EKS クラスターが直接ホストされているアカウント以外の AWS アカウントでロールを直接引き受けることができますが、EKS Pod ID ではロールの連鎖を設定する必要があります。詳細な比較については、[EKS ドキュメント](https://docs.aws.amazon.com/eks/latest/userguide/service-accounts.html#service-accounts-iam)を参照してください。
##### サービスアカウントの IAM ロールを使用した AWS API リソースへのアクセス
[サービスアカウントの IAM ロール (IRSA)](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html) を使用すると、EKS で実行されているワークロードに一時的な AWS 認証情報を配信できます。IRSA を使用して、クラスターアカウントからワークロードアカウントの IAM ロールの一時的な認証情報を取得できます。これにより、クラスターアカウントの EKS クラスターで実行されているワークロードは、ワークロードアカウントでホストされている S3 バケットなどの AWS API リソースをシームレスに消費し、Amazon RDS データベースや Amazon EFS FileSystems などのリソースに IAM 認証を使用できます。
ワークロードアカウントで IAM 認証を使用する AWS API リソースおよびその他のリソースには、クロスアカウントアクセスが可能であり、明示的が有効になっている場合を除き、同じワークロードアカウントの IAM ロールの認証情報でのみアクセスできます。
##### クロスアカウントアクセスの IRSA の有効化
クラスターアカウントのワークロードの IRSA がワークロードアカウントのリソースにアクセスできるようにするには、まずワークロードアカウントに IAM OIDC ID プロバイダーを作成する必要があります。これは、ID プロバイダーがワークロードアカウントで作成されることを除いて、[IRSA](https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html) の設定と同じ手順で行うことができます。
次に、EKS でワークロードに IRSA を設定するときに、 [ドキュメントと同じステップを実行できます](https://docs.aws.amazon.com/eks/latest/userguide/associate-service-account-role.html)が、「別のアカウントのクラスターから ID プロバイダーを作成する」セクションで説明されているように、[ワークロードアカウントの 12 桁のアカウント ID](https://docs.aws.amazon.com/eks/latest/userguide/cross-account-access.html) を使用します。
これを設定すると、EKS で実行されているアプリケーションは、そのサービスアカウントを直接使用してワークロードアカウントのロールを引き受け、その中のリソースを使用できます。
##### EKS Pod ID を使用した AWS API リソースへのアクセス
[EKS Pod Identity ](https://docs.aws.amazon.com/eks/latest/userguide/pod-identities.html)は、EKS で実行されているワークロードに一時的な AWS 認証情報を配信する別の方法を提供します。EKS Pod Identity は EKS コントロールプレーンおよびクラスター上のエージェントと統合されるため、ポッドは IAM OIDC ID プロバイダーを作成または管理することなく認証情報を受け取ります。EKS Pod Identity は、[サポートされているノードタイプの](https://docs.aws.amazon.com/eks/latest/userguide/pod-identities.html#pod-id-considerations)新しいワークロードに推奨されるアプローチですが、IRSA は引き続き完全にサポートされている代替手段です。
EKS Pod Identity では、クラスター内の Kubernetes サービスアカウントを、クラスターと同じ AWS アカウントの IAM ロールに関連付けます。EKS はこの関連付けを使用して、その IAM ロールの一時的な認証情報を取得し、サービスアカウントを使用するポッドに安全に提供します。その後、アプリケーションは標準の AWS SDKs とデフォルトの認証情報チェーンを使用して AWS APIs を呼び出すことができます。カスタム認証情報プロバイダーや設定ファイルは必要ありません。
##### クロスアカウントアクセスの EKS Pod ID の有効化
EKS Pod Identity は、ワークロードアカウントのターゲット IAM ロールと IAM ロールの連鎖を使用して、クロスアカウントアクセスをネイティブにサポートします。Kubernetes サービスアカウントの Pod Identity 関連付けを作成するときは、クラスターアカウントのポッド IAM ロールとワークロードアカウントのターゲット IAM ロールの両方を指定します。EKS Pod Identity は、ポッドロールを使用してターゲットロールを引き受け、ターゲットロールの一時的な認証情報をポッドに返します。
このアプローチの詳細なウォークスルーと考慮事項については、この [AWS ブログ](https://aws.amazon.com/blogs/containers/amazon-eks-pod-identity-a-new-way-for-applications-on-eks-to-obtain-iam-credentials/)を参照してください。
##### クロスアカウントアクセス用の ABAC および EKS Pod ID
EKS Pod Identity を使用して、マルチアカウント戦略の一環として他のアカウントのロール (ロールの連鎖) を引き受ける場合、別のアカウントにアクセスする必要があるサービスアカウントごとに一意の IAM ロールを割り当てるか、複数のサービスアカウントで共通の IAM ロールを使用し、ABAC を使用してアクセスできるアカウントを制御できます。
ABAC を使用して、ロールチェーンを使用してロールを別のアカウントに引き受けることができるロールを制御するには、想定値が存在するときに EKS クラスターアカウント (アカウント ID 111122223333) からポッド IAM ロールのみがロールを引き受けることを許可するロール信頼ポリシーステートメントを作成します。次のロール信頼ポリシーでは、 `eks-cluster-arn`および `kubernetes-namespace` タグのすべてに期待値がある場合`kubernetes-service-account`、EKS クラスターアカウントのポッド IAM ロールがロールを引き受けることのみを許可します。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:role/account-a-role"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/kubernetes-service-account": "PayrollApplication",
"aws:RequestTag/eks-cluster-arn": "arn:aws:eks:us-east-1:111122223333:cluster/ProductionCluster",
"aws:RequestTag/kubernetes-namespace": "PayrollNamespace"
}
}
}
]
}
```
EKS Pod Identity セッションポリシーを使用して、追加の IAM ロールを作成することなく、ポッドのアクセス許可をさらに絞り込むこともできます。セッションポリシーは、EKS Pod Identity がロールを引き受け、結果として得られるアクセス許可がロールポリシーとセッションポリシーの共通部分である場合に適用されます。考慮事項と詳細な手順については、AWS Containers ブログの[「Amazon EKS Pod Identity のセッションポリシー](https://aws.amazon.com/blogs/containers/session-policies-for-amazon-eks-pod-identity/)」を参照してください。
この戦略を使用する場合は、共通の IAM ロールに `sts:AssumeRole`および アクセス`sts:TagSession`許可のみがあり、他の AWS アクセスがないことを確認することがベストプラクティスです。
ABAC を使用するときは、IAM ロール、ユーザー、および STS セッションを、厳密に必要なユーザーのみにタグ付けできるユーザーを制御することが重要です。`kubernetes-` または `eks-` タグを設定できるユーザーは、EKS Pod Identity ロールの連鎖中に渡すものと同じタグを設定でき、権限を昇格できる場合があります。IAM ポリシーまたはサービスコントロールポリシー (SCP) を使用して、これらのタグを設定するアクセス権を持つユーザーを制限できます。たとえば、コントロールについては、[ProtectPodIdentitiesTagsOnRolesAndUsers](https://github.com/aws-samples/service-control-policy-examples/blob/main/Service-specific-controls/Amazon-EKS/ProtectPodIdentitiesTagsOnRolesAndUsers.json)」および[STS-Protect-EKS-pod-identities-tags](https://github.com/aws-samples/resource-control-policy-examples/blob/main/Service-specific-controls/STS-Protect-EKS-pod-identities-tags.json)」を参照してください。
##### EKS ポッド ID と IRSA の選択
IRSA と EKS Pod ID はどちらも、一時的な AWS 認証情報を EKS ワークロードに配信するための有効なオプションです。EKS Pod Identity は、[サポートされているノードタイプ](https://docs.aws.amazon.com/eks/latest/userguide/pod-identities.html#pod-id-considerations)で実行されている新しいアプリケーションに推奨されます。また、IRSA は、EKS Pod Identity がサポートしていないプラットフォームで OIDC と IRSA が既に導入されているか、実行されている場合に適しています。
どちらを使用するかを決定するときは、次の点を考慮してください。
+ **次の場合に EKS Pod ID を選択します。**
+ 新しいワークロードを設計していて、IAM OIDC ID プロバイダーの作成と管理を避けたいと考えています。
+ カスタム認証情報スクリプトや AWS 設定ファイルをポッドに追加せずに、ターゲット IAM ロールを使用したクロスアカウントアクセスをネイティブにサポートする必要があります。
+ クラスター管理者がどの Kubernetes サービスアカウントがどのロールを引き受けることができるかを管理し、IAM 管理者がそれらのロールのアクセス許可を管理することをお勧めします。
+ 認証情報供給を効率的にスケーリングし、IAM クォータの制限に達しないようにします。
+ **次の場合に IRSA を選択します。**
+ すでに IRSA を正常に使用しており、OIDC プロバイダーと IAM ロールの標準パターンがあります。
+ ワークロードは、AWS Fargate、Windows ノード、サポートされていない AWS SDKs を使用するアプリケーションなど、EKS Pod ID がサポートされていない環境で実行されます。
+ ワークロードアカウントのロールには OIDC ベースの直接フェデレーションモデルが必要であり、セキュリティコントロールはすでに OIDC プロバイダーを中心に構築されています。
IRSA と EKS Pod ID はどちらもマルチアカウント戦略をサポートしています。クラスター全体で一貫したアプローチを使用するか、レガシーワークロードが引き続き IRSA を使用し、新しいワークロードが EKS Pod ID を使用する混合モデルを採用できます。
## 分散型 EKS クラスター
このアプローチでは、EKS クラスターは各ワークロードの AWS アカウントにデプロイされ、Amazon S3 バケット、VPCs、Amazon DynamoDB テーブルなどの他の AWS リソースと一緒に動作します。各ワークロードアカウントは独立しており、自己完結しており、各ビジネスユニット/アプリケーションチームによって運用されています。このモデルでは、 AI/ML クラスター、バッチ処理、汎用など、さまざまなクラスター機能の再利用可能なブループリントを作成し、アプリケーションチームの要件に基づいてクラスターを 供給できます。アプリケーションチームとプラットフォームチームの両方がそれぞれの [GitOps](https://www.weave.works/technologies/gitops/) リポジトリから運用され、ワークロードクラスターへのデプロイを管理します。
上記の図では、Amazon EKS クラスターおよびその他の AWS リソースがそれぞれのワークロードアカウントにデプロイされています。次に、EKS ポッドで実行されているワークロードは、IRSA または EKS Pod ID を使用して AWS リソースにアクセスします。
GitOps は、Git リポジトリでシステム全体が宣言的に記述されるように、アプリケーションとインフラストラクチャのデプロイを管理する方法です。これは、バージョン管理、イミュータブルアーティファクト、自動化のベストプラクティスを使用して、複数の Kubernetes クラスターの状態を管理する機能を提供する運用モデルです。このマルチクラスターモデルでは、各ワークロードクラスターは複数の Git リポジトリでブートストラップされるため、各チーム (アプリケーション、プラットフォーム、セキュリティなど) はそれぞれの変更をクラスターにデプロイできます。
各アカウントの[サービスアカウント (IRSA) または EKS Pod ID の IAM ロール](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html)を使用して、EKS ワークロードが一時的な AWS 認証情報を取得して他の AWS リソースに安全にアクセスできるようにします。 [https://docs.aws.amazon.com/eks/latest/userguide/pod-identities.html](https://docs.aws.amazon.com/eks/latest/userguide/pod-identities.html)IAM ロールは、それぞれのワークロードの AWS アカウントで作成され、一時的な IAM アクセスを提供するために k8s サービスアカウントにマッピングされます。したがって、このアプローチではクロスアカウントアクセスは必要ありません。IRSA の各ワークロードで を設定する方法については、[サービスアカウントの IAM ロール](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html)に関するドキュメント、各アカウントの [EKS ポッド ID](https://docs.aws.amazon.com/eks/latest/userguide/pod-identities.html) を設定する方法については、EKS ポッド ID に関するドキュメントを参照してください。
### 一元化されたネットワーク
AWS RAM を使用して VPC サブネットをワークロードアカウントと共有し、Amazon EKS クラスターやその他の AWS リソースを起動することもできます。これにより、一元化されたネットワーク管理、簡素化されたネットワーク接続、および分散された EKS クラスターが可能になります。このアプローチの詳細なウォークスルーと考慮事項については、この [AWS ブログ](https://aws.amazon.com/blogs/containers/use-shared-vpcs-in-amazon-eks/)を参照してください。
上記の図では、AWS RAM を使用して、中央ネットワークアカウントからワークロードアカウントにサブネットを共有しています。次に、EKS クラスターおよびその他の AWS リソースが、それぞれのワークロードアカウントのサブネットで起動されます。EKS ポッドは、IRSA または EKS Pod ID を使用して AWS リソースにアクセスします。
## 一元化された EKS クラスターと分散された EKS クラスター
集中型または分散型で実行するかどうかは、要件によって異なります。この表は、各戦略の主な違いを示しています。
| \# | 一元化された EKS クラスター | 分散型 EKS クラスター |
| --- | --- | --- |
| クラスター管理: | 1 つの EKS クラスターの管理は、複数のクラスターを管理するよりも簡単です。 | 複数の EKS クラスターを管理する運用オーバーヘッドを減らすには、効率的なクラスター管理の自動化が必要です。 |
| コスト効率: | EKS クラスターとネットワークリソースの再利用を許可し、コスト効率を高める | ワークロードごとにネットワークとクラスターのセットアップが必要で、追加のリソースが必要です |
| 耐障害性: | クラスターに障害が発生した場合、集中型クラスターの複数のワークロードが影響を受ける可能性があります。 | クラスターに障害が発生した場合、損害はそのクラスターで実行されるワークロードのみに限定されます。他のすべてのワークロードは影響を受けません |
| 分離とセキュリティ: | 分離/ソフトマルチテナンシーは、 のような k8s ネイティブコンストラクトを使用して実現されます`Namespaces`。ワークロードは、CPU、メモリなどの基盤となるリソースを共有する場合があります。AWS リソースは独自のワークロードアカウントに分離され、デフォルトでは他の AWS アカウントからはアクセスできません。 | リソースを共有しない個々のクラスターとノードでワークロードが実行されるため、コンピューティングリソースをより強力に分離できます。AWS リソースは独自のワークロードアカウントに分離され、デフォルトでは他の AWS アカウントからはアクセスできません。 |
| パフォーマンスとスケーラビリティ: | ワークロードが非常に大規模になると、クラスターアカウントで kubernetes と AWS サービスクォータが発生する可能性があります。追加のクラスターアカウントをデプロイして、さらに拡張できます | より多くのクラスターと VPCsと、各ワークロードの k8 と AWS サービスクォータが利用可能になります。 |
| ネットワーク: | クラスターごとに 1 つの VPC が使用されるため、そのクラスター上のアプリケーションの接続が簡単になります。 | 分散 EKS クラスター VPCs 間でルーティングを確立する必要があります |
| Kubernetes アクセス管理: | すべてのワークロードチームへのアクセスを提供し、kubernetes リソースが適切に分離されるように、クラスター内でさまざまなロールとユーザーを維持する必要があります。 | 各クラスターがワークロード/チーム専用であるため、アクセス管理を簡素化 |
| AWS アクセス管理: | AWS リソースは、ワークロードアカウントの IAM ロールでのみデフォルトでアクセスできる独自のアカウントにデプロイされます。ワークロードアカウントの IAM ロールは、IRSA または EKS Pod ID を使用してクロスアカウントとして引き受けられます。 | AWS リソースは、ワークロードアカウントの IAM ロールでのみデフォルトでアクセスできる独自のアカウントにデプロイされます。ワークロードアカウントの IAM ロールは、IRSA または EKS Pod ID を持つポッドに直接配信されます。 |