2026.10.19 AWS

AWS Protonとは：2026年10月7日のサポート終了で残るものと移行手順

AWS Protonは、プラットフォームチームが用意したテンプレートから、開発者がコンテナやサーバーレスのインフラとCI/CDパイプラインを自分で立ち上げられるようにするAWSのサービスでした。過去形なのは、2026年10月7日にサポートが終了し、コンソールとAPIに入れなくなったためです。この記事では、Protonが担っていた役割を短く整理したうえで、終了後も動き続けるもの・止まったもの、残ったCloudFormationスタックを洗い出してテンプレートを取り戻すCLI手順、公式が挙げる移行先4つの比較を、2026年10月19日時点の公式ドキュメントとGitHubの記録に沿って説明します。

まとめ：AWS Protonの現状と残ったスタックを引き継ぐ順番の結論

Protonで作った環境やサービスのリソースは、CloudFormationスタックとしてアカウントに残り、そのまま動いています。止まったのはProtonの管理画面とAPI、そしてProtonのデータです。公式の移行ガイドは、10月7日以降にデータを削除すると明記しています。

引き継ぎは「タグでスタックを洗い出す」「展開済みテンプレートを回収する」「Proton APIを呼ぶパイプラインを止める」の順に進めます。移行先は、環境の概念が要らなければCloudFormation Git sync、承認や段階デプロイが要るならCodePipelineかGitHub Actionsです。公式が4択の1つに挙げるHarmonix on AWSは2025年12月で保守が止まっており、新規の採用先には選びません。

AWS Protonの仕組みと環境・サービステンプレートが担っていた役割

移行先を選ぶには、Protonが何を肩代わりしていたかを先に分解しておく必要があります。

環境テンプレートとサービステンプレートの2層構造と開発者の操作範囲

公式ユーザーガイドの概要によると、Protonのテンプレートは2種類です。環境テンプレートはVPCやECSクラスターなど複数のアプリが共有する基盤を定義し、サービステンプレートは1つのアプリやマイクロサービスの実行基盤と監視、CI/CDパイプラインを定義します。サービスを特定の環境に展開した単位がサービスインスタンスで、本番・検証といった段階ごとに1つずつ作られました。

開発者はテンプレートを選び、ソースコードのリポジトリを指定するだけです。テンプレートの版が上がると、古い版を使っているサービスインスタンスをProtonが一覧にし、管理者が一括で更新を掛けられました。移行で失うのは、この「版の管理と一括更新」と「開発者向けのセルフサービス画面」の2つです。料金ページにあるとおりProton自体は無料で、移行先の費用は新たに発生する分だけ比べれば足ります。

AWS管理・CodeBuild・自己管理の3方式とProtonの関与の違い

プロビジョニング方式の説明では、環境とサービスごとに次の3方式のどれかが使われます。どの方式だったかで、終了後に引き継ぐ作業量が変わります。

方式	IaCの形式	実際に構築する主体	終了後の主な作業
AWS管理	CloudFormation＋Jinja	ProtonがCloudFormationを呼ぶ	スタックとテンプレートの回収
CodeBuild	マニフェストのコマンド（CDK等）	CodeBuildのジョブ	コマンドの実行基盤の付け替え
自己管理	Terraform	自社のGitリポジトリの自動化	Proton連携の呼び出しを外す

自己管理方式は、ProtonがTerraformのプルリクエストを出し、マージ後は自社の仕組みがterraform applyを走らせて結果をProtonに通知する構成でした。コードはすでに自社のリポジトリにあるため、Protonへの通知処理を削れば移行はほぼ終わります。手間が大きいのはAWS管理方式で、テンプレートの原本がProton側にしか無かった組織です。

2026年10月7日のサポート終了で止まったものと稼働を続けるもの

終了の影響範囲を、公式の記述とProton製パイプラインの中身から確認します。

コンソールとAPIの停止とデータ削除、手元に残るスタックとリソース

サポート終了と移行のガイドによると、新規の申し込みは2025年10月7日に締め切られ、既存の利用者も2026年10月7日でコンソールとProtonのリソースにアクセスできなくなりました。同ガイドのFAQは、データの保持を2026年10月7日までとし、それ以降は全データを削除すると答えています。

一方で、デプロイ済みのCloudFormationスタックと、そのスタックが管理するリソースは残って動き続けます。ECSサービスやLambda関数が止まるわけではありません。消えたのはテンプレートの原本と版の履歴、環境とサービスの対応関係、パラメータの入力値です。原本をGitで管理していなかった場合、手がかりはスタックに残った展開済みテンプレートだけになります。

Proton製パイプラインのビルド定義がProton APIを呼ぶ落とし穴

見落としやすいのはパイプラインです。CloudFormationのIaCファイルの説明に載っているサービスパイプラインの例では、ビルド後にaws proton get-serviceでサービス定義を取り、デプロイ段階でaws proton update-service-instanceを実行して新しいイメージを反映します。CodePipelineとCodeBuildのプロジェクトはスタックとして残りますが、この2つのAPIがもう応答しないため、コードをプッシュしてもデプロイ段階で失敗します。

AWSのサンプル集aws-proton-cloudformation-sample-templatesもアーカイブ済みで、更新されることはありません。サンプルから作ったパイプラインは、次のコマンドでビルド定義にaws protonが残っていないかを確かめます。

for p in $(aws codebuild list-projects --query "projects[]" --output text); do
  aws codebuild batch-get-projects --names "$p" \
    --query "projects[0].source.buildspec" --output text | grep -q "aws proton" && echo "要修正: $p"
done

該当したプロジェクトは、デプロイ段階をaws ecs update-serviceやCloudFormationの更新に置き換えるまでリリースできません。障害対応の修正版を出す段で気付くことのないよう、棚卸しの最初に掛けます。

終了後に残ったスタックを棚卸ししてテンプレートを取り出すCLI手順

Protonのデータは消えても、リソース側のタグとスタックの中身から構成を復元できます。

proton:environmentタグを使うスタック名の棚卸し手順

タグ付けの仕様では、AWS管理方式のとき、Protonは構築したリソースにproton:environment・proton:service・proton:service-instanceなどのタグを付けます。値はProton上の環境やサービスのARNです。これと、CloudFormationが自動で付けるaws:cloudformation:stack-nameタグを組み合わせると、Proton由来のスタック名を一覧にできます。

aws resourcegroupstaggingapi get-resources \
  --region ap-northeast-1 \
  --tag-filters Key=proton:environment \
  --query "ResourceTagMappingList[].Tags[?Key=='aws:cloudformation:stack-name'][].Value" \
  --output text | tr '\t' '\n' | sort -u

get-resourcesはリージョン単位で動くため、Protonを使っていたリージョンごとに実行します。キーをproton:service-instanceに替えると、サービスインスタンス側のスタックだけが取得対象です。タグ付けに対応していないリソース種別は結果に出ないので、出てきたスタック名からdescribe-stack-resourcesで全量を確かめます。

get-templateで展開済みテンプレートを回収しパラメータへ戻す作業

ProtonはJinjaで書かれたテンプレートに入力値を埋め込み、完成したCloudFormationテンプレートを作ってからスタックを構築していました。そのためget-templateで取り出せるのは、{{ service_instance.inputs.port }}のような変数がすでに具体値へ置き換わった状態のテンプレートです。

STACK=STACK_NAME_FROM_PREVIOUS_STEP
aws cloudformation get-template --stack-name "$STACK" \
  --template-stage Original --query TemplateBody --output text > "$STACK.yaml"
aws cloudformation describe-stacks --stack-name "$STACK" \
  --query "Stacks[0].{params: Parameters, outputs: Outputs, role: RoleARN}"

回収したテンプレートは、環境ごとに変わる値（CIDR、イメージURI、タスクサイズ、希望タスク数）をParametersセクションに戻してから、Gitに入れます。RoleARNに出るロールはProtonの環境用に用意したプロビジョニングロールで、移行後もスタック更新に使い続けるかを判断する対象です。書き戻したテンプレートはcfn-lintで構文と型を検証し、変更セットで差分が出ないことを確かめてから使い始めます。

公式の移行先4択と2026年10月時点で見直すべき推奨の前提

移行ガイドが挙げる代替は4つですが、そのうち1つは状況が変わっています。

移行先4択を環境の概念・想定チーム・パイプラインの制約で比較する表

公式の移行ガイドの記述を、Protonの機能に対して何が残るかで並べ直すと次のとおりです。

移行先	公式の想定	環境の概念	主な弱点
CloudFormation Git sync	GitOpsで回したいチーム	無い	高度なパイプライン機能が無い
CodePipeline＋CodeBuild	柔軟さと統制を求めるチーム	自作する	実装量が多い
GitHub Actions	GitHub中心の小規模チーム	Environmentsで代替	プラットフォーム側の統制が弱い
Harmonix on AWS	開発者ポータルが欲しい大企業	有る	2025年12月で保守終了

ガイドはGit syncの弱点に「GitHub以外では使えない機能に依存する」と書いています。ただ、Git syncの説明ではGitHub、GitHub Enterprise、GitLab、Bitbucket、GitLabセルフマネージドの5種に対応しており、プルリクエストへの差分コメントも同じ仕組みで出せます。GitLab利用を理由にGit syncを外す必要はありません。

推奨先のHarmonixが2025年12月に保守を終えていた事実と代替

Protonに最も近い機能を持つとされるHarmonix on AWSは、GitHubのリポジトリの冒頭に「2025年12月時点で積極的な保守を終えた」と表示されています。最後のリリースは2025年11月12日公開のv0.4.2で、名前に付いている表記は「Final Release」です。リポジトリはアーカイブされていませんが、利用者には重大な脆弱性への対応としてv0.4.2への更新が求められています。移行ガイドから案内されている専用サイトのドメインも、2026年10月19日時点で名前解決できません。

結論として、Harmonixを新しく導入する選択肢はありません。開発者ポータルが本当に要るなら、Harmonixの土台だったBackstageそのものを自社で運用します。導入手順と成熟度の考え方はPlatform Engineeringとはで整理した内容です。承認済みの構成を部署に配るだけなら、ポータルを作らずAWS Service Catalogの製品として公開する方が運用の手間は小さく済みます。

CloudFormation Git syncでProtonのセルフサービスを代替する手順

4択のうち、Protonの「テンプレートを選んでパラメータを入れる」体験に最も近いのがGit syncです。Git syncは東京リージョンでも使えます。

Git sync用サービスロールの信頼ポリシーとCodeConnectionsの準備

前提条件のページによると、Git syncにはCodeConnectionsでGitプロバイダと接続し、専用のサービスロールを用意する必要があります。ロールは変更セットの作成・実行とスタックの参照、EventBridgeルールの作成の権限を持ち、次の信頼ポリシーを付けます。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "Service": "cloudformation.sync.codeconnections.amazonaws.com" },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": { "aws:SourceAccount": "111122223333" },
        "ArnLike": { "aws:SourceArn": "arn:aws:codeconnections:ap-northeast-1:111122223333:connection/EXAMPLE" }
      }
    }
  ]
}

Conditionの2行は、別アカウントの接続からこのロールを使われる「混乱した代理」問題を防ぐための推奨設定です。コンソールでロールを自動生成した場合、そのロールは生成元の1スタックにしか権限を持ちません。Protonの環境が数十あった組織では、自動生成に頼らずIaCで1本のロールを作って使い回す方が管理しやすくなります。

スタックデプロイファイルとcreate-sync-configurationの実行例

Git syncは、テンプレートとスタックデプロイファイルの2つを監視します。デプロイファイルにはtemplate-file-path・parameters・tagsの3つを書き、パラメータとタグはそれぞれ最大50個です。Protonのサービスインスタンス1つが、デプロイファイル1つに対応すると考えると移しやすくなります。

# deployments/orders-api-prod.yaml
template-file-path: templates/fargate-service.yaml
parameters:
  ImageUri: 111122223333.dkr.ecr.ap-northeast-1.amazonaws.com/orders-api:1.8.2
  TaskSize: medium
  DesiredCount: 2
tags:
  owner: orders-team

# 接続済みリポジトリとスタックを結び付ける
aws codeconnections create-sync-configuration \
  --branch main \
  --config-file deployments/orders-api-prod.yaml \
  --repository-link-id REPOSITORY_LINK_ID \
  --resource-name orders-api-prod \
  --role-arn arn:aws:iam::111122223333:role/CfnGitSyncRole \
  --sync-type CFN_STACK_SYNC \
  --trigger-resource-update-on FILE_CHANGE \
  --pull-request-comment ENABLED

REPOSITORY_LINK_IDには、aws codeconnections create-repository-linkの出力にあるRepositoryLinkIdを入れます。create-sync-configurationのリファレンスどおり、--resource-nameは同期先のスタック名です。開発者はデプロイファイルのイメージタグや台数を書き換えてプルリクエストを出し、プラットフォームチームがテンプレート側をレビューする分担になります。CloudFormationテンプレートの更新で消えやすい設定はAWS CloudFormationとはで扱っています。

Proton利用者の移行先を決める判断基準と移行を見送ってよい場面

最後に、どの移行先を選び、どこまで手を入れるかを条件で言い切ります。

Proton移行先の選び方を環境の概念と本番承認フローの要否で判断する基準

本番前に承認を挟み、検証から本番へ同じ成果物を順に流す運用をProtonで組んでいたなら、Git syncでは足りません。Git syncには環境の概念も段階デプロイも無いからです。この場合はAWS CodePipelineで承認アクションとステージを組むか、GitHub ActionsのEnvironmentsで保護ルールを掛けます。GitHub ActionsからAWSへはOIDCでロールを引き受ける形にし、長期のアクセスキーは置きません。設定はconfigure-aws-credentialsの使い方にまとめています。

反対に、サービスごとに独立したスタックを開発者がパラメータだけ変えて更新していた組織は、Git syncで十分です。CodeBuild方式でCDKを動かしていたなら、ビルド定義をそのままCodePipelineへ移せます。CDK側の構成はAWS CDKとはで確認できます。

構成変更やイメージ更新予定のないスタックを移行せず凍結する判断条件

Proton由来のスタックをすべて新しい仕組みへ載せ替える必要はありません。今後1年以内に構成変更の予定が無く、ECSのイメージ更新もしないスタックは、テンプレートの回収とGitへの保存だけ済ませて凍結します。直す必要が出た時点でGit syncかCodePipelineに載せれば足ります。

凍結してはいけないのは、セキュリティパッチのためにイメージを定期的に更新するサービスと、Proton製パイプラインで本番リリースしていたサービスです。前者は放置すると脆弱性が積み上がり、後者は前述のとおりデプロイ段階がすでに動きません。終了したサービスからの移行は、新規受付の停止が決まったAWS App Runnerでも同じ判断が要ります。スタックの棚卸しとパイプラインの再設計をまとめて進めたい場合は、一創のAWSインフラ構築サービスで現状調査から支援しています。

よくある質問

Protonのサポート終了後によく出る疑問に答えます。

AWS Protonは今から新しく使い始められますか？

使い始められません。新規の申し込みは2025年10月7日に締め切られ、既存の利用者も2026年10月7日でコンソールとAPIにアクセスできなくなりました。同じ目的なら、テンプレートとパラメータをGitで管理するCloudFormation Git syncか、CodePipelineやGitHub Actionsでデプロイの仕組みを組みます。

サポート終了後もProtonで作ったECSサービスは動きますか？

動き続けます。公式の移行ガイドは、デプロイ済みのCloudFormationスタックと管理下のリソースはそのまま機能すると明記しています。止まったのはProtonの管理機能で、テンプレートの版管理と一括更新、Protonを経由したデプロイが使えません。Proton製パイプラインのうち、デプロイ段階でProton APIを呼んでいるものは失敗するため、ビルド定義の確認が必要です。

Protonのテンプレートを手元に保存していなかった場合はどうしますか？

回収元は、アカウントに残っているスタックです。Protonは入力値を埋め込んだ完成形のテンプレートでスタックを作っているため、aws cloudformation get-templateで取り出せます。取り出した内容は変数が具体値に置き換わった状態なので、環境ごとに変わる値をParametersに戻してから再利用します。Jinjaの原本と版の履歴は2026年10月7日以降に削除されており、取り戻せません。

ProtonとAWS Service Catalogの違いは何ですか？

Protonはテンプレートからの構築に加えて、CI/CDパイプラインの作成とアプリのデプロイまで受け持っていました。Service Catalogは、管理者が承認したCloudFormationテンプレートを製品として配り、利用者がパラメータを入れて起動する仕組みで、アプリのデプロイは扱いません。移行先として使う場合は、基盤の配布をService Catalog、アプリのデプロイをCodePipelineやGitHub Actionsと分けます。

Terraformで自己管理方式を使っていた場合は何をすればよいですか？

Terraformのコードは自社のリポジトリに残っているため、移行作業の規模は小さいものです。リポジトリの自動化処理から、ProtonへデプロイのステータスとOutputsを通知するNotifyResourceDeploymentStatusChangeの呼び出しを外します。さらに、Protonが渡していたproton.auto.tfvars.jsonの値の移行先は、通常の変数ファイルです。proton_tags変数で付けていたタグも、不要ならdefault_tagsから外します。