AWS Proton v2.0 完全ガイド 2026

初心者から実務者向けの包括的解説

AWS Proton は、プラットフォームエンジニアリングチームが開発者向けに IaC テンプレートをゴールデンパスとして提供し、セルフサービスでインフラをプロビジョニングできる Internal Developer Platform（IDP）サービスです。CloudFormation / Terraform テンプレートを「環境テンプレート（共有インフラ）+ サービステンプレート（アプリデプロイ）」の 2 層で抽象化し、開発チームがパラメータ入力だけでインフラを自動展開。Platform Engineering / ガバナンス・セキュリティ・コスト管理を両立させます。

重要注記：AWS Proton は 2025-12-31 に End-of-Support となります。 代替として AWS CDK・Service Catalog・Terraform Cloud への移行が推奨されます。本ドキュメントは、現在の運用対応と移行計画を両立する完全ガイドです。

ドキュメントの目的

本ガイドは以下を対象としています：

初心者向け： Proton とは何か、IDP の概念を学びたい方
プラットフォームエンジニア向け： テンプレート設計・バージョン管理・段階的更新
開発者向け： Proton でのサービスプロビジョニング・CI/CD 統合
意思決定者向け： End-of-Support 対応・CDK/Terraform Cloud への移行戦略

2026 年の Proton エコシステム

End-of-Support が 2025 年 12 月末
段階的な AWS CDK への移行推奨
Terraform Cloud・Spacelift 連携強化
Service Catalog との統合深化
Backstage IDP プラグイン活用

概要
Proton が解決する課題
主な特徴
アーキテクチャ
Environment Template（環境テンプレート）
Service Template（サービステンプレート）
Component（コンポーネント）
CI/CD Pipeline 統合
Terraform 対応
主要ユースケース
テンプレート設計のベストプラクティス
バージョン管理・段階的更新
設定・操作の具体例
ECS / Lambda / Kubernetes
Backstage IDP 統合
セキュリティ・監査
トラブルシューティング
End-of-Support への移行計画
AWS CDK への移行
Terraform Cloud・Spacelift
類似サービス比較
ベストプラクティス
2025-2026 最新動向
学習リソース
実装例・チェックリスト
まとめ

概要

初心者向けメモ： Proton は「プラットフォームチームが開発チームに IaC テンプレートを提供し、開発者がクリックだけでインフラをセルフサービス展開できるサービス」です。従来、インフラ構築には CloudFormation / Terraform の深い知識が必要でしたが、Proton なら開発者は「環境タイプ」「サービスタイプ」を選んでパラメータを入力するだけ。バックエンドでプラットフォームチームが管理する安全で標準化されたテンプレートが自動展開されます。

AWS Proton は以下を実現する Internal Developer Platform（IDP）です：

機能	説明
Environment Template	共有インフラ（VPC・ECS クラスター・RDS）テンプレート
Service Template	アプリケーション展開方法（ECS・Lambda・Kubernetes）テンプレート
CI/CD Pipelines	CodePipeline による自動デプロイ
Terraform Support	CloudFormation + Terraform の両対応
Component	再利用可能な基本コンポーネント
Version Management	メジャー・マイナー版で段階的更新
Self-Service	開発者がセルフサービスでプロビジョニング

Proton が解決する課題

1. インフラ知識とセルフサービスの両立

課題：

従来のアプローチ:

① 完全セルフサービス（開発者が CloudFormation 操作）
   メリット: 開発速度が速い
   デメリット: セキュリティ脆弱性・コスト超過・不整合

② 完全管理（インフラチームが構築・運用）
   メリット: セキュリティ・コスト管理が確実
   デメリット: 開発速度が遅い（構築リクエスト → インフラチーム → 構築 に時間）

Proton の解決：

ゴールデンパスアプローチ:

① プラットフォームチーム: テンプレートを設計・管理
   - セキュリティ・コスト・構成管理を組み込み
   - テンプレートをバージョン管理

② 開発チーム: セルフサービスでプロビジョニング
   - 環境タイプを選択
   - パラメータを入力
   - ワンクリック展開
   - 標準化された安全なインフラが自動構築

メリット:
  ✅ 開発速度（セルフサービス）
  ✅ セキュリティ（テンプレートで統制）
  ✅ コスト管理（テンプレートで統制）

2. テンプレート更新の一括適用の困難性

課題：

手動管理時:
  - セキュリティパッチ適用（例: VPC セキュリティグループルール更新）
  - 数十〜数百個のスタックを手動で更新
  - 更新漏れによるセキュリティ脆弱性
  - 確認・ロールバック管理が複雑

Proton の解決：

バージョン管理:
  - テンプレートを v1.0 → v1.1 → v2.0 に更新
  - 既存サービスに自動適用（段階的）
  - ロールバック機能完備

例:
  VPC セキュリティグループ更新 → テンプレート更新
  → 全サービスに自動適用（数十〜数百個一括）

3. インフラ多様性による運用負荷

課題：

テンプレートが散乱:
  チーム A: 独自 CloudFormation テンプレート
  チーム B: 独自 Terraform コード
  チーム C: AWS CDK で独自実装
  
結果:
  - 標準化がない
  - 知識が分散
  - 移行・監査が困難

Proton の解決：

統一テンプレート:
  - 組織全体で 1 つの Environment Template
  - 複数の Service Template（ECS・Lambda・Kubernetes）
  - 全チームが同じテンプレート使用
  - 一元管理・一括更新が可能

主な特徴

graph TD
    Proton["AWS Proton<br/>Internal Developer Platform"]
    
    Proton -->|Templates| EnvTemplate["Environment Template<br/>VPC / ECS Cluster / RDS"]
    Proton -->|Templates| SvcTemplate["Service Template<br/>ECS Service / Lambda / Kubernetes"]
    Proton -->|Components| Comp["Components<br/>再利用可能ユニット"]
    
    EnvTemplate -->|Provision| Env["Environment Instance<br/>prod / staging / dev"]
    SvcTemplate -->|Provision| Svc["Service Instance<br/>myapp-api / myapp-web"]
    
    Env -->|includes| Svc
    
    Svc -->|CI/CD| Pipeline["CodePipeline<br/>自動ビルド・デプロイ"]
    
    Pipeline -->|CloudFormation/Terraform| Deploy["Deployment<br/>Infrastructure"]

1. Environment Template（環境層）

役割: 共有インフラストラクチャ
  - VPC（ネットワーク）
  - ECS クラスター（コンテナオーケストレーション）
  - RDS DB インスタンス（データベース）
  - IAM ロール・ポリシー

特性:
  - 組織全体で 1 つ（複数バージョン管理）
  - バージョン管理（v1.0 → v1.1 → v2.0）
  - 段階的な更新適用
  - パラメータ化（VPC CIDR・RDS インスタンスタイプ等カスタマイズ可能）

例:
  "環境テンプレート: ECS Fargate 基盤"
  ├─ VPC（10.0.0.0/16）
  ├─ ECS クラスター（コンテナインスタンス 3 台）
  ├─ RDS MySQL（db.t3.medium）
  ├─ Application Load Balancer
  ├─ Auto Scaling Group
  └─ IAM ロール（各マイクロサービス用）

2. Service Template（アプリ層）

役割: アプリケーションデプロイ方法
  - ECS サービス定義（タスク定義・レプリカ数・ログ）
  - Lambda 関数（関数コード・トリガー）
  - Kubernetes デプロイメント・サービス

特性:
  - 複数タイプ可能（ECS 用・Lambda 用・Kubernetes 用）
  - 各 Service Template が 1 つの環境で複数インスタンス化可能
  - CI/CD パイプライン統合
  - パラメータ化

例:
  "サービステンプレート: ECS Fargate マイクロサービス"
  ├─ タスク定義（CPU: 512, メモリ: 1GB）
  ├─ 期待タスク数（3）
  ├─ ログ（CloudWatch Logs）
  ├─ オートスケーリング（メトリクス）
  ├─ ヘルスチェック
  ├─ ALB ターゲットグループ
  └─ CI/CD パイプライン（コード変更 → 自動ビルド → 自動デプロイ）

3. Infrastructure Abstraction（インフラ抽象化）

従来（直接 CloudFormation 操作）:
  開発者が 200 行以上の YAML を記述
  ├─ VPC パラメータ
  ├─ セキュリティグループ
  ├─ IAM ロール
  ├─ ECS タスク定義
  └─ ...複雑

Proton（抽象化）:
  開発者が 3-4 個のパラメータのみ入力
  ├─ アプリ名: "myapp"
  ├─ 環境: "prod"
  ├─ コンテナイメージ: "myapp:v1.0"
  └─ レプリカ数: 3
  
  背後で 200 行の CloudFormation が自動生成・実行

アーキテクチャ

Proton の 2 層テンプレートモデル

┌──────────────────────────────────────────────────────────────┐
│ Platform Team（プラットフォームチーム）                     │
└──────────────────────────────────────────────────────────────┘
                  │
     ┌────────────┼────────────┐
     │            │            │
     ▼            ▼            ▼
┌─────────────┐┌──────────────┐┌──────────┐
│Environment  ││Service       ││Component │
│Template v2.0││Template v1.5 ││ Library  │
│(VPC+ECS)    ││(ECS Service) ││          │
└─────────────┘└──────────────┘└──────────┘
     │            │            │
└────────────┬────────────┬────────────┘
             │
┌────────────▼────────────────────────────────────┐
│ Development Team（開発チーム）                  │
│                                                 │
│ 環境テンプレート: ECS Fargate v2.0 選択       │
│ サービステンプレート: ECS Microservice 選択    │
│                                                 │
│ パラメータ入力:                                │
│  - アプリ名: product-api                       │
│  - 環境: production                            │
│  - コンテナイメージ: myrepo/product-api:v2.1  │
│  - レプリカ数: 3                               │
│                                                 │
│ ワンクリック: "Create Service"                │
└────────────┬────────────────────────────────────┘
             │
   ┌─────────▼─────────┐
   │ Proton Engine     │
   │ CloudFormation    │
   │実行               │
   └─────────┬─────────┘
             │
   ┌─────────▼──────────────────────┐
   │ Infrastructure Provisioned     │
   │                                │
   │ ✅ VPC (10.0.0.0/16)          │
   │ ✅ ECS Cluster (prod)          │
   │ ✅ ECS Service (product-api)   │
   │ ✅ RDS MySQL                   │
   │ ✅ Application Load Balancer   │
   │ ✅ Auto Scaling Group          │
   │ ✅ CloudWatch Logs             │
   │ ✅ IAM Roles                   │
   └────────────────────────────────┘

Environment Instance と Service Instance の関係

環境 (Environment Instance)
  prod-environment
  ├─ VPC (10.0.0.0/16)
  ├─ ECS Cluster
  ├─ RDS MySQL
  ├─ Security Groups
  └─ IAM Roles
  
サービス 1 (Service Instance)
  product-api
  ├─ ECS Service
  ├─ Task Definition
  ├─ Load Balancer Target Group
  └─ CloudWatch Logs
  
サービス 2 (Service Instance)
  order-api
  ├─ ECS Service
  ├─ Task Definition
  ├─ Load Balancer Target Group
  └─ CloudWatch Logs
  
サービス 3 (Service Instance)
  payment-service
  ├─ Lambda Function
  ├─ API Gateway
  └─ CloudWatch Logs

1 つの環境に複数のサービスがデプロイされる
→ 環境ごとのコスト・管理を効率化

Environment Template（環境テンプレート）

テンプレート構成

environment-template/
  ├─ infrastructure/
  │  ├─ cloudformation.yaml      # 環境の CloudFormation
  │  └─ manifest.yaml            # ファイル構成定義
  ├─ schema/
  │  └─ schema.yaml              # 入力パラメータスキーマ（JSON Schema）
  └─ README.md

schema.yaml（パラメータ定義）

schema:
  format:
    openapi: "3.0.0"
  environment_input_type: "EnvironmentInput"
  types:
    EnvironmentInput:
      type: object
      description: ECS Fargate 環境の設定
      required:
        - vpc_cidr
        - availability_zones
        - container_insights
      properties:
        vpc_cidr:
          type: string
          description: VPC CIDR ブロック
          default: "10.0.0.0/16"
          pattern: "^([0-9]{1,3}\\.){3}[0-9]{1,3}/[0-9]{1,2}{{CONTENT}}quot;
        
        availability_zones:
          type: integer
          description: 使用可能ゾーン数（1-3）
          minimum: 1
          maximum: 3
          default: 2
        
        container_insights:
          type: string
          description: ECS Container Insights の有効化
          enum: [enabled, disabled]
          default: enabled
        
        rds_instance_class:
          type: string
          description: RDS インスタンスタイプ
          enum: [db.t3.micro, db.t3.small, db.t3.medium, db.t3.large]
          default: db.t3.medium
        
        high_availability:
          type: boolean
          description: マルチ AZ で HA 構成
          default: true

cloudformation.yaml（基盤テンプレート）

AWSTemplateFormatVersion: '2010-09-09'
Description: 'ECS Fargate 環境テンプレート v2.0'

Parameters:
  VpcCidr:
    Type: String
    Default: "10.0.0.0/16"
  AvailabilityZones:
    Type: Number
    Default: 2
  ContainerInsights:
    Type: String
    Default: enabled

Resources:
  # VPC
  VPC:
    Type: AWS::EC2::VPC
    Properties:
      CidrBlock: !Ref VpcCidr
      EnableDnsHostnames: true
      EnableDnsSupport: true
      Tags:
        - Key: Name
          Value: !Sub '${AWS::StackName}-vpc'

  # Subnets
  PublicSubnet1:
    Type: AWS::EC2::Subnet
    Properties:
      VpcId: !Ref VPC
      CidrBlock: !Select [0, !Cidr [!Ref VpcCidr, 4, 8]]
      AvailabilityZone: !Select [0, !GetAZs '']
      MapPublicIpOnLaunch: true

  PublicSubnet2:
    Type: AWS::EC2::Subnet
    Properties:
      VpcId: !Ref VPC
      CidrBlock: !Select [1, !Cidr [!Ref VpcCidr, 4, 8]]
      AvailabilityZone: !Select [1, !GetAZs '']
      MapPublicIpOnLaunch: true

  # Internet Gateway
  IGW:
    Type: AWS::EC2::InternetGateway
  AttachIGW:
    Type: AWS::EC2::VPCGatewayAttachment
    Properties:
      VpcId: !Ref VPC
      InternetGatewayId: !Ref IGW

  # ECS Cluster
  ECSCluster:
    Type: AWS::ECS::Cluster
    Properties:
      ClusterName: !Sub '${AWS::StackName}-cluster'
      ClusterSettings:
        - Name: containerInsights
          Value: !Ref ContainerInsights

  # RDS
  DBSubnetGroup:
    Type: AWS::RDS::DBSubnetGroup
    Properties:
      DBSubnetGroupDescription: Subnet group for RDS
      SubnetIds:
        - !Ref PublicSubnet1
        - !Ref PublicSubnet2

  RDSInstance:
    Type: AWS::RDS::DBInstance
    Properties:
      Engine: mysql
      DBInstanceClass: db.t3.medium
      AllocatedStorage: 20
      DBSubnetGroupName: !Ref DBSubnetGroup
      VPCSecurityGroups:
        - !Ref RDSSecurityGroup

  RDSSecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: RDS security group
      VpcId: !Ref VPC
      SecurityGroupIngress:
        - IpProtocol: tcp
          FromPort: 3306
          ToPort: 3306
          SourceSecurityGroupId: !Ref ECSSecurityGroup

  ECSSecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: ECS security group
      VpcId: !Ref VPC
      SecurityGroupIngress:
        - IpProtocol: tcp
          FromPort: 80
          ToPort: 80
          CidrIp: 0.0.0.0/0
        - IpProtocol: tcp
          FromPort: 443
          ToPort: 443
          CidrIp: 0.0.0.0/0

  # IAM Role
  ECSTaskExecutionRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Principal:
              Service: ecs-tasks.amazonaws.com
            Action: sts:AssumeRole
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy

Outputs:
  VpcId:
    Value: !Ref VPC
  ECSClusterName:
    Value: !Ref ECSCluster
  RDSEndpoint:
    Value: !GetAtt RDSInstance.Endpoint.Address

Service Template（サービステンプレート）

サービステンプレート構成

service-template/
  ├─ instance_infrastructure/
  │  ├─ cloudformation.yaml      # サービスインスタンス用 CF
  │  └─ manifest.yaml
  ├─ pipeline_infrastructure/
  │  ├─ cloudformation.yaml      # CI/CD パイプライン用 CF
  │  └─ manifest.yaml
  ├─ schema/
  │  └─ schema.yaml              # パラメータスキーマ
  └─ README.md

instance_infrastructure/cloudformation.yaml

AWSTemplateFormatVersion: '2010-09-09'
Description: 'ECS マイクロサービスサービステンプレート'

Parameters:
  ServiceName:
    Type: String
    Description: サービス名（例: product-api）
  ContainerImage:
    Type: String
    Description: コンテナイメージ URI
  DesiredCount:
    Type: Number
    Default: 3
    Description: タスク数
  ContainerPort:
    Type: Number
    Default: 8080
    Description: コンテナポート

Resources:
  # ECS Service
  ECSService:
    Type: AWS::ECS::Service
    Properties:
      ServiceName: !Ref ServiceName
      Cluster: !Sub '{{environment.cluster_name}}'
      TaskDefinition: !Ref TaskDefinition
      DesiredCount: !Ref DesiredCount
      LaunchType: FARGATE
      NetworkConfiguration:
        AwsvpcConfiguration:
          AssignPublicIp: ENABLED
          Subnets:
            - !Sub '{{environment.subnet_id_1}}'
            - !Sub '{{environment.subnet_id_2}}'
          SecurityGroups:
            - !Sub '{{environment.security_group_id}}'
      LoadBalancers:
        - ContainerName: !Ref ServiceName
          ContainerPort: !Ref ContainerPort
          TargetGroupArn: !Ref ALBTargetGroup

  # Task Definition
  TaskDefinition:
    Type: AWS::ECS::TaskDefinition
    Properties:
      Family: !Ref ServiceName
      NetworkMode: awsvpc
      RequiresCompatibilities:
        - FARGATE
      Cpu: '512'
      Memory: '1024'
      ExecutionRoleArn: !Sub '{{environment.execution_role_arn}}'
      ContainerDefinitions:
        - Name: !Ref ServiceName
          Image: !Ref ContainerImage
          PortMappings:
            - ContainerPort: !Ref ContainerPort
          LogConfiguration:
            LogDriver: awslogs
            Options:
              awslogs-group: !Ref LogGroup
              awslogs-region: !Ref 'AWS::Region'
              awslogs-stream-prefix: ecs

  # CloudWatch Logs
  LogGroup:
    Type: AWS::Logs::LogGroup
    Properties:
      LogGroupName: !Sub '/ecs/${ServiceName}'
      RetentionInDays: 7

  # ALB Target Group
  ALBTargetGroup:
    Type: AWS::ElasticLoadBalancingV2::TargetGroup
    Properties:
      Name: !Sub '${ServiceName}-tg'
      Port: !Ref ContainerPort
      Protocol: HTTP
      TargetType: ip
      VpcId: !Sub '{{environment.vpc_id}}'
      HealthCheckPath: /health
      HealthCheckProtocol: HTTP
      HealthCheckIntervalSeconds: 30
      HealthCheckTimeoutSeconds: 5
      HealthyThresholdCount: 2
      UnhealthyThresholdCount: 3

Outputs:
  ServiceArn:
    Value: !GetAtt ECSService.ServiceArn
  TaskDefinitionArn:
    Value: !Ref TaskDefinition

Component（コンポーネント）

コンポーネント = 再利用可能なユニット

例: RDS コンポーネント

RDS を複数のサービステンプレートで再利用したい場合:

従来:
  ├─ Service Template A で RDS を定義
  ├─ Service Template B で RDS を定義
  ├─ Service Template C で RDS を定義
  
  問題: 重複・更新管理が困難

Proton Component:
  ├─ Component: "rds-mysql" を作成
  └─ Service Template A・B・C で参照
  
  メリット:
    ✅ 定義を 1 箇所に集約
    ✅ 更新すると全テンプレートに反映
    ✅ バージョン管理可能

使用例:
  Service Template が Component を参照:
  
  aws proton create-component \
    --name "rds-mysql-v1" \
    --infrastructure '{
      "TemplateUrl": "s3://my-bucket/rds-mysql.yaml"
    }'

CI/CD Pipeline 統合

pipeline_infrastructure での CI/CD 設定

# pipeline_infrastructure/cloudformation.yaml
# CodePipeline・CodeBuild の自動構築

Resources:
  # CodeRepository Connection（GitHub・CodeCommit）
  CodeStarConnection:
    Type: AWS::CodeStarConnections::Connection
    Properties:
      ProviderType: GitHub
      ConnectionName: my-app-repo-connection

  # CodeBuild Project
  CodeBuildProject:
    Type: AWS::CodeBuild::Project
    Properties:
      Name: !Sub '${ServiceName}-build'
      ServiceRole: !GetAtt CodeBuildRole.Arn
      Artifacts:
        Type: CODEPIPELINE
      Environment:
        ComputeType: BUILD_GENERAL1_SMALL
        Image: aws/codebuild/standard:5.0
        Type: LINUX_CONTAINER
        PrivilegedMode: true
        EnvironmentVariables:
          - Name: AWS_ACCOUNT_ID
            Value: !Ref 'AWS::AccountId'
          - Name: AWS_DEFAULT_REGION
            Value: !Ref 'AWS::Region'
          - Name: IMAGE_REPO_NAME
            Value: !Ref ServiceName
          - Name: IMAGE_TAG
            Value: latest
      Source:
        Type: CODEPIPELINE
        BuildSpec: buildspec.yml

  # CodePipeline
  Pipeline:
    Type: AWS::CodePipeline::Pipeline
    Properties:
      Name: !Sub '${ServiceName}-pipeline'
      RoleArn: !GetAtt CodePipelineRole.Arn
      ArtifactStore:
        Type: S3
        Location: !Ref ArtifactBucket
      Stages:
        - Name: Source
          Actions:
            - Name: SourceAction
              ActionTypeId:
                Category: Source
                Owner: AWS
                Provider: CodeStarSourceConnection
                Version: '1'
              Configuration:
                FullRepositoryId: my-org/my-app
                BranchName: main
                ConnectionArn: !Ref CodeStarConnection
              OutputArtifacts:
                - Name: SourceOutput

        - Name: Build
          Actions:
            - Name: BuildAction
              ActionTypeId:
                Category: Build
                Owner: AWS
                Provider: CodeBuild
                Version: '1'
              Configuration:
                ProjectName: !Ref CodeBuildProject
              InputArtifacts:
                - Name: SourceOutput
              OutputArtifacts:
                - Name: BuildOutput

        - Name: Deploy
          Actions:
            - Name: DeployAction
              ActionTypeId:
                Category: Deploy
                Owner: AWS
                Provider: ECS
                Version: '1'
              Configuration:
                ClusterName: !Sub '{{environment.cluster_name}}'
                ServiceName: !Ref ServiceName
                FileName: imagedefinitions.json
              InputArtifacts:
                - Name: BuildOutput

Terraform 対応

Terraform によるプロビジョニング

Terraform テンプレート構成:

environment-template/
  ├─ terraform/
  │  ├─ main.tf          # 環境定義
  │  ├─ variables.tf     # 入力変数
  │  ├─ outputs.tf       # 出力値
  │  └─ terraform.tfvars # デフォルト値
  └─ schema.yaml         # Proton パラメータスキーマ

service-template/
  ├─ terraform/
  │  ├─ main.tf          # サービス定義
  │  ├─ variables.tf
  │  └─ outputs.tf
  └─ schema.yaml

実行フロー:

1. Proton が環境テンプレートを Git リポジトリに PR として作成
2. プラットフォームエンジニアが確認・マージ
3. Terraform Cloud / GitHub Actions が terraform apply 実行
4. Proton がステータスを監視

メリット:
  - Terraform の完全な柔軟性
  - Version control による audit trail
  - 回復力の強い plan-apply フロー

主要ユースケース

1. マイクロサービス・プラットフォーム

プラットフォームチーム:
  ├─ Environment Template: ECS Fargate 環境（VPC・RDS・ALB）
  ├─ Service Template: マイクロサービス（API・Worker・Frontend）
  └─ バージョン管理: v1.0 → v2.0 での一括更新

開発チーム（各チーム 5-10 名）:
  ├─ Team A（Product API）: サービスインスタンス作成・運用
  ├─ Team B（Order API）: サービスインスタンス作成・運用
  └─ Team C（Payment Service）: サービスインスタンス作成・運用

メリット:
  ✅ 開発チームは Terraform・CloudFormation 不要
  ✅ 標準化された環境
  ✅ セキュリティ・コスト管理を一元化

2. 複数環境管理（dev・staging・prod）

Environment Instances:
  ├─ dev-environment（小規模、コスト最適化）
  ├─ staging-environment（本番類似）
  └─ prod-environment（HA・監視強化）

各環境に複数のサービスをデプロイ:
  dev-environment
    ├─ product-api
    ├─ order-api
    └─ payment-service

  staging-environment
    ├─ product-api
    ├─ order-api
    └─ payment-service

  prod-environment
    ├─ product-api
    ├─ order-api
    └─ payment-service

管理効率:
  - テンプレートの更新 → 全環境に自動適用
  - リソースライフサイクル管理（作成・更新・削除）一元化

3. セルフサービスポータル + Backstage

Backstage（Spotify IDP）+ Proton 統合:

  Backstage Portal
    ↓
  "Create Service" ボタン
    ↓
  Service Template 選択
    ↓
  パラメータ入力
    ↓
  Proton API で自動実行
    ↓
  ECS Service 自動展開
    ↓
  Dashboard に登録・表示

メリット:
  - 開発者ポータルが統一
  - ワークフロー自動化
  - セルフサービス文化促進

テンプレート設計のベストプラクティス

✅ Environment Template 設計

推奨:
  1. 部門別・環境別でテンプレートを分離
     - テンプレート: web-app-environment・api-environment・data-pipeline-environment
     
  2. パラメータ化で柔軟性を確保
     - VPC CIDR・AZ・インスタンスタイプ等をパラメータ化
     
  3. セキュリティ・コスト管理をテンプレートに組み込み
     - VPC Endpoint
     - 最小権限 IAM ロール
     - CloudTrail ロギング
     - 予算アラート

  4. バージョン管理で段階的な更新
     - v1.0 → v1.1（バグ修正）
     - v1.1 → v2.0（大型更新）
     - 既存環境は互換性保つ

✅ Service Template 設計

推奨:
  1. 1 つのテンプレート = 1 つのデプロイ方法
     - ECS Fargate マイクロサービス
     - Lambda + API Gateway
     - Kubernetes Deployment
     
     複数を無理に 1 テンプレートに詰め込まない

  2. CI/CD パイプラインを自動化
     - GitHub → CodeBuild（ビルド）→ CodeDeploy（デプロイ）
     - ブランチマージで自動デプロイ

  3. ロギング・監視を組み込み
     - CloudWatch Logs
     - CloudWatch Alarms
     - X-Ray（トレーシング）

  4. スケーラビリティを考慮
     - Auto Scaling Group
     - Horizontal Pod Autoscaler（Kubernetes）

バージョン管理・段階的更新

テンプレートバージョンニング

# 環境テンプレート v1.0 の作成・発行
aws proton create-environment-template-version \
  --template-name ecs-fargate-environment \
  --source 's3://my-bucket/env-template-v1.0.tar.gz' \
  --major-version 1 \
  --minor-version 0

# v1.0 を PUBLISHED（公開）
aws proton update-environment-template-version \
  --template-name ecs-fargate-environment \
  --major-version 1 \
  --minor-version 0 \
  --status PUBLISHED

# v1.1 の作成（バグ修正）
aws proton create-environment-template-version \
  --template-name ecs-fargate-environment \
  --source 's3://my-bucket/env-template-v1.1.tar.gz' \
  --major-version 1 \
  --minor-version 1

# v1.1 を PUBLISHED
aws proton update-environment-template-version \
  --template-name ecs-fargate-environment \
  --major-version 1 \
  --minor-version 1 \
  --status PUBLISHED

段階的な更新適用

既存環境を v1.0 → v1.1 に更新:

戦略1: 段階的更新（Blue-Green）
  ① 新しい環境を v1.1 で作成
  ② テスト実施
  ③ トラフィック切り替え
  ④ 旧環境削除

戦略2: In-place 更新（ローリング）
  ① v1.1 をマイナーバージョン更新
  ② Proton が既存環境に適用
  ③ リソース更新（順次・一括選択可）

推奨: v1.0 → v1.1（マイナー更新）は In-place
     v1.0 → v2.0（メジャー更新）は Blue-Green

設定・操作の具体例

AWS CLI での実装

# 例1: Environment Template を作成
aws proton create-environment-template \
  --name ecs-fargate-environment \
  --display-name "ECS Fargate Environment" \
  --description "Production-ready ECS Fargate environment"

# 例2: Environment Template Version を作成
aws proton create-environment-template-version \
  --template-name ecs-fargate-environment \
  --source 's3://my-proton-templates/env-v1.0.tar.gz' \
  --major-version 1 \
  --minor-version 0

# 例3: Version を PUBLISHED（公開）
aws proton update-environment-template-version \
  --template-name ecs-fargate-environment \
  --major-version 1 \
  --minor-version 0 \
  --status PUBLISHED

# 例4: Service Template を作成
aws proton create-service-template \
  --name ecs-microservice \
  --display-name "ECS Microservice" \
  --description "ECS Fargate microservice template"

# 例5: Service Template Version を作成
aws proton create-service-template-version \
  --template-name ecs-microservice \
  --source 's3://my-proton-templates/svc-v1.0.tar.gz' \
  --major-version 1 \
  --minor-version 0

# 例6: Version を PUBLISHED
aws proton update-service-template-version \
  --template-name ecs-microservice \
  --major-version 1 \
  --minor-version 0 \
  --status PUBLISHED

# 例7: Environment Instance を作成
aws proton create-environment \
  --name production \
  --template-name ecs-fargate-environment \
  --template-major-version 1 \
  --template-minor-version 0 \
  --spec '{
    "proton": "EnvironmentSpec",
    "spec": {
      "vpc_cidr": "10.0.0.0/16",
      "availability_zones": 2,
      "container_insights": "enabled"
    }
  }'

# 例8: Service Instance を作成
aws proton create-service \
  --name product-api \
  --template-name ecs-microservice \
  --template-major-version 1 \
  --template-minor-version 0 \
  --spec '{
    "proton": "ServiceSpec",
    "pipeline": {
      "unit_test_command": "npm test",
      "image_tag": "latest"
    },
    "instances": [
      {
        "name": "prod-instance",
        "environment": "production",
        "spec": {
          "container_image": "123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/product-api:v1.0",
          "desired_count": 3
        }
      }
    ]
  }' \
  --repository-connection-arn arn:aws:codestar-connections:ap-northeast-1:123456789012:connection/my-github-connection \
  --repository-id "my-org/product-api" \
  --branch-name main

CloudFormation / Terraform

# CloudFormation での Proton テンプレート定義

AWSTemplateFormatVersion: '2010-09-09'
Description: 'Proton Service via CloudFormation'

Resources:
  ProductAPIService:
    Type: AWS::Proton::Service
    Properties:
      Name: product-api
      TemplateName: ecs-microservice
      TemplateMajorVersion: 1
      TemplateMinorVersion: 0
      Spec: |
        {
          "proton": "ServiceSpec",
          "pipeline": {
            "unit_test_command": "npm test"
          },
          "instances": [
            {
              "name": "prod",
              "environment": "production",
              "spec": {
                "container_image": "myrepo/product-api:v1.0",
                "desired_count": 3
              }
            }
          ]
        }

ECS / Lambda / Kubernetes

複数のサービステンプレート

Service Template 複数タイプ:

1. ECS Fargate テンプレート
   - 対象: コンテナマイクロサービス
   - 例: API・Worker・Frontend

2. Lambda テンプレート
   - 対象: サーバーレス関数
   - 例: イベント処理・バッチジョブ

3. Kubernetes テンプレート
   - 対象: EKS クラスタ内のアプリケーション
   - 例: マイクロサービス（高度なロードバランシング）

選択例:
  Product API → ECS Fargate テンプレート
  ↓
  Async Job → Lambda テンプレート
  ↓
  Analytics Service → Kubernetes テンプレート

Backstage IDP 統合

Backstage + Proton で統一ポータル

Backstage Software Catalog:
  ├─ Teams
  ├─ Components（マイクロサービス）
  ├─ APIs
  ├─ Plugins
  └─ Templates（IDP）

Proton Integration:
  Template（Backstage）
    ↓
    Service Template リスト
    ↓
    パラメータ入力フォーム
    ↓
    Proton API 呼び出し
    ↓
    Infrastructure Provisioning
    ↓
    Service Catalog 登録

メリット:
  - 統一ポータル
  - ワークフロー自動化
  - Platform Engineering 文化

セキュリティ・監査

IAM・CloudTrail・VPC

セキュリティレイヤー:

1. IAM ロール・ポリシー
   - テンプレートに最小権限を組み込み
   - Service Instance ごとに異なる IAM ロール

2. CloudTrail ロギング
   - Proton 操作の完全監査
   - AWS::Proton::* イベントを記録

3. VPC セキュリティ
   - テンプレートで VPC Endpoint 設定
   - Security Group ルールを厳格に

4. リソースタグ付け
   - Cost Center・Environment・Owner
   - CloudTrail クエリで環境別の操作追跡

トラブルシューティング

問題	原因	解決策
Service Creation Failed	テンプレート syntax エラー	CloudFormation validate-template で検証
Deployment timeout	IAM 権限不足	Proton の Service Role 権限確認
Pipeline fails	Repository 接続エラー	CodeStar Connections を再認可
Version update fails	既存環境との互換性なし	新規 Environment で検証後、段階的に適用

End-of-Support への移行計画

⚠️ 2025-12-31 Proton End-of-Support

現在の状況:
  AWS Proton は 2025 年 12 月 31 日で End-of-Support

対応:
  ① 既存 Proton リソースは継続利用可能（サポート終了後も）
  ② 新規テンプレート・インスタンス作成は推奨外
  ③ 代替サービスへの移行を計画

代替案:
  1. AWS CDK（推奨） - Infrastructure as Code
  2. Service Catalog - ポートフォリオ管理
  3. Terraform Cloud - ポリシー・ガバナンス
  4. Spacelift - Terraform GUI 管理
  5. Backstage - IDP プラットフォーム

AWS CDK への移行

Proton → AWS CDK 移行戦略

Proton テンプレート:
  ├─ Environment Template
  └─ Service Template

AWS CDK に変換:
  ├─ CDK Stack（Environment 相当）
  └─ CDK Stack（Service 相当）

利点:
  - TypeScript / Python での完全な柔軟性
  - Construct Hub で再利用可能コンポーネント
  - L1・L2・L3 レベルの抽象化
  - CloudFormation 以上の能力

例:
  environment-template.yaml
    ↓
  environment-stack.ts（CDK）

  service-template.yaml
    ↓
  service-stack.ts（CDK）

移行手順:

① Proton テンプレートの CloudFormation を抽出
② CDK Construct に変換
③ CDK Pipelines で CI/CD 実装
④ Service Catalog と統合（セルフサービス）

Terraform Cloud・Spacelift

Proton → Terraform Cloud・Spacelift

Proton メリット:
  - AWS ネイティブ統合
  - Self-Service Portal

Terraform Cloud・Spacelift メリット:
  - マルチクラウド対応（AWS・GCP・Azure）
  - Terraform の完全な柔軟性
  - Cost estimation・Policy as Code
  - より成熟したエコシステム

移行例:

Proton:
  Environment Template → Terraform モジュール
  Service Template → Terraform モジュール
  
Terraform Cloud:
  Run State 管理
  Plan・Apply フロー
  Policy as Code（Sentinel）

Spacelift:
  Plan・Apply GUI
  Cost estimation
  Policy enforcement
  Notifications

類似サービス比較

観点	AWS Proton	AWS CDK	Service Catalog	Terraform Cloud	Spacelift
IaC 言語	CloudFormation / Terraform	TypeScript / Python / Go	CloudFormation	Terraform	Terraform
Self-Service Portal	✅ ネイティブ	⚠️ CDK Pipelines	✅ ポートフォリオ	⚠️ API / Terraform Cloud UI	✅ GUI
マルチクラウド	❌ AWS のみ	❌ AWS のみ	❌ AWS のみ	✅	✅
バージョン管理	✅	⚠️（Git）	✅	✅	✅
Cost Management	⚠️	❌	❌	✅	✅
コミュニティ	小規模	大規模	小規模	大規模	成長中
Status	End-of-Support 2025/12	Active	Active	Active	Active

ベストプラクティス

✅ Proton 運用中

1. テンプレートを Git で管理
   理由: バージョン管理・Audit Trail

2. バージョニング戦略を明確に
   理由: 段階的な更新を可能に

3. Terraform 対応テンプレートを作成
   理由: End-of-Support 後への移行を簡単に

4. CI/CD パイプラインを自動化
   理由: セルフサービス文化を促進

5. ダッシュボード・アラート設定
   理由: リソース・コスト監視

✅ End-of-Support 移行準備

1. 今から CDK・Terraform への移行計画を開始
   理由: 2025 年 12 月末までに移行必須

2. 既存 Proton テンプレートをドキュメント化
   理由: CDK / Terraform 変換の参考に

3. テスト環境で CDK・Terraform を試験
   理由: 移行リスク低減

4. Backstage IDP の採用検討
   理由: Proton のセルフサービス機能を保持

2025-2026 最新動向

1. Terraform Cloud・Spacelift の台頭

IaC 標準が CloudFormation → Terraform にシフト

理由:
  - マルチクラウド対応
  - より成熟したエコシステム
  - Policy as Code（Sentinel・OPA）
  - コミュニティの活動が活発

2. Backstage を中心とした IDP トレンド

Backstage：
  - Software Catalog
  - Developer Portal
  - TechDocs
  - Plugins

統合対象:
  - Terraform Cloud
  - AWS CDK
  - Service Catalog
  - GitHub・GitLab

3. AWS CDK の強化

CDK 進化:
  - L3 Construct の充実
  - Construct Hub での共有
  - CDK Pipelines の成熟度向上
  - CDK for Terraform（CDKTF）での Terraform 対応

学習リソース

公式ドキュメント

代替サービス・リソース

実装例・チェックリスト

チェックリスト

## Proton 運用・移行チェック

### 現状把握
- [ ] 既存 Proton テンプレート数を確認
- [ ] 稼働中の Environment Instance 数
- [ ] 稼働中の Service Instance 数
- [ ] 依存チームを把握

### End-of-Support 対応計画
- [ ] 移行先（CDK・Terraform Cloud など）を決定
- [ ] 移行スケジュール（2025 年 12 月末までに完了）
- [ ] 移行テーム・予算確保

### テンプレート準備
- [ ] 既存テンプレートをドキュメント化
- [ ] CloudFormation を抽出
- [ ] CDK / Terraform へ変換開始

### 代替プラットフォーム検証
- [ ] AWS CDK でテンプレート作成
- [ ] Terraform Cloud でテンプレート作成
- [ ] Backstage との統合検証

### 移行実施
- [ ] テスト環境で新テンプレート動作確認
- [ ] ステージング環境で本番環境テスト
- [ ] 本番環境への段階的切り替え
- [ ] Proton リソース削除・クリーンアップ

### ドキュメント・知見共有
- [ ] 移行ガイド作成
- [ ] チーム研修・ハンズオン実施
- [ ] Best Practice ドキュメント共有

まとめ

AWS Proton（v2.0） は、プラットフォームエンジニアリング時代の重要なサービスでしたが、2025 年 12 月 31 日に End-of-Support となります。

Proton の価値

✅ Environment Template + Service Template = IDP 実装
✅ セルフサービス + ガバナンスの両立
✅ バージョン管理による一括更新
✅ CI/CD 自動化

移行戦略

段階的移行：

2025 年 Q2・Q3: 準備
  - AWS CDK・Terraform Cloud 検証
  - テンプレート ドキュメント化

2025 年 Q4: テスト環境移行
  - テスト環境をテンプレート移行
  - チーム研修

2025 年末〜2026 年初: 本番環境移行
  - ステージング環境から段階的に
  - Proton リソース削除

推奨代替サービス

AWS CDK - AWS ネイティブ・柔軟性重視
Terraform Cloud - マルチクラウド・Policy as Code
Backstage - IDP プラットフォーム・UI 重視
Service Catalog - ポートフォリオ管理

最終更新：2026-04-27 バージョン：v2.0

重要： AWS Proton は End-of-Support が決定しています。新規プロジェクトは AWS CDK・Terraform Cloud・Backstage + Service Catalog の採用を推奨します。既存 Proton ユーザーは 2025 年 12 月末までの移行計画を緊急に策定してください。

目次

AWS Proton v2.0 完全ガイド 2026

初心者から実務者向けの包括的解説

ドキュメントの目的

2026 年の Proton エコシステム

目次

概要

Proton が解決する課題

1. インフラ知識とセルフサービスの両立

2. テンプレート更新の一括適用の困難性

3. インフラ多様性による運用負荷

主な特徴

1. Environment Template（環境層）

2. Service Template（アプリ層）

3. Infrastructure Abstraction（インフラ抽象化）

アーキテクチャ

Proton の 2 層テンプレートモデル

Environment Instance と Service Instance の関係

Environment Template（環境テンプレート）

テンプレート構成

schema.yaml（パラメータ定義）

cloudformation.yaml（基盤テンプレート）

Service Template（サービステンプレート）

サービステンプレート構成

instance_infrastructure/cloudformation.yaml

Component（コンポーネント）

コンポーネント = 再利用可能なユニット

CI/CD Pipeline 統合

pipeline_infrastructure での CI/CD 設定

Terraform 対応

Terraform によるプロビジョニング

主要ユースケース

1. マイクロサービス・プラットフォーム

2. 複数環境管理（dev・staging・prod）

3. セルフサービスポータル + Backstage

テンプレート設計のベストプラクティス

✅ Environment Template 設計

✅ Service Template 設計

バージョン管理・段階的更新

テンプレートバージョンニング

段階的な更新適用

設定・操作の具体例

AWS CLI での実装

CloudFormation / Terraform

ECS / Lambda / Kubernetes

複数のサービステンプレート

Backstage IDP 統合

Backstage + Proton で統一ポータル

セキュリティ・監査

IAM・CloudTrail・VPC

トラブルシューティング

End-of-Support への移行計画

⚠️ 2025-12-31 Proton End-of-Support

AWS CDK への移行

Proton → AWS CDK 移行戦略

Terraform Cloud・Spacelift

Proton → Terraform Cloud・Spacelift

類似サービス比較

ベストプラクティス

✅ Proton 運用中

✅ End-of-Support 移行準備

2025-2026 最新動向

1. Terraform Cloud・Spacelift の台頭

2. Backstage を中心とした IDP トレンド

3. AWS CDK の強化

学習リソース

公式ドキュメント

代替サービス・リソース

実装例・チェックリスト

チェックリスト

まとめ

Proton の価値

移行戦略

推奨代替サービス