CloudFormation GitSync のアカウント上限に備える設計

はじめに

先日 AWS CloudFormation(以下、CloudFormation ) の Git 同期機能（GitSync）の接続をひたすら増やしていたら、上限に当たってしまいました。  

そのときは上限があること自体を知らず、しかも引き上げ申請ができないものでした。
GitSync を使うなら先に設計を考えておかないとまずい、という話を書きます。

結論

結論：CloudFormation スタック同期設定はアカウントあたり 100 個までで、この上限は引き上げられません。
テンプレートが増えるたびに同期設定が増える設計にしていると、いずれ頭打ちになります。

上限に当たる仕組み

GitSync はスタック 1 つに対して同期設定が 1 つ必要です。
そのため、スタックを増やせばそのぶん同期設定も増えていきます。

厄介なのは、この上限が CloudFormation のクォータのページには載っていないことです。
GitSync は内部で AWS CodeConnections を使うため、上限は開発者用ツールコンソール側で定義されています。

2026 年 7 月現在の値は以下のとおりです。

• CloudFormation スタック同期設定の最大数：100（変更不可）
• リポジトリリンクの最大数：100（変更不可）
• 接続の最大数：250（引き上げ申請が可能）

引き上げられるものと引き上げられないものが混ざっているので、「上限に当たっても申請すればいい」と考えていると詰まります。
最新の値は 接続のクォータ を確認してください。

対策1：スタックの粒度を粗くする

GitSync を使い続ける前提であれば、同期設定を 100 個までしか使えない前提で設計することになります。

たとえば IAM ロール 1 つだけを持つテンプレートを作り、それを GitSync で繋ぐのはもったいない使い方です。

関連するリソースは 1 つのスタックにまとめ、スタックの数自体が増えない設計を意識します。
「テンプレートを分けたほうが管理しやすい」という考え方もありますが、GitSync を前提にすると、分けた数だけ枠を消費するという別のコストが乗ります。
分けるかどうかを、管理のしやすさだけで決められなくなる点が厄介です。

この対策は GitSync の使い方を変えるだけなので、既存の構成にそのまま適用できます。

対策2：CodePipeline に寄せ、パイプライン自体は自己更新にする

もう 1 つは、そもそも GitSync でスタックを繋がない方法です。

そもそも GitSync は、テンプレートを検知してスタックを更新するだけの仕組みです。
以下のような場合は AWS CodePipeline（以下、CodePipeline）でのデプロイをおすすめします。

• ビルドが必要な場合。AWS Serverless Application Model のようにビルドとパッケージングを挟むものは GitSync だけでは完結しません
• デプロイの依存関係が複雑な場合。先に共通のスタックを更新してからアプリのスタックを更新する、といった順序をつけられます
• デプロイ前にテストを走らせたい場合

こうした要件があるなら CodePipeline を使うことになり、GitSync の同期設定はそもそも不要になります。

残る問題は「CodePipeline 自体のスタックを誰が更新するのか」ですが、これはパイプラインの中に自分自身のスタックを更新するステージを持たせることで解決できます。

- Name: UpdatePipelineStack
  ActionTypeId:
    Category: Deploy
    Owner: AWS
    Provider: CloudFormation
    Version: '1'
  Configuration:
    ActionMode: CREATE_UPDATE
    StackName: example-pipeline
    TemplatePath: SourceOutput::infra/pipeline.yaml
    Capabilities: CAPABILITY_NAMED_IAM
  InputArtifacts:
    - Name: SourceOutput
  RunOrder: 2

パイプラインのテンプレートを更新して push すると、パイプラインが動き、その中で自分のスタックが更新されます。
最初の 1 回だけ手動でデプロイすれば、あとは自分で自分を更新し続けます。

順序に注意する

このとき、デプロイ用の IAM ロールを別のスタックに分けて先に更新する必要があります。
自己更新するスタックがこのロールも一緒に持っていると、権限が足りない状態で権限を付与する処理を実行することになり、順序が破綻します。

ロールを別スタックにしておき、ロールの更新を RunOrder: 1、パイプラインの更新を RunOrder: 2 にすることで、新しい権限が揃った状態でパイプラインの更新が走ります。
私はこの順序に気づかず、修正を何度か重ねることになりました。

運用面での利点

自己更新にしてから気づいたのは、パイプラインの画面を見るだけで何が起きているか分かることです。

GitSync 方式の場合、パイプラインの画面を見ても、そのパイプライン自体が何によって更新されているのかは分かりません。
CloudFormation のコンソールまで見にいって、はじめて GitSync で繋がっていると分かります。
仕組みが画面の外にあるぶん、あとから見た人に伝わりにくいという問題があります。

GitSync が向いている場面

とはいえ GitSync が不要になったわけではありません。
パイプラインを用意するほどではないけれど Git で管理したい、というテンプレートをサッとデプロイする用途には向いています。

一方で、すでに CodePipeline を使っているのであれば、パイプライン自体の更新は自己更新で足ります。
そこに同期設定の枠を使う理由はありません。

まとめ

GitSync のアカウント上限と、その対策を 2 つ書きました。
以前は何でも GitSync で繋げばいいと思っていましたが、引き上げられない上限があると知ってから、繋ぐ前に一度考えるようになりました。
同じように課題を抱えている方の参考になれば幸いです。

この記事は私が書きました

野間 太一

記事一覧

猫とCloudFormationが好きです。