メインコンテンツに移動

builders.flash

Amazon EKS で実現するプラットフォームエンジニアリング - GitOps によるセルフサービス型開発プラットフォーム

2026-04-02 | Author : 林 政利

はじめに


プラットフォームエンジニアリングは、インフラストラクチャーや運用プロセスを抽象化したプラットフォームを「プロダクト」として構築 (エンジニアリング) する取り組み全般を指す、幅広い概念です。近年、広く浸透してきており、皆さんも耳にされたことがあるかもしれません。

プラットフォームエンジニアリングにより、開発者はセルフサービスでソフトウェアを開発・運用でき、また、プラットフォームチームと開発チームの責任範囲が明確になることで、組織全体の生産性が向上します。

本記事では、Amazon EKS (Elastic Kubernetes Service) を活用したプラットフォームエンジニアリングのリファレンス実装を紹介します。実際に手を動かしながら、以下の技術やコンセプトを体験できます。

  • EKS Auto Mode : Kubernetes データプレーン とアプリケーション実行に必要な多くのアドオンをマネージドで提供する新しい Amazon EKS の運用モデル
  • EKS Capabilities - Argo CD : AWS がフルマネージドで提供する GitOps ツール
  • EKS Capabilities - ACK : EKS Capabilities を通じてフルマネージドで利用する AWS リソース管理ツール
  • Argo Rollouts : Blue/Green デプロイメントによる安全なリリース戦略

この記事を通じて、モダンな開発プラットフォームの構築方法を学び、実際に動作するプラットフォームを構築できます。


本プロジェクトのソースコードは GitHub にアップロードしています。
 

X ポスト » | Facebook シェア » | はてブ »


 

builders.flash メールメンバー登録

builders.flash メールメンバー登録で、毎月の最新アップデート情報とともに、AWS を無料でお試しいただけるクレジットコードを受け取ることができます。

今すぐ登録 »

対象読者

  • Kubernetes の基本的な知識がある方
  • AWS のサービスを使った経験がある方
  • プラットフォームエンジニアリングや GitOps に興味がある方
  • 開発チームに自律的な環境を提供したいプラットフォームエンジニア

アーキテクチャ概要

今回構築するプラットフォームは、以下のコンポーネントで構成されます。図中の色分けにより、プラットフォームチームと開発チームの責任領域を明確にしています。

本リファレンスアーキテクチャの責任共有モデル

上記の図を確認しながら、これから構築する「プラットフォーム」の責任共有モデルを俯瞰します。責任共有モデルとはつまり、プラットフォームとしてのインターフェースをどのように設計しているのか、ということです。

開発チームの責任 (オレンジ色)

  • アプリケーションコードの開発とビルド
  • Kubernetes マニフェストの作成・更新 (レプリカ数、リソース制限、環境変数などのアプリケーション設定)
  • Git へのプッシュ (デプロイはプラットフォームで実施)
  • ブルーグリーンデプロイの指示 (デプロイ自体はプラットフォームが実施)

プラットフォームチームの責任 (青色)

  • Terraform によるインフラ構築 (Amazon VPC、EKS、AWS IAM)
  • プラットフォームが利用する Git リポジトリの管理
    - プラットフォーム用リポジトリ - プラットフォームを設定する Kubernetes マニフェストを管理 (Namespace ごとのクォータ設定、OSS のアドオン類、Auto Mode のノードプール設定など)
    - ワークロード用リポジトリ - 開発者に公開される、アプリケーション用のマニフェストを格納するリポジトリ。Kustomize を利用
  • AWS IAM や Kubernetes RBAC、EKS Pod Identity など、権限の設計と管理

権限の設計と管理

AWS IAM や Kubernetes RBAC、EKS Pod Identity など、権限の設計と管理

開発者が自律的に作業できる環境を提供

このように、プラットフォームエンジニアリングで重要な点は、プラットフォームチームと開発チームの間で明確な責任分担を行い、開発者が自律的に作業できる環境を提供することです。

もう少し詳しく、本プロジェクトで実装する責任共有モデルを深掘りしてみましょう。もちろん実際の組織では、チームの成熟度や要件に応じて、この責任共有モデルを調整することができます。

責任共有モデルを深掘りする

プラットフォームチームの責任

開発者が安全かつ効率的に作業できる「プラットフォーム」を提供します。

インフラ構築 : クラスターやネットワークの構築・管理

  • EKS Auto Mode により、Kubernetes インフラストラクチャの認知負荷を削減ノードやストレージを AWS が自動管理


標準化 :
統一された開発環境の提供

  • Auto Mode の Ingress Class や Node Pool を設計することで、アプリケーションチームが容易にコンピュートやロードバランサー、ストレージを標準にしたがって利用できるようにする
  • Namespace ごとのリソース制限やネットワークポリシーを標準化
  • Namespace の設定は Helm チャート化して展開


セキュリティ :
権限管理とガバナンスの維持

  • 後述するAWS Controllers for Kubernetes (ACK) と IAM Role Selector を利用して、開発チームごとに最小権限の原則に基づいた IAM の権限を設計、提供


ツール提供 :
デプロイ戦略や監視などの共通機能

  • Argo CD: OSS で開発されている GitOps ツール。EKS Capabilities によるフルマネージド版を利用することでインフラストラクチャの認知負荷を低減
  • AWS Controllers for Kubernetes (ACK): OSS で開発されている AWS のリソースを Kubernetes で管理できるリソース管理ツール。Argo CD と同様、EKS Capabilities によるフルマネージド版を利用することでインフラストラクチャの認知負荷を低減
  • Argo Rollouts: OSS で開発されている Progressive Delivery を Kubernetes で実現するためのツール。Blue/Green デプロイメントなどの高度なリリース戦略を提供。このような OSS のアドオンは、プラットフォーム用のリポジトリに helm チャートの設定を格納することで、指定の EKS クラスターに導入される

開発チームの責任

プラットフォームが提供する機能を活用してアプリケーションを開発・運用します。

アプリケーション開発 : ビジネスロジックの実装

  • プラットフォームの詳細を意識せず、コードに集中


アプリケーションの設定管理 :
アプリケーションの動作設定

  • Kubernetes マニフェストでレプリカ数やリソース制限を定義
  • Git にプッシュすれば Argo CD が自動デプロイ

デプロイ操作 : 新バージョンのリリース判断

  • ブルーグリーンデプロイを指示する
    - Preview 環境で新バージョンを確認
    - 問題なければ手動で Promotion して本番環境に切り替え

リソース管理 : 必要なクラウドリソースの作成・削除

  • Auto Mode により、インフラストラクチャを意識することなく AWS のロードバランサーやストレージを利用
  • ACK を使って Kubernetes マニフェストで S3 バケットなどを管理
  • プラットフォームチームが設定した権限の範囲内で自律的に AWS リソースを操作
     

責任分担の利点

この明確な分離により、以下のメリットが得られます。

開発チームにとって

  • インフラの詳細を意識せずにアプリケーション開発に集中
  • セルフサービスで必要なリソースを迅速に利用
  • 標準化された環境により学習コストが低減

プラットフォームチームにとって

  • セキュリティとガバナンスを一元管理
  • 標準化によりサポートコストが削減
  • 開発チームの自律性を高めながら統制を維持

組織全体にとって

  • 開発速度の向上
  • セキュリティリスクの低減
  • 運用コストの最適化
     

ハンズオン : プラットフォームを構築してみよう

それでは、実際にプラットフォームを構築していきましょう。 このハンズオンでは、まず「プラットフォームチーム」の立場でプラットフォームを構築し、その後「開発チーム」の立場でアプリケーションをデプロイします。この流れを通じて、プラットフォームエンジニアリングにおける責任分担を体験できます。

前提条件

以下のツールがインストールされていることを確認してください。

  • AWS CLI
  • Terraform >= 1.14.0
  • kubectl >= 1.34
  • Git

また、本リファレンスアーキテクチャで利用する EKS Capabilities は、 Argo CD への認証に AWS IAM Identity Center を利用します。 セットアップがまだの場合は、AWS ドキュメント を参照してセットアップしてください。

パート 1 : プラットフォームチームの作業

プラットフォームチームとして、開発者が利用するプラットフォームを構築します。ここで構築するのは以下の様な環境です。

  • EKS クラスター (および関連する VPC などの AWS リソース)
  • CodeCommit リポジトリ (プラットフォーム用 / ワークロード用)
  • Namespace 標準設定 (ResourceQuota、NetworkPolicy など)
  • GitOps によるアドオン類 (Argo Rollouts) の導入
  • Amazon CloudWatch Container Insights を利用したモニタリングのセットアップ

ステップ 1 : リポジトリのクローン

本リファレンスアーキテクチャのソースコードをクローンします。

bash
git clone git@github.com:aws-samples/sample-platform-engineering-on-eks.git
cd sample-platform-engineering-on-eks

export PROJECT_DIR=$(pwd)

ステップ 2 : Terraform 変数の設定

本リファレンスアーキテクチャは Terraform で構築されます。環境に合わせて Terraform の変数を設定します。これらの設定は、プラットフォーム全体の基本構成を決定します。

bash
cd environments/sample
cat << EOF > terraform.tfvars
# AWS プロファイル名
aws_profile = "your-aws-profile"

# デプロイ先のリージョン
aws_region = "ap-northeast-1"

# リソース名のプレフィックス(AWS アカウント内でのリソース名の衝突を避けるため)
resource_prefix = "ex-idp"

# IAM Identity Center の設定
argo_cd_idc_region = "ap-northeast-1"
argo_cd_idc_instance_arn = "arn:aws:sso:::instance/ssoins-xxxxxxxxxx"

# Argo CD の管理者権限を付与する Identity Center グループ
# キー: グループ ID、値: グループ名
argo_cd_idc_groups = {
  "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" = "ADMIN"
}
EOF

ポイント : argo_cd_idc_instance_arn と argo_cd_idc_groups は、IAM Identity Center の設定から取得します。上記の設定で、グループと Argo CD 内の権限をマッピングしています。

ステップ 3 : インフラのデプロイ

Terraform でインフラを構築します。

bash
terraform init
terraform plan
terraform apply

デプロイには約 15-20 分かかります。この間に、以下のリソースが作成されます。

  • EKS クラスターを含む AWS リソース
  • EKS Capabilities - Argo CD, ACK
  • 2つの CodeCommit リポジトリ (プラットフォーム / ワークロード 用)

ステップ 4 : クラスターへの接続

デプロイが完了したら、kubectl でクラスターに接続します。クラスター名は、作成されたクラスター名に合わせてください。

bash
export AWS_REGION=ap-northeast-1
aws eks update-kubeconfig --name ex-idp-dev-cluster

# ノードの確認
kubectl get nodes

EKS Auto Mode により、必要に応じてノードが自動的にプロビジョニングされます。

ステップ 5 : Argo CD へのアクセス

EKS Capabilities の Argo CD は、AWS が管理する専用 URL からアクセスします。

bash
# Argo CD の URL を取得
aws eks describe-capability \
  --cluster-name ex-idp-dev-cluster \
  --capability-name argocd \
  --query 'capability.configuration.argoCd.serverUrl' \
  --output text

ブラウザで URL を開き、IAM Identity Center でログインします。

ステップ 6 : GitOps リポジトリのセットアップ

このリファレンスアーキテクチャでは、Argo CD による GitOps でプラットフォームの構成やアプリケーションをデプロイを管理します。プラットフォームの構成を管理する Git リポジトリと、ワークロードのデプロイを管理する Git リポジトリに分けて管理します。 リポジトリは、上記のセットアップで作成されていますので、ここでは、それらのリポジトリに必要なマニフェストをプッシュします。

bash
# CodeCommit リポジトリの URL を取得
export PLATFORM_REPO_URL=$(terraform output -raw platform_repo_url)
export WORKLOAD_REPO_URL=$(terraform output -raw workload_repo_url)

# 作業ディレクトリを作成
mkdir -p tmp

# Platform 設定をプッシュ
cp -r $PROJECT_DIR/repositories/platform tmp/platform
cd tmp/platform
git init
git add .
git commit -m "Initial platform configuration"
git remote add origin $PLATFORM_REPO_URL
git push -u origin main

# Workload マニフェストをプッシュ
cd ..
cp -r $PROJECT_DIR/repositories/workloads tmp/workloads
cd workloads
git init
git add .
git commit -m "Initial workload manifests"
git remote add origin $WORKLOAD_REPO_URL
git push -u origin main

プラットフォームチームの視点 : - プラットフォーム リポジトリ : Namespace の標準設定、Argo Rollouts などのアドオン、ApplicationSet の定義を管理します。これらはプラットフォームチームが管理し、開発チームは通常触りません - ワークロード リポジトリ: 開発チームがアプリケーションのマニフェストを管理します。プラットフォームチームが設定した ApplicationSet により自動的に検出されるため、開発チームはやることはこのリポジトリに Kubernetes のマニフェストを格納するだけです。 Argo CD の設定を意識する必要がありません
この分離により、プラットフォームの設定と個別のアプリケーションを独立して管理できます。

ポイント : CodeCommit への認証には、AWS CLI の認証情報ヘルパーまたは git-remote-codecommit を使用してください。詳細は AWS CodeCommit のドキュメントを参照してください。

ステップ 7 : デプロイの確認

Argo CD UI にアクセスして、以下を確認します:

  1. bootstrap ApplicationSet が作成されている
  2. 以下の Application が自動生成されている:
    - bootstrap-namespaces : Namespace 設定
    - bootstrap-workloads : ワークロード設定
    - config-addons : Argo Rollouts などのアドオン
  3. workloads-ex-app-bg-demo-dev Application が作成され、同期されていることを確認
  4. Application をクリックして、Rollout、Service、Ingress のリソースを確認


プラットフォームチームの視点 : ApplicationSet の階層構造により、新しい Namespace を開発チームに払い出す際も、Git リポジトリの namespaces/ にファイルを設定するのみとなっています。これにより、プラットフォームチームの運用負荷も大きく削減できます。

bootstrap # 設定のルートとなる ApplicationSet で、Terraform により作成される
├|── bootstrap-namespaces # Namespace 設定を自動検出
├── bootstrap-workloads # ワークロードを自動検出
├── config-addons # クラスターアドオン
└── config-automode # EKS Auto Mode 設定

これで、プラットフォームの基本構成が完了しました!

パート 2 : 開発チームの作業

ここからは、開発チームの立場に切り替えます。プラットフォームチームが構築したプラットフォームを利用して、アプリケーションをデプロイしていきます。

今回デプロイするのは「Distribution Monitor」という Spring Boot アプリケーションです。複数の Pod 間でリクエストがどのように分散されているかを可視化するシンプルなアプリケーションです。

ステップ1 : アプリケーションのビルドとプッシュ

bash
cd apps/distribution-monitor

# ECR にログイン
make login

# イメージをビルド
make build

# ECR にプッシュ
make push

# イメージ情報を環境変数に保存
export IMAGE_REPO=$(make image-repo)
export IMAGE_TAG=$(make image-tag)

echo "Image Repository: $IMAGE_REPO"
echo "Image Tag: $IMAGE_TAG"

ステップ2 : Kubernetes マニフェストの作成

ワークロードリポジトリに新しいアプリケーション用のマニフェストを作成します。Kustomize を利用しており、ほとんどの設定は base ディレクトリに存在します。dev ディレクトリで環境ごとの設定を格納します。 なお、「環境」は、Argo CD のクラスター設定のアノテーションに設定されています。興味がある方は、Argo CD の UI からクラスターの設定を確認してみてください。

bash
cd environments/sample/tmp/workloads/ex-app
mkdir -p distribution-monitor/base
mkdir -p distribution-monitor/dev

Rollout の定義

本リファレンスアーキテクチャでは、開発者に Argo Rollouts がツールとして提供されています。ここでは、そのツールを使い、アプリケーションをブルーグリーン形式でデプロイしてみましょう。 Argo Rollouts では、Kubernetes の Deployment リソースの代わりに、Rollout リソースでデプロイを表現します。

bash
cat << 'EOF' > distribution-monitor/base/rollouts.yaml
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: distribution-monitor
spec:
  replicas: 2
  revisionHistoryLimit: 2
  selector:
    matchLabels:
      app.kubernetes.io/name: distribution-monitor
  template:
    metadata:
      labels:
        app.kubernetes.io/name: distribution-monitor
    spec:
      containers:
      - name: distribution-monitor
        image: distribution-monitor
        imagePullPolicy: Always
        ports:
        - name: http
          containerPort: 8080
          protocol: TCP
        env:
        - name: POD_ID
          valueFrom:
            fieldRef:
              fieldPath: metadata.name
        resources:
          requests:
            memory: "512Mi"
            cpu: "250m"
          limits:
            memory: "512Mi"
            cpu: "500m"
        livenessProbe:
          httpGet:
            path: /
            port: 8080
          initialDelaySeconds: 30
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /
            port: 8080
          initialDelaySeconds: 10
          periodSeconds: 5
  strategy:
    blueGreen: 
      activeService: distribution-monitor-active
      previewService: distribution-monitor-preview
      autoPromotionEnabled: false
EOF

strategy.blueGreen でブルーグリーンをデプロイ戦略として設定しています。

また、autoPromotionEnabled: false となっており、デプロイ後、手動でプロモーション作業を実施するまで、本番環境に新バージョンが移行しないように制御されています。

これらの設定は、本アーキテクチャでは開発チームが自由に設定できるようになっています。
 

Service の定義

Active 環境と Preview 環境用の Service を作成します。

bash
cat << 'EOF' > distribution-monitor/base/service.yaml
apiVersion: v1
kind: Service
metadata:
  name: distribution-monitor-active
  labels:
    app.kubernetes.io/name: distribution-monitor
spec:
  ports:
    - port: 80
      targetPort: http
      protocol: TCP
      name: http
  selector:
    app.kubernetes.io/name: distribution-monitor

---
apiVersion: v1
kind: Service
metadata:
  name: distribution-monitor-preview
  labels:
    app.kubernetes.io/name: distribution-monitor
spec:
  ports:
    - port: 80
      targetPort: http
      protocol: TCP
      name: http
  selector:
    app.kubernetes.io/name: distribution-monitor
EOF

Ingress の定義

ALB で外部公開するための Ingress を作成します。

bash
cat << 'EOF' > distribution-monitor/base/ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: distribution-monitor-active
spec:
  rules:
    - http:
        paths:
          - path: /*
            pathType: ImplementationSpecific
            backend:
              service:
                name: distribution-monitor-active
                port:
                  name: http

---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: distribution-monitor-preview
spec:
  rules:
    - http:
        paths:
          - path: /*
            pathType: ImplementationSpecific
            backend:
              service:
                name: distribution-monitor-preview
                port:
                  name: http
EOF

ここでは、Ingress を指定するだけで、ALB が払い出されて、Pod が公開されます。これは、Auto Mode により実施されており、開発者は ALB の操作を行うことなく、Pod にロードバランサーを設定できるようになっています。

Kustomize の設定

Kustomize でイメージタグを管理します。

Git にプッシュ

マニフェストを Git にプッシュすると、Argo CD が自動的にデプロイします。

bash
cd $PROJECT_DIR/
git add . 
git commit -m "Add distribution-monitor application" 
git push

デプロイの確認

Argo CD UI で以下を確認します。

  1. 数秒 ~ 数分後、workloads-ex-app-distribution-monitor-dev Application が自動生成される
  2. Application が Synced 状態になる
  3. すべてのリソースが Healthy になる

アプリケーションへのアクセス

bash
# Active 環境の URL を取得
kubectl get ingress -n ex-app distribution-monitor-active \
  -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'

ブラウザで URL にアクセスすると、Distribution Monitor の画面が表示されます。ページをリフレッシュするたびに、どの Pod が応答したかが記録され、負荷分散の状況が可視化されます。

Blue/Green デプロイメントを体験しよう

次に、アプリケーションを更新して、Blue/Green デプロイメントの動作を確認してみましょう。

新しいバージョンのデプロイ

アプリケーションコードを変更して、新しいイメージをビルドします。

bash
cd apps/distribution-monitor

# コードを変更(例: src/main/resources/templates/index.html の背景色を変更)
# ここでは例として、背景色を変更したとします

# 新しいイメージをビルド・プッシュ
make build
make push

# 新しいイメージタグを取得
export IMAGE_TAG=$(make image-tag)
echo "New Image Tag: $IMAGE_TAG"

マニフェストの更新

Kustomize の設定を更新して、新しいイメージタグを指定します。

bash
cd environments/sample/tmp/workloads/ex-app/distribution-monitor/base

# kustomization.yaml の newTag を更新
sed -i.bak "s/newTag: .*/newTag: ${IMAGE_TAG}/" kustomization.yaml

# 変更を確認
cat kustomization.yaml

# Git にプッシュ
cd $PROJECT_DIR/
git add .
git commit -m "Update distribution-monitor to ${IMAGE_TAG}"
git push

Rollout の状態確認

Argo CD が変更を検出し、新しいバージョンを Preview 環境にデプロイします。

bash
# Rollout の状態を確認
kubectl argo rollouts get rollout distribution-monitor -n ex-app

ポイント : 新しいバージョン (revision:2) が Preview 環境にデプロイされ、古いバージョン(revision:1)は Active 環境で稼働し続けています。

Preview 環境での確認

Preview 環境の URL にアクセスして、新しいバージョンを確認します。

bash
# Preview 環境の URL を取得
kubectl get ingress -n ex-app distribution-monitor-preview \
  -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'

ブラウザで URL にアクセスして、変更内容(背景色など)が反映されていることを確認します。

本番環境への Promotion

新しいバージョンに問題がなければ、手動で Promotion を実行して Active 環境に切り替えます。

bash
kubectl argo rollouts promote distribution-monitor -n ex-app

Rollback が必要な場合

もし新しいバージョンに問題があった場合は、簡単に Rollback できます。

bash
kubectl argo rollouts undo distribution-monitor -n ex-app

これで、Blue/Green デプロイメントの一連の流れを体験できました!

このリファレンスアーキテクチャでは、新しいバージョンを Preview 環境で確認してから、安全に本番環境 (Active) に切り替えることができる機能が開発者に提供されている、と言えます。

ACK で AWS リソースを管理してみよう

最後に、ACK (AWS Controllers for Kubernetes) を使って、Kubernetes から AWS リソースを管理する方法を体験しましょう。

ACK とは

Kubernetes でプラットフォームを構築する際、Kubernetes 外のリソースを開発者にどのように利用させるかが課題になります。GitOps を導入して開発者が自律的にコンテナをデプロイできるようになったとしても、アプリケーションが必要とする RDS や DynamoDB のテーブル、SQS のキューなどの AWS リソースは、開発チームがチケットを発行してプラットフォームチームに作成を申請する、というケースも少なくありません。

ACK は、OSS で開発されている Kubernetes コントローラーです。Kubernetes のマニフェストで AWS リソースを管理できるため、RDS や DynamoDB を表す Kubernetes のマニフェストをクラスターに適用すると、コントローラーにより実際の対応する AWS リソースが作成・管理されます。これにより、アプリケーションと、アプリケーションが必要とする AWS リソースをどちらも Kubernetes で統一的に取り扱うことができます。

開発者は、Helm や Kustomize で、アプリケーションの設定と同時に AWS リソースを表すマニフェストを同梱することで、AWS リソースもセルフサービスで管理できるようになります。

このリファレンスアーキテクチャでは、運用負荷の観点から、EKS Capabilities を通じて ACK をフルマネージドで利用します。Argo CD と同様に、インストールや運用を AWS が管理するため、プラットフォームチームの運用負荷が軽減されます。


 

ACK における責任分担

リファレンスアーキテクチャでは、AWS リソース管理において、プラットフォームチームと開発チームの責任分担を以下のようにしています。

まず、プラットフォームチームは、IAM Role Selector を使用して、Namespace ごとに異なる IAM ロールを割り当てます。IAM Role Selector は、ACK が提供する機能で、Namespace に応じて自動的に適切な IAM ロールを選択し、AWS リソースへのアクセスを制御します。

具体的には、プラットフォームチームが各 Namespace に対してどの AWS サービスにアクセスできるかを IAM ロールとして設計し、IAM Role Selector により Namespace とマッピングします。その Namespace 内で ACK のマニフェストを適用すると、自動的にマッピングされた IAM ロールが利用されます。

一方、開発チームは、プラットフォームチームが設定した権限の範囲内で、Kubernetes マニフェストを使って必要な AWS リソースを作成・管理します。AWS コンソールや AWS CLI を使う必要はなく、アプリケーションのデプロイと同じ方法で AWS リソースを扱えます。

この分離により、プラットフォームチームはセキュリティとガバナンスを維持しながら、開発チームに自律性を提供できます。

それでは、実際に体験してみましょう。


 

パート 1 : プラットフォームチームの作業 - IAM 権限の設定

まず、プラットフォームチームの立場で、開発者が使用できる AWS リソースの権限を確認します。 terraform の実行により、すでに IAM 関連のリソースは作成されています。当該設定を行なっている environments/sample/namespace_ex_app.tf ファイルを見てみましょう。

bash
module "ack_iam_role_selector_ex_app_s3" {
  source = "$PROJECT_DIR/modules/ack_iam_role_selector"

  resource_prefix          = var.resource_prefix
  environment              = "dev"
  selector_name            = "ex-app-s3"
  namespace                = "ex-app"
  ack_controller_role_arn  = module.cluster_development.ack_capability_role_arn
  namespace_selector_names = ["ex-app"]

  # S3 バケットの作成・管理権限
  iam_policy_statements = [
    {
      effect = "Allow"
      actions = [
        "s3:CreateBucket",
        "s3:DeleteBucket",
        "s3:GetBucket*",
        "s3:PutBucket*",
        "s3:ListBucket"
      ]
      resources = [
        "arn:aws:s3:::ex-idp-dev-ex-app-*"
      ]
    },
    {
      effect = "Allow"
      actions = [
        "s3:ListAllMyBuckets"
      ]
      resources = ["*"]
    }
  ]
}

terraform のモジュールが呼び出されていますが、上記により作成されるリソースは以下のとおりです。

  1. ex-idp-dev-ex-app-s3-role という IAM ロール (S3 権限を設定)
  2. Kubernetes の IAMRoleSelector CRD (ロールと Namespace の関連付け)
    詳細については、同リポジトリの ack_iam_role_selector モジュールを参照してください。

プラットフォームチームの視点
この設定により、以下のセキュリティ制御を実現しています。

  1. Namespace スコープ : ex-app Namespace でのみ有効な権限
  2. リソース制限 : ex-idp-dev-ex-app-* パターンにマッチするバケットのみ作成可能
  3. 最小権限 : 必要な S3 操作のみを許可

開発チームは、この範囲内で自由に S3 バケットを作成・管理できます。範囲外の操作(例: 他のチームのバケットへのアクセス)は自動的に拒否されます。
 

パート 2 : 開発チームの作業 - S3 バケットの作成

次に、開発者の立場で S3 バケットを作成してみましょう。 開発者は、プラットフォームチームが設定した IAM 権限の詳細を知る必要はありません。Kubernetes のマニフェストを作成するだけで、AWS リソースを利用できます。 s3-bucket.yaml ファイルを作成します。

bash
apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
metadata:
  name: my-app-data
  namespace: ex-app
spec:
  name: ex-idp-dev-ex-app-my-app-data

マニフェストを適用

マニフェストを適用します。

bash
kubectl apply -f s3-bucket.yaml

バケットの状態を確認

バケットの状態を確認します。

bash
# Kubernetes リソースの状態
kubectl get bucket -n ex-app my-app-data

# AWS での確認
aws s3 ls | grep ex-idp-dev-ex-app-my-app-data

出力例

bash
NAME SYNCED AGE
my-app-data True 30s

2026-03-05 10:30:00 ex-idp-dev-ex-app-my-app-data

開発チームの視点  : AWS コンソールや AWS CLI を使わずに、Kubernetes のマニフェストだけで S3 バケットを作成できました。プラットフォームチームが設定した権限の範囲内で、セルフサービスで AWS リソースを利用できます。

なお、ここではハンズオンの目的で kubectl で Bucket マニフェストを適用しましたが、実際の運用では ワークロードリポジトリに Push することで、同様に Bucket を作成できます。

ポイント : ACK が自動的に以下を実行しています: 1. ex-app Namespace 用の IAM ロールを assume 2. AWS に S3 バケットを作成 3. Kubernetes リソースのステータスを更新
 

権限の境界を確認してみよう

プラットフォームチームが設定した権限の範囲外の操作を試してみましょう。

bash
# 命名規則に違反するバケット名で作成を試みる
cat << EOF | kubectl apply -f -
apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
metadata:
  name: invalid-bucket
  namespace: ex-app
spec:
  name: my-invalid-bucket-name
EOF

確認結果

このバケットは作成に失敗します。なぜなら、バケット名が ex-idp-dev-ex-app-* パターンにマッチしないためです。

bash
# エラーを確認
kubectl describe bucket -n ex-app invalid-bucket

このように、プラットフォームチームが設定した権限により、開発チームは安全な範囲内でのみリソースを作成できます。

リソースの削除

不要になったら、Kubernetes のマニフェストを削除するだけで、AWS リソースも自動的に削除されます。

bash
kubectl delete bucket -n ex-app my-app-data

サポートされている AWS サービス

ACK は以下を含む多くの AWS サービスをサポートしています。

  • Amazon S3 (Simple Storage Service)
  • Amazon DynamoDB
  • Amazon RDS (Relational Database Service)
  • Amazon ElastiCache
  • Amazon SNS / Amazon SQS
  • その他多数

完全なリストは ACK Service Controllers を参照してください。

ACK による責任共有モデルのまとめ

ACK を使うことで、以下のような明確な責任分担が実現できました。

  • プラットフォームチームが実施したこと : Terraform で IAM ロールと IAM Role Selector を作成 - 最小権限の原則に基づいた権限設計 - リソース命名規則の強制
  • 開発チームが実施したこと : Kubernetes マニフェストで S3 バケットを作成 - IAM の詳細を意識せずにリソースを利用
  • 結果 : 開発チームは AWS コンソールや AWS CLI を使わずに、必要なリソースをセルフサービスで利用できる - プラットフォームチームはセキュリティとガバナンスを維持しながら、開発チームに自律性を提供できる

これで、ACK を使った AWS リソース管理の一連の流れを体験できました!

クリーンアップ

ハンズオンを終えたら、以下のコマンドでリソースを削除できます。

bash
cd environments/sample
terraform destroy

注意 : ACK で作成した AWS リソースは、事前に削除しておく必要があります。

まとめ

本記事では、Amazon EKS を活用した Platform Engineering のリファレンス実装を紹介しました。実際に手を動かしながら、以下の技術やコンセプトを体験しました。

  1. Argo CD : EKS Capabilities を通じてフルマネージドで利用することで、GitOps の運用コストを削減
  2. ACK : EKS Capabilities を通じてフルマネージドで利用することで、開発者のセルフサービスを実現
  3. Argo Rollouts : Blue/Green デプロイメントによる安全なリリース戦略
  4. Multi-tenancy : Namespace ベースの分離により、複数チームが安全に共存

プラットフォームの効果

プラットフォームを構築することで、以下のような効果が期待できます。

開発者にとって

  • Git にプッシュするだけで自動デプロイ
  • Preview 環境で安全に新バージョンを確認
  • AWS リソースを、アプリケーションと同じ方式で管理でき、かつセルフサービスで利用可能
  • インフラの詳細を意識せずにアプリケーション開発に集中
     

プラットフォームチームにとって

  • 標準化された環境を一元管理
  • セキュリティとガバナンスを維持しながら開発者に自律性を提供
  • AWS がマネージドサービスを提供することで運用負担を削減
  • Infrastructure as Code による再現性の高い環境構築
     

次のステップ

このリファレンス実装をベースに、以下のような拡張が可能です。

  • 複数環境の管理 : dev、staging、production 環境の構築
  • カスタムアドオンの追加 : Istio などのサービスメッシュやセキュリティエージェントなど
  • より高度なデプロイ戦略 : Canary デプロイメント、A/B テスト
  • 他の AWS サービスとの統合 : RDS、DynamoDB、ElastiCache など

本記事が、プラットフォームエンジニアリングや GitOps の理解を深める一助となれば幸いです。実際に手を動かすことで、モダンな開発プラットフォームの構築方法を体感できたのではないでしょうか。

ぜひ、このリファレンス実装をベースに、あなたのチームに最適なプラットフォームを構築してみてください!

筆者プロフィール

林 政利 (@literalice)
アマゾン ウェブ サービス ジャパン合同会社
コンテナスペシャリスト ソリューションアーキテクト

フリーランスや Web 系企業で業務システムや Web サービスの開発、インフラ運用に従事。近年はベンダーでコンテナ技術の普及に努めており、現在、AWS Japan で Amazon ECS や Amazon EKS でのコンテナ運用や開発プロセス構築を中心にソリューションアーキテクトとして活動中。

A person smiling outdoors in a park-like setting with colorful trees in the background, wearing a jacket. Photo taken in 2023.