本記事は 2026 年 3 月 6 日に公開された “ AWS Load Balancer Controller adds general availability support for Kubernetes Gateway API ” を翻訳したものです。 AWS は最近、 Amazon Web Services (AWS) Load Balancer Controller による Kubernetes Gateway API サポートの一般提供を発表しました。これまで、AWS Load Balancer Controller は Kubernetes Ingress と Service リソースの要件を満たすため、それぞれ Application Load Balancer (ALB) と Network Load Balancer (NLB) をプロビジョニングしていました。この新機能により、標準の Kubernetes Gateway API を使用してAWSロードバランシング機能を定義できるようになりました。この投稿では、AWS Load Balancer Controller の Kubernetes Gateway API サポートをご紹介します。Gateway API 統合の構成ベストプラクティス、機能、ユースケースを共有し、AWS 上での Kubernetes デプロイメントのモダナイゼーションと合理化を支援します。 前提条件 Kubernetes API、コントローラー、Deployments、Services、カスタムリソースなどのリソースタイプを含む Kubernetes の概念に精通していることを前提としています。また、 Amazon Elastic Kubernetes Service (Amazon EKS) と AWS ロードバランシングサービスについての基本的な理解も必要です。これらの概念を復習する必要がある場合は、Kubernetes ドキュメントと Amazon EKS ユーザーガイドから始めることをお勧めします。 Gateway API 概要 Gateway API は、Kubernetes クラスターで L4 (TCP/UDP) および L7 (HTTP/gRPC) トラフィックルーティングを管理するための次世代フレームワークです。従来の Ingress API よりも柔軟で表現力豊かなロール指向のアプローチを提供し、Ingress における以前の制限に対処しています。流入トラフィック (north-south トラフィック) やサービス間接続 (east-west トラフィック) を含む、幅広いトラフィック管理ニーズに対応する標準化された、ポータブルで拡張可能な仕様を提供します。 Ingress API は長年にわたって Kubernetes ユーザーによく貢献してきましたが、Gateway API が対処するいくつかの制限があります。Ingress は高度な機能に対してベンダー固有のアノテーションに依存しており、異なる実装間での構成の移植性を低下させています。さらに、ロールベースのリソース管理のネイティブサポートが不足しており、これはクラスター運用者とアプリケーション開発者が同じ構成面を共有することを意味します。Gateway API は、インフラストラクチャプロバイダー (GatewayClass)、クラスター運用者 (Gateway)、アプリケーション開発者 (Routes) に対して異なるリソースを持つロール指向設計を導入しています。この分離により、より良い組織ポリシーとセキュリティ境界が可能になります。さらに、Gateway API は、クロス名前空間ルーティング、重み付きトラフィック分割、ヘッダーベースルーティング、L4 と L7 の両方のプロトコルに対するネイティブサポートを提供します。これらの機能は以前は複雑な回避策が必要であったか、Ingress だけでは不可能でした。これらの改善により、Gateway API はより表現力豊かで拡張可能であり、現代のクラウドアーキテクチャに適したものになります。 AWS のフルマネージドアプリケーションネットワーキングサービスである Amazon VPC Lattice は、 Amazon VPC Lattice Gateway API Controller を通じて Kubernetes Gateway API のサポートを既に提供しています。これは、VPC とアカウント内の EKS クラスター間でサービス間接続を可能にする別のコントローラーです。AWS Load Balancer コントローラーも Gateway API 仕様をサポートすることで、ALB と NLB による流入 (north-south）トラフィック管理と、east-west サービスメッシュ機能に VPC Lattice を使用する柔軟性の両方について包括的なカバレッジを得ることができます。そして、これらはすべて同じ標準化された Gateway API リソースを使用して実現されます。 Gateway API コンポーネント Gateway API は、Kubernetes クラスターへのトラフィックの流入と通過の方法を定義するために連携する 3 つのコアリソースを導入します。これらのコンポーネントとそれらが AWS インフラストラクチャにどのようにマッピングされるかを理解することで効果的なトラフィック管理戦略を設計できます。図 1 は Gateway API 仕様のコンポーネントを示しています: 図 1 : Gateway API コントローラーコンポーネント [ 出典 ] GatewayClass GatewayClass は、共通の構成と動作を持つ Gateway を作成するためのテンプレートを定義します。プラットフォームチームは GatewayClass を使用して組織ポリシーとインフラストラクチャテンプレートを確立します。例えば、GatewayClass はどのコントローラーが Gateway を管理するか (AWS Load Balancer Controller など) と、どのタイプのロードバランサーをプロビジョニングするか (ALB または NLB) を指定します。 以下は、ALB をプロビジョニングする GatewayClass の例です: apiVersion: gateway.networking.k8s.io/v1 kind: GatewayClass metadata: name: aws-alb spec: controllerName: gateway.k8s.aws/alb Gateway Gateway はロードバランサーをインスタンス化し、トラフィックがクラスターにどのように入るかを定義します。クラスター運用者は、リスナー (プロトコルとポートの組み合わせ)、ホスト名、TLS 設定を指定するように Gateway を構成します。Gateway を作成すると、AWS Load Balancer Controller は指定されたリスナーで対応する AWS ロードバランサーをプロビジョニングします。 以下は、HTTP と HTTPS リスナーを持つ ALB を作成する Gateway の例です: apiVersion: gateway.networking.k8s.io/v1 kind: Gateway metadata: name: my-gateway namespace: default spec: gatewayClassName: aws-alb listeners: - name: http protocol: HTTP port: 80 - name: https protocol: HTTPS port: 443 hostname: example.com Routes Routes は、リスナーをバックエンド Kubernetes サービスにマッピングするルーティングルールを定義します。アプリケーション開発者は、パス、ヘッダー、ホスト名などのリクエスト属性に基づいてトラフィックがサービスにどのように分散されるかを制御するために Routes (HTTPRoute、GRPCRoute、TCPRoute、UDPRoute、TLSRoute) を作成します。 以下は、Gateway の HTTP リスナーから Kubernetes サービスにトラフィックをルーティングする HTTPRoute の例です: apiVersion: gateway.networking.k8s.io/v1beta1 kind: HTTPRoute metadata: name: my-route namespace: default spec: parentRefs: - name: my-gateway sectionName: http rules: - matches: - path: type: PathPrefix value: /app backendRefs: - name: my-service port: 8080 AWS Load Balancer Controller は Kubernetes Gateway API オブジェクトの調整をサポートしています。以下を満たします: TCPRoute や UDPRoute などの L4 ルートを AWS NLB で HTTPRoute や GRPCRoute などの L7 ルートを AWS ALB で 動作の仕組み AWS Load Balancer Controller が Gateway API リソースを AWS インフラストラクチャにどのように変換するかを理解することで、より信頼性の高いアプリケーションを設計し、問題をより迅速にトラブルシューティングできます。コントローラーの調整モデルにより、Kubernetes の定義が AWS ロードバランサーと同期された状態を保ち、継続的な検証とリアルタイムステータスフィードバックを提供します。 高レベルでは、以下のステップが調整ループの動作を示しています: API 監視 : Gateway API リソースの作成、変更、削除について、Kubernetes API が継続的に監視されます。 キューイング : コントローラーは特定されたリソースを処理のための内部キューに追加します。 処理 : 内部キューの各アイテムに対して: コントローラーは関連する GatewayClass をチェックして、ユーザーが AWS ロードバランサーを要求しているかどうかを確認します。 yes の場合、対応する Gateway リソースの Gateway API 定義が、NLB/ALB、リスナー、リスナールール、ターゲットグループ、またはアドオンなどの AWS リソースにマッピングされます。 これらのマッピングされたリソースは、AWS の実際の状態と比較されます。差分があると、コントローラーは AWS の状態を Gateway オブジェクトによって設定された望ましい状態と一致させます。 ステータス更新 : 調整後、AWS Load Balancer Controller は対応する Gateway および Route リソースのステータスフィールドを更新します。これにより、ALB の DNS 名や Amazon Resource Name (ARN) などのプロビジョニングされた AWS リソース、およびデバッグを支援するエラー詳細について、リアルタイムフィードバックが提供されます。例えば、HTTPRoute を作成すると、ステータスフィールドにはルートが受け入れられたかどうか、それが接続されている Gateway、およびプロビジョニング時にトラフィックルーティングに使用する ALB の DNS 名がすぐに表示されます。無効な証明書 ARN などの構成エラーがある場合、ステータスフィールドは実用的なエラーメッセージを提供します。 図 2 は、この調整フローを詳細に示しています。コントローラーは Gateway API リソースに対するウォッチを確立し、内部キューを通じて変更を処理し、望ましい状態の中間表現を構築し、対応する AWS リソースを実現します。このプロセス全体を通じて、プロビジョニングの進行状況と発生したエラーを反映するためにステータス条件が更新されます。 図 2 : Gateway API コントローラー調整フロー この宣言的アプローチは、望ましいロードバランシング構成を一度定義すると、コントローラーが AWS がその意図と一致することを継続的に保証することを意味します。これにより、ドリフトと構成変更が自動的に処理されます。 主要機能 このセクションでは、Load Balancer Controller Gateway API サポートの主要機能について説明します: 強化されたカスタマイズ AWS Load Balancer Controller は、適切に定義された Kubernetes Custom Resource Definitions (CRD) を採用し、アノテーションベースの構成を廃止します。この変更により、検証や IDE サポートが不足しているアノテーション文字列に複雑なデータ構造を埋め込むという制限に対処します。例えば: Before (アノテーションベースアプローチ): apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: my-ingress annotations: alb.ingress.kubernetes.io/target-group-attributes: | deregistration_delay.timeout_seconds=30, stickiness.enabled=true, stickiness.type=lb_cookie After (CRDベースアプローチ): apiVersion: gateway.k8s.aws/v1beta1 kind: TargetGroupConfiguration metadata: name: my-app-tg-config namespace: my-app spec: targetReference: name: my-service defaultConfiguration: targetGroupAttributes: - key: deregistration_delay.timeout_seconds value: "30" - key: stickiness.enabled value: "true" - key: stickiness.type value: lb_cookie healthCheckConfig: healthyThresholdCount: 5 healthCheckInterval: 30 healthCheckPath: /health healthCheckPort: "8080" healthCheckProtocol: HTTP healthCheckTimeout: 5 unhealthyThresholdCount: 2 AWS Load Balancer Controller は Gateway API カスタマイズのために 3 つの CRD を導入しています： TargetGroupConfiguration : サービスレベルでヘルスチェック、登録解除遅延、スティッキネス設定を含むターゲットグループプロパティを構成 LoadBalancerConfiguration : Gateway または GatewayClass レベルでサブネット配置、セキュリティグループ、アクセスログなどのリスナーおよびロードバランサープロパティを定義 ListenerRuleConfiguration : Amazon Cognito または OIDC プロバイダーを通じた認証を含む AWS 固有のルーティング動作で HTTPRoute および GRPCRoute リソースを拡張 これらの CRD は、スキーマ検証、タイプセーフティ、GitOps ワークフローとのネイティブ統合を提供します。構成エラーは実行時ではなく適用時に表面化し、運用オーバーヘッドを削減し、インフラストラクチャの信頼性を向上させます。 Cross-Namespace トラフィックルーティング Gateway API は、Cross-Namespace ルーティングを通じてインフラストラクチャ運用者とアプリケーション開発者の間の関心の分離を可能にします。プラットフォームチームは共有 Gateway リソースをプロビジョニングし、アプリケーションチームはクラスターレベルの権限を必要とせずに独自の Rout を管理します。 このモデルでは、プラットフォームチームがアクセス制御された専用の名前空間に Gateway をデプロイします。別々の名前空間のアプリケーションチームは、共有 Gateway を参照する Route リソースを作成します。コントローラーは、これらの分散された定義に基づいてトラフィックをルーティングするようにロードバランサーを自動的に構成します。 このアーキテクチャは、Kubernetes API レベルで RBAC 境界を強制します。アプリケーションチームは、サブネット配置やセキュリティグループ割り当てなどのインフラストラクチャレベルの構成にアクセスすることなく、サービスのルーティングロジックを管理します。 自動 TLS 証明書検出 AWS Load Balancer Controller は、L4 と L7 の両方のプロトコルについて、Ingress API から Gateway API リスナーへの証明書検出を拡張します。Gateway リスナーまたは Route ホスト名でホスト名が指定されると、コントローラーは AWS Certificate Manager (ACM) にクエリを実行して、ホスト名マッチングに基づいて一致する証明書を見つけて添付します。 コントローラーは証明書の更新について ACM を監視し、ロードバランサー構成に変更を自動的に適用します。これにより、手動での証明書 ARN 管理が不要になり、複数の環境間での証明書ローテーションの運用複雑性が軽減されます。 これらの機能により運用オーバーヘッドを削減し、関心の分離を改善した本格的な AWS 上の Kubernetes ネットワーキングが可能になります。型安全な CRD、Cross-Namespace ルーティング、自動証明書管理の組み合わせにより、チームはインフラストラクチャ構成ではなくアプリケーション配信に集中できます。 始め方 初回ユーザーの場合は、インストールガイドに従ってください。このガイドでは、必要な AWS Identity and Access Management (IAM) 権限を設定し、AWS Load Balancer Controller を Kubernetes クラスターにデプロイします。 AWS Load Balancer Controller で Gateway API サポートを有効にするには、まず 前提条件 が満たされていることを確認してください。その後、Gateway API サポートを有効にするには、 こちら で説明されているように機能フラグを有効にする必要があります。 構成例 この例では、AWS Load Balancer Controller Gateway API 統合の 3 つの主要機能を実証します : HTTP ルーティング、自動証明書検出を使用した HTTPS ルーティング、ListenerRuleConfiguration を使用したカスタムルーティングルール。デプロイメント手順と検証コマンドを含む完全なウォークスルーについては、AWS Load Balancer Controller Gateway API の例を参照してください。 この例では、以下のアーキテクチャでALBをプロビジョニングします： ポート 80 の HTTP リスナーが blue デプロイメントにルーティング ポート 443 の HTTPS リスナーが自動証明書検出により orange デプロイメントにルーティング HTTP リスナー上の /alb-response パスに対して固定レスポンスを返すカスタムルーティングルール 構成概要 構成には以下が含まれます: AWS Load Balancer Controller を実装として定義する GatewayClass : # alb-gatewayclass.yaml apiVersion: gateway.networking.k8s.io/v1beta1 kind: GatewayClass metadata: name: aws-alb-gateway-class spec: controllerName: gateway.k8s.aws/alb HTTP および HTTPS リスナーを持つ Gateway : # my-alb-gateway.yaml apiVersion: gateway.networking.k8s.io/v1beta1 kind: Gateway metadata: name: my-alb-gateway namespace: example-ns spec: gatewayClassName: aws-alb-gateway-class infrastructure: parametersRef: kind: LoadBalancerConfiguration name: lbconfig-gateway group: gateway.k8s.aws listeners: - name: http protocol: HTTP port: 80 allowedRoutes: namespaces: from: Same - name: https hostname: "sample.com" protocol: HTTPS port: 443 allowedRoutes: namespaces: from: Same スキームまたはその他のゲートウェイ構成パラメータ用の LoadBalancerConfiguration : # lb-config-gateway.yaml apiVersion: gateway.k8s.aws/v1beta1 kind: LoadBalancerConfiguration metadata: name: lbconfig-gateway namespace: example-ns spec: loadBalancerName: "my-example-gateway-alb" scheme: internet-facing カスタムルーティング動作用の ListenerRuleConfiguration : # listener-rule-config-blue.yaml apiVersion: gateway.k8s.aws/v1beta1 kind: ListenerRuleConfiguration metadata: name: blue-lrc-config namespace: example-ns spec: actions: - type: "fixed-response" fixedResponseConfig: statusCode: 404 contentType: "text/plain" messageBody: "customized text" リスナーをバックエンドサービスにマッピングする HTTPRoutes : # httproute-blue.yaml apiVersion: gateway.networking.k8s.io/v1beta1 kind: HTTPRoute metadata: name: http-route-blue namespace: example-ns spec: parentRefs: - group: gateway.networking.k8s.io kind: Gateway name: my-alb-gateway sectionName: http rules: - matches: - path: value: "/alb-response" filters: - type: ExtensionRef extensionRef: group: "gateway.k8s.aws" kind: "ListenerRuleConfiguration" name: "blue-lrc-config" - backendRefs: - name: service-blue port: 80 # httproute-orange.yaml apiVersion: gateway.networking.k8s.io/v1beta1 kind: HTTPRoute metadata: name: http-route-orange namespace: example-ns spec: parentRefs: - group: gateway.networking.k8s.io kind: Gateway name: my-alb-gateway sectionName: https rules: - backendRefs: - name: service-orange port: 80 デプロイとテスト この例をデプロイするには、バックエンドの DeploymentsとServices が必要です。以下のリソースを作成してください: # deployment-orange.yaml apiVersion: apps/v1 kind: Deployment metadata: name: deployment-orange namespace: example-ns spec: selector: matchLabels: app: orange-app replicas: 1 template: metadata: labels: app: orange-app spec: containers: - image: k8s.gcr.io/e2e-test-images/echoserver:2.5 imagePullPolicy: Always name: echoserver ports: - containerPort: 8080 --- # deployment-blue.yaml apiVersion: apps/v1 kind: Deployment metadata: name: deployment-blue namespace: example-ns spec: selector: matchLabels: app: blue-app replicas: 1 template: metadata: labels: app: blue-app spec: containers: - image: k8s.gcr.io/e2e-test-images/echoserver:2.5 imagePullPolicy: Always name: echoserver ports: - containerPort: 8080 --- # service-orange.yaml apiVersion: v1 kind: Service metadata: name: service-orange namespace: example-ns spec: ports: - port: 80 targetPort: 8080 protocol: TCP type: NodePort selector: app: orange-app --- # service-blue.yaml apiVersion: v1 kind: Service metadata: name: service-blue namespace: example-ns spec: ports: - port: 80 targetPort: 8080 protocol: TCP type: ClusterIP selector: app: blue-app Gateway がプロビジョニングされるまで待機します: kubectl wait --for=condition=Programmed gateway/my-alb-gateway -n example-ns デプロイメントの検証 blue デプロイメントへの HTTP ルーティングをテストします: # ALB ホスト名を取得 ALB_HOSTNAME=$(kubectl get gateway my-alb-gateway \ -n example-ns \ -o jsonpath='{.status.addresses[0].value}') # HTTP エンドポイントをテスト curl http://$ALB_HOSTNAME orange デプロイメントへの証明書検出を使用した HTTPS ルーティングをテストします: curl -k https://$ALB_HOSTNAME -H "Host: sample.com" カスタムルーティングルールをテストします: curl http://$ALB_HOSTNAME/alb-response NLB 構成、Cross-Namespace ルーティング、高度なカスタマイゼーションシナリオを含むその他の例については、AWS Load Balancer Controller ドキュメントを参照してください。 考慮事項 GatewayClass によるポリシー強制 : プラットフォームチームは、サブネット配置、セキュリティグループ割り当て、アクセスログを制御する LoadBalancerConfiguration 設定を持つ GatewayClass リソースを定義します。アプリケーションチームは、インフラストラクチャ変更権限なしに承認された GatewayClass オプションから選択します。これにより、 Kubernetes RBAC を通じて内部ワークロードをインターネット向けロードバランサーから分離するなどの組織ポリシーが強制されます。 標準ベースの移植性 : Gateway、GatewayClass、Route リソースは Kubernetes Gateway API 仕様に従います。コアルーティングロジックは実装間で一貫性を保ちます。AWS 固有の CRD (LoadBalancerConfiguration、TargetGroupConfiguration、ListenerRuleConfiguration) はオプションのままで、コアルーティング定義から分離されています。これにより、必要に応じてAWS固有の機能を持つポータブルなアプリケーション構成が可能になります。 運用可視性 : コントローラーは、リアルタイムプロビジョニング進行状況、リソース識別子 (ロードバランサー ARN と DNS 名)、エラーメッセージで Gateway API ステータスフィールドを更新します。これにより、トラブルシューティング時間が短縮され、リソース状態を確認するための直接的な AWS API クエリが不要になります。 AWS サービス統合 : この実装は、自動証明書検出のための ACM、アプリケーション保護のための AWS WAF 、DDoS 保護のための AWS Shield Advanced と統合されます。ターゲットグループ構成、ヘルスチェック、アクセスログは Amazon S3 および Amazon CloudWatch と統合されます。 GitOps 互換性 : スキーマ検証を持つ型安全な CRDは、デプロイ前検証中に構成エラーを表面化します。Infrastructure as Code (IaC) ツールである Flux 、 ArgoCD 、Kubernetes 用 AWS Cloud Development Kit (AWS CDK) は、自動ドリフト検出を伴う宣言的インフラストラクチャ管理のための Gateway API サポートを提供します。 まとめ AWS Load Balancer Controller の Gateway API サポートは、AWS 上での Kubernetes トラフィック管理に対する標準ベースのアプローチを提供します。Gateway API 仕様を採用することで、Kubernetes 環境間での移植性を維持しながら、ロール指向のリソース管理、Cross-Namespace ルーティング機能、型安全な CRD による拡張されたカスタマイゼーションを得ることができます。プラットフォームチームが Ingress ベースの構成から移行する場合でも、新しい Kubernetes デプロイメントを構築する場合でも、Gateway API 統合によってアプリケーションチームにセルフサービスルーティング機能を提供しながら組織ポリシーを強制することができます。この実装は、証明書管理、セキュリティ、可観測性のためのネイティブ AWS 統合と組み合わせることで運用ワークフローを合理化し、構成の複雑性を軽減します。AWS Load Balancer Controller デプロイメントで Gateway API サポートを有効にして、今すぐ始めましょう。詳細な構成例とベストプラクティスについては、AWS Load Balancer Controller ドキュメントを参照してください。

はじめに こんにちは、クラウドエース株式会社第１開発部の高牟禮です。 昨今、AI を活用したコーディング支援ツールが急速に普及しています。 Google が提供する AI 開発ツールにも様々なものがあり、最近では Jules なども話題に上がりますが、本格的に「 AI エージェントを活用した開発」を自身の開発環境に組み込む際、公式ブログでも比較されている以下の2つのツールが非常に強力な選択肢となります。 Google Antigravity: Google が提供する AI ネイティブな統合開発環境（IDE）。エディタと AI が深く統合されており、単なるチャットアシスタントにと

本ブログは 2026 年 3 月 17 日に公開された AWS Blog、” Essential security controls to prevent unauthorized account removal in AWS Organizations ” を翻訳したものです。 AWS メンバーアカウントが侵害された場合、攻撃者はアカウントを組織から離脱させ、すべてのガバナンスコントロールを無効化する可能性があります。本記事では、サービスコントロールポリシー (SCP)、安全なアカウント移行、一元化されたルートアクセス管理などの多層的なセキュリティコントロールを使用して、AWS 環境をアカウント侵害から保護する方法を解説します。 AWS はクラウドを実行するインフラストラクチャのセキュリティを担い、お客様はクラウド内のワークロードとデータのセキュリティを担います。そのために、AWS Organizations には不正なアカウント離脱を防止し、アカウント全体のガバナンスを維持するセキュリティコントロールが含まれています。 本記事では、4 つのコントロールについて説明します。サービスコントロールポリシー (SCP) による不正なアカウント離脱の防止、正当な移行のためのブレークグラス手順の確立、組織間でのアカウントの直接移行、およびメンバーアカウントのルートアクセスの無効化です。 前提条件 本記事では、 AWS Organizations と マルチアカウント戦略の概念 に精通している必要があります。以下の権限を持つ AWS Organizations 管理アカウントへのアクセスが必要です。 サービスコントロールポリシーの作成とアタッチ — organizations:CreatePolicy 、 organizations:AttachPolicy 組織単位の管理 — organizations:CreateOrganizationalUnit 、 organizations:MoveAccount 一元化されたルートアクセス管理の有効化 — iam:EnableOrganizationsRootCredentialsManagement セキュリティと柔軟性を両立する組織単位 (OU) 構造の設計 マネージドサービスプロバイダー、リセラー、アカウントの入れ替わりが多い組織など、メンバーアカウントが定期的に組織を離脱することを許可する必要があるビジネスモデルの場合、最初からこのワークフローを考慮して OU 構造を設計する必要があります。 アカウントのライフサイクルステージ (オンボーディング、アクティブ、オフボーディング) ごとに専用の OU を作成し、長期的なガバナンス下に置くべきアカウントを含む OU にのみ DenyLeaveOrganization SCP を適用することを検討してください。このアプローチにより、コアインフラストラクチャを保護しつつ、短期間のアカウントの移行を簡素化できます。 セキュリティコントロールと運用の柔軟性のバランスを取る 階層的な OU 構造を作成 してください。本番環境と開発環境の OU に DenyLeaveOrganization SCP を適用して重要なワークロードを保護し、制御されたアカウント移行のためにこの制限のない別の移行用 OU を維持します。 推奨される OU アーキテクチャ 本番 OU: DenyLeaveOrganization SCP を適用して、本番ワークロードを実行するアカウントが組織を離脱することを防止します 開発 OU: 同じ SCP を適用して、開発およびテスト環境のガバナンスを維持します 移行 OU: DenyLeaveOrganization SCP を適用せず、組織を離脱する準備をしているアカウントの制御されたステージングエリアとして機能させます 正当なビジネス上の理由でアカウントが組織を離脱する必要がある場合、管理アカウントはそのアカウントを移行 OU に移動でき、メンバーアカウントの離脱操作が可能になります。これにより、明確な承認ワークフローが作成され、移行プロセス全体の可視性が維持されます。 管理アカウントは組織からメンバーアカウントを離脱させることができるため、メンバーアカウントが自ら離脱する正当な必要性がない場合は、離脱アカウント用の移行 OU アプローチを実装する必要はありません。 OU 構造の整理と管理に関する詳細なガイダンスについては、 AWS Organizations での組織単位の管理に関する AWS ベストプラクティス を参照してください。 組織離脱アクションを拒否するサービスコントロールポリシーの実装 メンバーアカウントが組織を離脱することを防止するには、メンバーアカウントに対して organizations:LeaveOrganization アクションを拒否する SCP を実装します。この予防的コントロールにより、アカウントがガバナンスフレームワーク内に留まり、セキュリティコントロールと組織ポリシーが維持されます。 AWS マネジメントコンソールを使用した SCP の作成 管理アカウントで AWS Organizations コンソールにサインインします。 ナビゲーションペインで ポリシー を選択します。 サービスコントロールポリシーを有効化 します。 ポリシーの作成 を選択します。 ポリシー名を入力します (例: “DenyLeaveOrganization” )。 ポリシーエディタに以下の JSON を入力します。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": "organizations:LeaveOrganization", "Resource": "*" } ] } ポリシーの作成 をクリックします。 AWS CLI を使用した SCP の作成 以下のコマンドを実行してポリシーを作成します。 aws organizations create-policy \ --name DenyLeaveOrganization \ --type SERVICE_CONTROL_POLICY \ --description "Prevents member accounts from leaving the organization" \ --content '{"Version":"2012-10-17","Statement":[{"Effect":"Deny","Action":"organizations:LeaveOrganization","Resource":"*"}]}' 次のステップで使用するため、出力からポリシー ID を記録してください。 ポリシーを作成したら、 移行 OU を制限なしのまま維持しつつ、 本番 OU と 開発 OU に DenyLeaveOrganization SCP を適用します。 AWS マネジメントコンソールを使用した OU への SCP のアタッチ AWS Organizations に移動します。 対象の OU ( 本番 または 開発 ) を選択します。 ポリシー タブを選択します。 アタッチ を選択し、「DenyLeaveOrganization」ポリシーを選択します。 ポリシーが必要な各 OU に対して繰り返します。 AWS CLI を使用した OU への SCP のアタッチ 作成ステップで取得したポリシー ID を使用して、対象の OU にポリシーをアタッチします。 aws organizations attach-policy --policy-id p-xxxxxxxx --target-id r-xxxx ポリシーのアタッチを確認します。 aws organizations list-targets-for-policy --policy-id p-xxxxxxxx ポリシーが必要な各 OU に対して繰り返します。 このコントロールは、コンソール、CLI、SDK を通じた API レベルでの離脱の試みをブロックします。管理アカウントの保護に関するベストプラクティスについては、 ドキュメント を参照してください。 SCP は管理アカウントには適用されず、組織内のメンバーアカウントにのみ影響することに注意してください。そのため、管理アカウントを MFA、アクセス制限、一時的な認証情報のみの使用、包括的なモニタリングなど、可能な限り強力なセキュリティコントロールで保護することが不可欠です。 ブレークグラス手順の文書化 アカウントの移行、合併、買収、事業売却の際に特定のアカウントが組織を離脱することを許可する必要がある場合は、文書化された承認ワークフローと技術的メカニズムを備えた正式なプロセスを確立してください。 シナリオに適したブレークグラスメカニズムを選択してください。アカウントが組織を離脱する必要がある場合、標準的な変更管理プロセスを通じて、現在の OU から移行 OU に移動します。移行 OU に移動すると、DenyLeaveOrganization SCP の制限なしに離脱操作を実行できます。このアプローチにより、組織ルート全体から SCP を一時的に削除することなく、すべてのアクティブなアカウントのセキュリティコントロールが維持されます。 メンバーアカウント離脱の文書化された例外プロセスの確立 安全な招待ベースの移行プロセスの外で、メンバーアカウントが独自に組織を離脱する場合は、正式な承認を必要とする例外として扱う必要があります。各例外リクエストには、標準的な組織間移行プロセスを使用できない理由を説明する明確なビジネス上の正当性と、セキュリティおよびガバナンスポリシー要件との整合性を検証するためのセキュリティおよび IT 管理チームによるレビューと承認が含まれている必要があります。 この例外をセキュリティベースラインに文書化し、移行 OU は標準的な招待ベースの移行を使用できない承認済みの移行中の一時的なアカウントステージングのためにのみ存在することを明示的に記載してください。この文書化により、説明責任が確立され、コンプライアンスレビューのための監査証跡が作成され、セキュリティコントロールの例外が意図的で、正当化され、期限付きであることが保証されます。 合併・買収時のアカウントの安全な移行 合併、買収、または組織統合の際、AWS Organizations は組織間の安全な直接アカウント移行をサポートし、アカウントがスタンドアロンになることを防止します。移行先の組織の管理アカウントが移行するアカウントに招待を送信します。承認されると、アカウントは組織のガバナンスの外で運用されることなく、移行元から移行先の組織にシームレスに移行します。サービスコントロールポリシー (SCP)、ログ記録、モニタリングは移行中も継続的に適用され、セキュリティ体制が維持され、 AWS CloudTrail を通じた完全な監査証跡が作成されます。 この招待ベースのアプローチは、アカウントが独立して運用される際に発生するセキュリティギャップを防止しながら、ほとんどの正当な移行ユースケースに対応します。管理アカウントがメンバーアカウントを手動で離脱させる必要はなく、招待プロセスが移行を自動的に処理します。移行後は、適切なポリシーが適用されていることを確認し、正しい組織 ID で IAM ポリシーを更新し、請求設定、税金設定、リザーブドインスタンスの移行を確認してください。詳細なガイダンスについては、 AWS Organizations ユーザーガイドのアカウント移行 を参照してください。 メンバーアカウントのルートアクセスの脆弱性の排除 メンバーアカウントのルートユーザー認証情報は、AWS 環境における最高レベルの特権アクセスであり、AWS Identity and Access Management (IAM) ポリシーやサービスコントロールポリシーをバイパスできます。2025 年の AWS 一元化されたルートアクセス管理の開始以降、新しく作成されたメンバーアカウントにはデフォルトでルートユーザー認証情報がなくなりました。これは、組織内のすべての新しいアカウントの標準的な動作です。新しく作成されたメンバーアカウントはルートユーザー認証情報なしで自動的にプロビジョニングされるため、多要素認証の設定などのプロビジョニング後のセキュリティ対策が不要になります。 このデフォルトが有効になる前に作成された既存のアカウントについては、長期間有効なルートユーザー認証情報の削除は迅速かつ簡単です。AWS 一元化されたルートアクセス管理を使用すると、パスワード、アクセスキー、署名証明書、MFA デバイスなどのルートユーザー認証情報を、管理アカウントから組織全体にわたって直接削除できます。各メンバーアカウントに個別にサインインする必要はありません。 この一元化されたアプローチにより、メンバーアカウント全体で一貫したセキュリティが維持されます。また、アカウント作成とセキュリティ設定の間の脆弱性ギャップを排除することで、運用オーバーヘッドが削減されます。一元化されたルートアクセス管理の実装に関する詳細なガイダンスについては、 メンバーアカウントのルートアクセスの一元管理 を参照してください。 AWS マネジメントコンソールを使用したルートユーザー認証情報の削除 管理アカウントを使用して IAM コンソールを開きます。 ナビゲーションペインの アクセス管理 で、 ルートアクセス管理 を選択します。 一元化されたルートアクセス管理がまだ有効になっていない場合、ページの上部にバナーまたはプロンプトが表示されます。 有効化 を選択してアクティブにします。プロンプトが表示されない場合、この機能は組織で既に有効になっています。有効化すると、ページにメンバーアカウントを含む組織構造が表示されます。 アカウントを選択し、右側のルートユーザー認証情報パネルを確認します。アクティブなルートユーザー認証情報がまだあるアカウントについては、 ルートユーザー認証情報の削除 を選択して削除します。 図 1: ルートアクセス管理 AWS CLI を使用した一元化されたルートアクセス管理の有効化 以下のコマンドを実行して、一元化されたルートアクセス管理を有効化します (既に有効な場合でも安全に実行でき、現在の機能の状態が返されます)。 aws iam enable-organizations-root-credentials-management 有効化された機能を確認して設定を検証します。 aws iam list-organizations-features 出力を確認して、有効化が成功したことを確認します。機能が有効化されている場合、以下のように表示されます。 { "OrganizationId": "o-xxxxxxxxxxxx", "EnabledFeatures": [ "RootSessions", "RootCredentialsManagement" ] } 機能がまだ有効化されていない場合、 aws iam list-organizations-features は以下のように空の EnabledFeatures 配列を返します。 { "OrganizationId": "o-xxxxxxxxxxxx", "EnabledFeatures": [] } まとめ AWS Organizations をアカウント侵害から保護するには、保護と運用の柔軟性のバランスを取る多層的なセキュリティコントロールが必要です。DenyLeaveOrganization サービスコントロールポリシーは、不正なアカウント離脱をブロックし、継続的なガバナンスの監視を維持します。組織間の招待ベースのアカウント移行機能は、セキュリティギャップを作ることなく、合併、買収、統合などの正当なビジネスニーズをサポートします。AWS 一元化されたルートアクセス管理によるルートアクセスの排除は、セキュリティコントロールをバイパスできる最高特権の経路を削除します。 これらのコントロールにより、侵害された認証情報を使ったアカウントの組織からの離脱を防止し、移行中もサービスコントロールポリシーとログ記録をアクティブに保ち、セキュリティインシデントをガバナンスフレームワーク内に封じ込めることで、問題の検出、対応、修復をより迅速に行えるようになります。 まず OU 構造を設計し、ブレークグラス手順を文書化してから、DenyLeaveOrganization SCP を適用し、AWS 一元化されたルートアクセス管理を有効化してください。OU 構造を定期的にレビューし、例外リクエストを監査し、AWS CloudTrail を通じて不正アクセスの試みを監視してください。アカウントガバナンスを重要なセキュリティコントロールとして扱い、AWS 環境を安全でコンプライアンスに準拠し、ビジネス目標に沿った状態に保ちましょう。サービスコントロールポリシーの例とテンプレートについては、 AWS SCP Examples GitHub リポジトリ をご覧ください。 著者について Nivedita Tripathi Nivedita Tripathi は AWS Organizations のシニアプロダクトマネージャーです。セキュリティとガバナンスのベストプラクティスを活用し、組織が設定したコンプライアンス境界内で、お客様が複数のアカウントにわたるクラウドインフラストラクチャを構築・拡張できるよう支援することに注力しています。テクノロジーへの情熱に加え、音楽、世界旅行、家族との時間を楽しんでいます。 Ryan Bates Ryan は AWS のテクニカルアカウントマネージャーです。学ぶことと、学んだことで人々を助けることが大好きです。IT 業界で 20 年以上の経験があり、エンドユーザーサポート、インフラストラクチャサポート、IT 部門の構築を担当してきました。お客様のことに没頭していない時は、家族との時間、ワインテイスティング、ディズニーランドへの訪問を楽しんでいます。 Samir Behara Samir Behara は AWS プロフェッショナルサービスのシニアクラウドインフラストラクチャアーキテクトです。クラウド導入戦略を通じて、お客様の IT モダナイゼーションの加速を支援することに情熱を注いでいます。豊富なソフトウェアエンジニアリングのバックグラウンドを持ち、パフォーマンス、運用効率、イノベーションのスピード向上を推進するために、アプリケーションアーキテクチャと開発プロセスを深く掘り下げることを好みます。 翻訳は Security Solutions Architect の 松崎 博昭 が担当しました。