- マルチアカウント環境の自動タグ付与 ── EKSリソースの除外とコストで4案を比較した設計判断
はじめに
「リソースにタグを付ける」
文字にすると、たった一行の要件です。しかし私たちの環境は、数十を超える Amazon Web Services（AWS） アカウント、10リージョン、月6万件を超えるリソース作成イベントが飛び交う大規模マルチアカウント環境です。これを「自動で・確実に・低コストで」実現しようとした瞬間、話はまったく単純ではなくなりました。
こんにちは。株式会社NTTデータ九州の濱里です。
AWSを中心にクラウドアーキテクチャの設計・構築を担当しています。
この記事は、私が自動タグ付与アーキテクチャを設計するにあたり、4つの案を比較し、それぞれの落とし穴に頭を抱えながら最終的に1つの構成へたどり着くまでの記録です。きれいな結論だけでなく、途中でぶつかった制約や葛藤も含めて共有します。同じような課題に取り組む方の参考になれば幸いです。
この記事の概要
マルチアカウント・多リージョン環境で、EKSが大量に生み出すリソースを除外しながらタグを自動付与する方法を、4つのアーキ案で比較しました。決定要因は「イベント欠損の許容可否」で、最終的にAWS Config Advanced Queryを使った週次スキャン方式を採用しています。マルチアカウント運用の設計者やFinOps担当の方に向けた、
1. なぜ自動タグ付与が必要だったのか
1.1 タグ運用の限界
私たちの環境では、リソースに対して多くのタグを手動で付与する運用を続けてきました。しかしタグ設計の見直しを進める中で、現場から切実な声が上がってきました。
- 「タグ付与の手間が、得られる価値に見合っていない」
- 「付与忘れが多発しそう（というか、している）」
タグは付いていて初めて意味を持ちます。コスト配賦、リソースの所在把握、棚卸しのいずれも、タグが正確に付いていることが前提です。しかし人間が手で付ける以上、抜け漏れは必ず発生します。
1.2 発想の転換：「自動で取れる情報は、自動で付ける」
そこで方針を切り替えました。AWS CloudTrailのログ設計選定の記録です。などから機械的に決定できる情報は、人間の手を離れて自動で付与しようという考えです。
自動付与の対象に定めたのは、CloudTrailのログやAPIから確実に決定できる4種類の情報です。
| タグの種類 | 値の例 | 付与する目的 |
|---|---|---|
| Account識別タグ | 123456789012 | 多数のアカウントを横断してリソースを把握するため。AWS Resource Explorerでタグを検索キーにし、アカウント単位でリソースを洗い出す（例：アカウントごとのEC2数の把握）用途に使う |
| Region識別タグ | ap-northeast-1 | 管理するリージョンが多く、リージョン単位でリソースを把握する必要があるため。タグを検索キーに、横断的な絞り込みや棚卸しを行う |
| VPC識別タグ | 対象VPCのNameタグ値 | ネットワーク構成の追跡や、VPC単位でのリソース集計のため |
| Subnet区分タグ | Public / Private | セキュリティ区分・公開範囲を一目で判別できるようにするため |
ポイントは「ログやAPIから確実に決定できるものだけに絞った」ことです。手動で付与していたタグは全15種類で、そのうちログやAPIから機械的に決定できる4種（Account／Region／VPC／Subnet）を自動化の対象としました。残る11種（要素名やシステム識別子など）は人の判断が必要なため、引き続き手動または別の仕組みに委ねます。つまり今回の施策で手間と付与忘れが軽減できるのは、15種のうち4種の範囲です。それでも、AccountとRegionは対象リソースすべてに付与するタグで、値が機械的に決まるのに手動で付けていた部分でした（VPCとSubnetはVPCに属するリソースが対象です）。効果が見込めるところから自動化する、という判断です。自動化する範囲を欲張らないことが、最初の重要な設計判断でした。
1.3 本記事が担う範囲
タグ付与は、値の決まり方によって大きく2つに分けられます。本記事が扱うのは、そのうちの片方だけです。
| 分類 | 付与の手段とタイミング | 対象タグ | 本記事での扱い |
|---|---|---|---|
| 人が決めるタグ | IaC（Terraformの default_tags）で作成時に付与、または手動 |
環境識別タグ / システム識別タグ / コスト識別タグなど | スコープ外（別途対応） |
| 機械的に決まるタグ | 本記事の自動付与（作成を検知して後から付与） | アカウント識別タグ / リージョン識別タグ / VPC識別タグ / Subnet区分タグ | 本記事の対象 |
「人が決めるタグ」は、Terraformの default_tags を使い、リソース作成と同時に付与しています。作成時点で確定させる予防的なアプローチです。一方で「機械的に決まるタグ」の4種は、あえて default_tags には含めず、自動付与に委ねる設計にしました。
では、なぜ4種も default_tags で作成時に付けてしまわないのか。理由は、IaCによる予防だけでは取りこぼしが出るからです。新しくフォルダを切ったときに providers.tf の記載が不足していたり、マネジメントコンソールから直接作成されたリソースはIaCを通りません。こうしたリソースには、作成時のタグ付与が効きません。そこで、作成を検知して後から機械的に付与する「検出的」な仕組みで、取りこぼしを含めて4種を確実に埋めることにしました。本記事は、この検出的な自動付与の設計を扱います。
2. 立ちはだかった3つの制約
設計を始めてすぐ、この環境ならではの制約が次々と姿を現しました。
2.1 制約その1：規模が大きすぎる
対象は数十のAWSアカウント、そして10の管理リージョンにまたがります。「1アカウントで動けばOK」ではなく、「全アカウント・全リージョンで確実に動き、かつ展開・保守できる」ことが求められました。
2.2 制約その2：EKSが生み出す大量のEC2
過去3か月のリソース作成数を集計して、私たちは目を疑いました。
| リソース | 3か月合計 |
|---|---|
| EC2（EKSが作成したもの） | 181,503件 |
| EC2（EKSが作成したものを除く） | 178件 |
| その他（ELB, Lambda, S3, RDS等） | 約2,100件 |
EC2の作成イベントの 99.9%がAmazon EKSによるもの だったのです。EKSはPodのスケジューリングやオートスケーリングのために、裏で猛烈な勢いでEC2（ノード）を作成・破棄します。
なお、後述するコスト試算では、3か月の平均ではなく、あるセール期間にあたる月の実測値である64,869件（EKSによる作成を含む）を基準にしています。最も負荷が高い月を基準にすることで、コスト比較を保守的に見積もっています。
これらにまでタグ付与処理を走らせると、コストと処理性能に無視できない影響が出ます。方式によってはAWS Configの評価回数が跳ね上がり、月$60超のコストがかかります。さらにAWS Lambdaの最大処理時間（15分）超過やAPIスロットリングのリスクも生じます。しかもEKSが作成したEC2にタグを付けても運用上の意味はほとんどありません。**「EKSが作成したEC2をいかに除外するか」**が、アーキテクチャ選定を左右する最大の論点になりました。
2.3 制約その3：Security Hub CSPMを使っていない環境
比較を始める前に、もう一つ大事な前提がありました。私たちの環境では、AWS Security Hub CSPM（Cloud Security Posture Management）による継続的な準拠チェックの仕組みをまだ採用していません。
Security Hub CSPMを土台にした構成は、各メンバーアカウントの評価結果を管理アカウントに集約し、タグ未付与を一元的に検知できる強力な仕組みです。検討の過程ではこの仕組みを使った「中央集約型」の構成も候補に挙がりました。しかし採用するには、全メンバーアカウントでのSecurity Hub CSPM有効化、Delegated Admin設定、IAM Role配置など、新たに整える前提条件が多くあります。
さらに検討を進める中で、もう一つ気づきがありました。「管理アカウントに情報を集約する」こと自体に、当初期待したほどの意味がなかったのです。集約した先で一元的に活用できる情報や、運用上のメリットが実質的に見当たりませんでした。むしろ評価処理を各メンバーアカウントと管理アカウントの両方に持つことになり、コストと構成の複雑さだけが増える結果になりそうでした。「集約する」という響きの良さだけで構成を選んではいけない、という学びです。
今回はすでに稼働している仕組み（CloudTrail、AWS Resource Explorer、AWS Config）の上に構築することを優先しました。そのため、AWS Security Hub CSPMを前提とする中央集約型の構成は、環境的な制約として比較の対象から外しました。
3. 評価軸を決める ── 何をもって「良い」とするか
複数の案を比べるには、まず「ものさし」が必要です。私たちは次の観点を評価軸として設定しました。
- コスト：月額いくらかかるか。特にEKSの6万件をどう処理するかで大きく変わる
- EKS除外の確実性：EKSが作成したEC2を確実に除外できるか、タイミング問題はないか
- 拡張性：将来タグを追加したくなったとき、情報源として耐えられるか
- 構成のシンプルさ：コンポーネントが少なく、障害時の切り分けが容易か
- 信頼性：イベント欠損やLambda実行時間超過のリスクはないか
- リアルタイム性：リソース作成からタグ付与までのラグは許容できるか
- 運用性：全アカウントへの展開・切り戻しが容易か
そして、アーキテクチャを 「トリガー層（何をきっかけに動くか）」 と 「実行層（どうやってタグ値を決めて付けるか）」 の2層に分けて整理しました。実行層はどの案もLambdaで共通です。差が出るのはトリガー層です。
3.1 実行層は本当にどの案も同じなのか
「実行層はLambdaで共通」と書きましたが、正確には「Lambdaという実行手段」が共通なだけで、タグの値をどこから逆引きするかという実行層のロジックは案ごとに異なります。
| 案 | 実行層の情報源 | 逆引きの方法 |
|---|---|---|
| A | CloudTrailのログ | Trailログのresponse要素からVPC ID・Subnet IDを取得し、Describe APIでNameタグを逆引き |
| B | ARN（Resource Explorerが返す識別子） | ARNをパースしてAccountID・Regionを抽出。VPC・SubnetはDescribe APIで別途逆引き |
| C・D | AWS Configの構成アイテム | Config自身が保持する構成情報（関連VPC ID・Subnet ID等）から直接タグ値を決定 |
情報源が違うと、拡張性にも差が出ます。ConfigやCloudTrailは構成変更の経緯や関連リソースの情報を豊富に持つため、将来「作成者」「作成日時」のようなタグを追加したくなったときにも対応しやすくなります。一方でARNは識別子そのものしか持たないため、拡張の余地が小さくなります。トリガー層の違いだけでなく、この実行層の情報源の違いも、拡張性の評価軸に直結していました。
トリガー層は2つの軸で分類できます。
- 起動方式：即時（イベント駆動）か 週次（スケジュールバッチ）か
- AWS Configを使うか使わないか
この掛け合わせで、4つの案（A〜D）を検討しました。
4. 4つの案と、それぞれの苦悩
案A：CloudTrail + EventBridge イベント検知（即時・各アカウント完結）
CloudTrailの管理イベントをAmazon EventBridgeで拾い、パターンマッチした瞬間にLambdaを起動する、最も直感的な構成です。
良かった点：即時にタグが付きます。そしてEKS除外が明快に決まりました。EventBridgeのイベントパターンで、userAgent が eks.amazonaws.com のものを anything-but で除外するだけです。Lambdaが起動する前の段階で除外できるため、余計な処理もコストも一切発生しません。月額はわずか$0.003です。
この eks.amazonaws.com という値は、実際に自社環境のCloudTrailログで RunInstances イベントを確認し、裏取り済みです（ログ自体は社内情報を含むため本記事には掲載していません）。ただし、EKSノードのプロビジョニング方式（マネージドノードグループ／セルフマネージド／Karpenter／EKS Auto Modeなど）によって値が変わる可能性があります。自環境に適用する際は、必ず実際のCloudTrailログでこの値を確認してから運用に組み込むことをお勧めします。
悩みどころ：CloudTrailからEventBridgeへのイベント配信は「ベストエフォート」です。公式ドキュメントでも「AWSサービスはCloudTrailへのイベント配信をベストエフォートで行う」「まれにイベントが配信されないことがある」と明記されています（Amazon EventBridge - Delivery level for AWS service events）。つまり、ごくまれにイベントが届かず、タグ付与が漏れる可能性がゼロではありません。この構成単体では「漏れたこと自体」を検知できないのが弱点でした。
案B：EventBridge Scheduler + Resource Explorer + Describe API（週次・各アカウント完結）
週に1度、EventBridge SchedulerがAWS Step Functionsを起動し、Lambda①がResource Explorerでタグ未付与リソースを洗い出します。抽出したリストをMap Stateで並列処理し、Lambda②がDescribe APIでVPCやSubnetの情報を逆引きしてタグを付けます。
良かった点：Scheduler起動のため確実に実行されます。構成もシンプルで、月額$0.125と低コストに収まります。
悩みどころ：致命的だったのは次の2点です。まず、Resource Explorerは「そのリソースが誰によって作られたか」という作成元の情報を持たないため、EKSが作成したEC2を除外できません。全リソースにタグ付けを許容するしかないのです。もう一つは拡張性です。取得できる情報量で比べると、Resource Explorer ＜ CloudTrail ≒ AWS Config という序列です。そのため、将来「作成者」「作成日時」などのタグを追加したくなっても対応できません。拡張性の天井が低いのです。
案C：Config ルール（即時・各アカウント完結）
AWS Configがリソースの構成変更を検知し、カスタムルールでタグの有無を評価します。NON_COMPLIANTであればAWS Systems Manager Automationのランブック経由でLambdaが起動し、Config構成アイテムの情報からタグを付ける、コンプライアンス志向の構成です。
良かった点：準リアルタイム（数分）でタグが付きます。Configダッシュボードでタグ準拠状況を可視化できます。
悩みどころ：ここで大きな壁にぶつかります。
- コスト：Configルールはリソース作成のたびに評価が走ります。EKSの6万件も例外なく評価対象。評価コストだけで月$64.87（64,869件 × $0.001/評価。AWS Config料金ページより）、Lambda実行分を含めた合計は**$64.98/月**。評価そのものを止められない点が痛手です。なお、この$64.87はリソースの作成イベント数を基準にした見積もりです。実際のConfigルール評価は、EC2のライフサイクル変化（起動中→実行中→停止中→削除済み等）でも構成アイテムが記録されるたびに走るため、実際の評価回数はこれを上回る可能性があります。$64.87は下限に近い数字と捉えてください。
- EKSタグ反映のタイミング問題：EKSが作成したEC2に付くはずのEKS管理タグには、反映まで若干のタイムラグがあります。Configが評価した瞬間にまだタグが付いていないと、EKSが作成したEC2を誤って修復対象にしてしまいます。
- 構成の複雑さ：Config標準の修復アクションはSSM Automationのランブック経由となるため部品が多く、障害の切り分けが難しくなります。
案D：EventBridge Scheduler + Config Advanced Query（週次・各アカウント完結）★採用案
週に1度、EventBridge SchedulerがStep Functionsを起動し、Lambda①がConfig Advanced Query（SQLライクなクエリ）でタグ未付与リソースを抽出します。Lambda②がConfig構成アイテムの情報からVPC・Subnet名を逆引きしてタグを付けます。
良かった点：Config Advanced Query自体に追加料金はかかりません（Configを有効化済みであることが前提です）。AWS Config料金ページでも課金対象は「記録された構成アイテム数」「ルール評価数」「コンフォーマンスパック評価数」の3つのみで、Advanced Queryへの追加課金はありません。しかもクエリ結果にはタグ情報が含まれるので、EKS管理タグを持つリソースを、確実に、タイミング問題なしで除外できます。週次スキャンの時点ではEKSタグは確実に反映済みだからです。月額はわずか$0.019です。Config構成アイテムという情報の宝庫を情報源にできるため、将来のタグ拡張にも強くなります。
悩みどころ：唯一の弱点はリアルタイム性がないことです。リソース作成からタグ付与まで最大1週間のラグが出ます。ただ、今回は「タグ付与の即時性は必須要件ではない」と整理できたため、これは許容できる制約でした。
なお、Config Advanced Queryはタグのような入れ子構造をSQLで直接展開できないという制約があるため、実装では「SQLで粗く絞り込み、タグの正確な判定はLambda側で行う」という役割分担で対応しています。
5. コスト構造が浮き彫りにした「本質」
4案のコストを並べたとき、案Cだけが突出して高コストになりました。ここで示す金額は、いずれも対象の数十アカウント×10リージョン全体を合計した月額です。1アカウント・1リージョンあたりの金額ではありません。
また、この比較はAWS Configが既に有効化されている環境における増分コストです。私たちの環境ではConfigを本施策より前から有効化していたため、構成アイテムの記録費用（$0.003/件）は既存コストとして扱い、比較の対象外にしています。案C・案DはこのConfig記録費用の上に評価コストやクエリ実行コストが乗る形になりますが、案A・案BはそもそもConfigを必要としません。Configを未導入の環境でこの比較を参考にする場合は、記録費用が別途発生する点に注意してください（月6万件規模の記録では、それだけで月$180程度になります）。
| 案 | 月額 | EKS除外 |
|---|---|---|
| A | $0.003 | ◎ 確実（EventBridgeで除外） |
| B | $0.125 | × 不可（全件許容） |
| C | $64.98 | △ タイミング問題あり |
| D（採用） | $0.019 | ○ 確実 |
案Cが高コストになる理由は、突き詰めると次の1点です。**「リソース作成のたびに評価処理が自動で走り、月6万件のEKSが作成したEC2の評価を止められない」**ことです。
逆に案A・B・Dが安いのは、評価処理を挟まず、必要なときにデータを取得・検索するだけだからです。コンプライアンス可視化という付加価値と引き換えに、EKS環境では評価コストが重くのしかかります。この構造が見えたことが、案選定の決定打になりました。
6. たどり着いた結論：案D
最終的に採用したのは 案D（EventBridge Scheduler + Config Advanced Query） です。総合評価をまとめると次のようになりました。
| 観点 | 案A | 案B | 案C | 案D★ |
|---|---|---|---|---|
| 月額コスト | $0.003 | $0.125 | $64.98 | $0.019 |
| EKS除外 | ◎ | × | △ | ○ |
| 拡張性 | ○ | △ | ○ | ○ |
| 構成のシンプルさ | ◎ | ◎ | △（SSM Automation経由で部品が多い） | ◎ |
| 信頼性（イベント欠損） | まれにあり | なし | なし | なし |
| リアルタイム性 | 即時 | 週次 | 準即時 | 週次 |
| 運用性 | ○（StackSetsで一括展開） | ○（StackSetsで一括展開） | ○（StackSetsで一括展開だが障害切り分けが複雑） | ○（StackSetsで一括展開） |
表を見ると、コスト・EKS除外・拡張性は案Aとほぼ差がありません。むしろコストだけで見れば案Aのほうが安く、EKS除外も即時性も案Aが優位です。実質的に案Dが案Aに勝っているのは「イベント欠損：まれにあり」対「なし」の1点だけです。
つまり、この選定の決定要因はイベント欠損の許容可否でした。案Aの弱点は、CloudTrailからEventBridgeへのイベント配信がベストエフォートであるため、ごくまれにタグ付与が漏れる可能性がある点です。タグ付与の確実性を最優先する方針だったため、多少のリアルタイム性を犠牲にしても、イベント欠損のリスクがない週次スキャン方式を選びました。
検討の過程では、案A（即時付与）と案D（週次の突き合わせで漏れを補完）を組み合わせるハイブリッド構成も候補に挙がりました。合計コストは$0.022とごくわずかで、即時性と確実性を両立できる魅力的な構成です。しかし、運用対象が2系統（即時処理と週次処理）に増え、障害時の切り分けが複雑になることを懸念し、見送りました。最終的には、週次方式単体の確実性を取り、タグ付与が最大1週間遅れるタイムラグを許容する判断をしました。
7. 将来を見据えた仕込み：Step Functionsによる並列化
案Dは、対象件数が少ないうちは軽い処理で完結します。ただし、対象リソースやアカウントが増えれば、いつか単一Lambdaの15分制限に達する日が来るかもしれません。
そこで、週次実行の案には最初から Step Functions Map Stateによる並列化 を組み込んでおきました。
EventBridge Scheduler（週次）
↓
Lambda①（タグ未付与リソース一覧を取得）
↓ リストを返却
Step Functions Map State（並列実行）
↓ リストを分割して並列実行
Lambda②（タグ付与）× N並列
嬉しい誤算だったのは、この並列化のコスト増分がほぼ無視できるレベルだったことです。Step Functionsは状態遷移1,000回あたり$0.025で課金されるため、1件あたりの遷移コストは$0.000025です。月額でも$0.01未満に収まります（AWS Step Functions料金ページ）。なお、Step Functions Standard Workflowsには月4,000回の状態遷移まで無期限の無料枠があるため、週次実行という頻度であれば実質無料に収まる可能性が高いです。「今はシンプルに、必要になったら並列化」という段階的な設計方針を、最初から低コストで実現できました。
8. 現状と、効果測定について
案Dは2026年6月から本番環境で稼働しています。対象の全アカウント・全リージョンへStackSetsで展開し、週次でタグ付与が動いている状態です。
一方で、この記事は「効果を実測した事例」ではなく「アーキテクチャ選定の記録」として書いています。導入前の未タグリソース率や手動付与にかけていた工数といった、導入前後を比較するための定量指標を取得していないためです。「付与忘れがどれだけ減ったか」を数字で示すことは、現時点ではできません。
加えて、週次方式には構造的な限界もあります。AWSのコスト配分タグは、タグが付いた時点以降の使用量にのみ適用され、過去に遡って反映されません。そのため、リソース作成からタグ付与までの最大1週間分は、コスト配分レポート上で「タグなし」として記録され、後から回収できません。
ただし、この自動付与4種（Account／Region／VPC／Subnet）は、起動・停止スケジュールのようにリソースの動作そのものに関わるタグではなく、検索・集計のための識別タグです。そのため、1週間のラグが生じても運用上の実害は小さく、コスト配賦の観点でも許容できると判断しました。この整理から、案A（即時付与）との組み合わせは現時点では見送っており、案D単体で十分と判断しています。
9. 振り返って ── この検討で学んだこと
タグを付けるだけの仕組みに、私たちはずいぶん頭を悩ませました。その過程で得た教訓を3つ挙げます。
1つ目：自動化する範囲を欲張らない。 ログやAPIから確実に決まる情報に絞ったからこそ、設計がシンプルに保てました。人の判断が要る情報まで自動化しようとしていたら、破綻していたはずです。
2つ目：環境の「クセ」がアーキテクチャを決める。 今回はEKSが生む大量のEC2という特性が、案選定を最後まで支配しました。一般論としての「ベストプラクティス」ではなく、自分たちの環境の実データ（6万件のEKSが作成したEC2）と向き合ったことが、正しい判断につながりました。また、Security Hub CSPMを使っていないという環境の前提も、比較対象を絞り込む上で重要な判断材料になりました。
3つ目：コンプライアンス可視化は「タダ」ではない。 Configによる可視化は魅力的ですが、EKS環境では評価コストが重い。付加価値とコストのトレードオフを、数字で冷静に比較できたことが決め手になりました。
「たった1つのタグ」の裏には、規模・EKS・環境的制約という3つの壁と、4案分の試行錯誤がありました。同じように大規模マルチアカウント環境でタグ運用に悩む方にとって、この記録が少しでもヒントになれば嬉しいです。
執筆日：2026年8月18日
免責事項：
本記事は執筆時点の情報に基づいています。AWSサービスの仕様・料金は変更される可能性があるため、利用時は最新の公式ドキュメントをご確認ください。