複数システムが同居した 15 年物の AWS アカウントを解体するための考古学

JAWS FESTA 2026 in AKITA で話しました。
https://jawsfesta2026.jaws-ug.jp/timetable/c0af092d-58d9-4714-8c0e-e2ecc3f6a1e9

Transcript

1. "触るのが怖い" 複数システムが同居した 15 年物の AWS アカウントを解体するための考古学 @wa6sn #jawsug #jawsfesta2026
2. 誰？ @wa6sn（わらしな） 株式会社ギフティ / Platform Unit AWS/GCP のアカウント管理、セキュリティ、データ基盤など https://wa6sn.github.io/ 多分 JAWS 初参加です 🙏 2
3. 今日話すこと 技術的な How の話は控えめです 今回、地道な営みにより、複数のシステムが同居した AWS アカウントの「オーナーシップ」を明確にする 過程の話をします 2024 年ごろの取り組みです 最終的に、1 つを残してそれぞれ別の AWS アカウントに移動しました （が、今回は話す時間がないので、あれば別の機会に……） まだ、こうした取り組みをしたことがない方 が、 はじめの一歩を踏み出すきっかけになるとうれしいです 3
4. 開発 Tips ガチャもこう言ってる 4
5. 前置き
6. 株式会社ギフティ 「eギフト」という、様々な商品やサービスと交換することができる 電子チケットの発券から流通・販売までを一気通貫で提供しています 5
7. 秋田とのかかわり 「旅先納税」等でお世話になっております 🙇 （"ギフティ 秋田" で検索） 6
8. 弊社における AWS 環境 クラウドインフラのデファクト AWS Organizations + Control Tower で 220 アカウントほどを管理 うち、本番運用相当が 90 ほど "原則" 、1 システムに 1 つ以上の AWS アカウント 本番とステージングを別に持っていたり、持たなかったり 7
9. …… げ、"原則" ……？
10. 社内最古の AWS アカウント 創業当時（2010 年） から存在するアカウント 通称 "メインアカウント", "本垢"、ビジネス上でも重要なアカウント 東京リージョン GA（2011/03）よりも前 $ aws account get-account-information ...<snip>... "2010-11-04T05:01:29+00:00" 一つのアカウントに 5 つのシステムが同居 それぞれ別のチームが管理 同じアカウントでないとダメ、といった制約はない 8
11. どう同居？ システム 規模 備考 A おおきめ A, B, C は同一の VPC B おおきめ 同上 C ふつう 同上 D ちいさい E ちいさい 社内向け （プラス、過去さまざまな経緯で作られたものの残骸） 9
12. およその規模感 IAM user（人間を除く）: 37 VPC（ default を除く）: 21 セキュリティグループ（ default を除く）: 約 200 EC2 インスタンス: 約 240 ELB: 72 Elastic IP: 41 S3 バケット: 187 10
13. 同居、なぜ困るのか？ CCoE 的な目線では : ガバナンス構築の際、このアカウントを常に例外として扱い続けることになる チーム間の責任範囲が明確化されない （VPC の共有により）攻撃を受けたときに、横展開されてしまうリスク 利用者にヒアリングしてみた（抜粋） : 「誤操作が怖い。何かを変更しようとした時に影響範囲に自信が持てない」 「最小権限の付与が難しい」 「他のチームのリソースも見えてしまい、一覧性が低い」 11
14. 整理を試みよう 同居していることの不便さは、このアカウントの利用者も当然知っていて、 "触るのが怖い" と認識しつつも手を出せていなかった 2024 年頃から CTO とじわじわ計画を始め、このアカウントの利用者に 対してこのまま使い続けることへのリスクの認識を合わせたのち、 まずは 棚卸しから始める ことにした 各リソースのオーナーシップを明確にすること を最初のゴールとした 12
15. 棚卸し
16. マインドチェンジ まず、"メインアカウント", "本垢" という呼び方をやめた 会社にとって重要な AWS アカウントではあるが、（マイクロサービスアー キテクチャを採用する弊社において）"メイン" は存在しない この呼び方を続けることで、ここに新たなサブシステムが 増えてしまうことを避けたかった 今後、 4321- （アカウント ID の上 4 桁、仮称）という名前で呼ぶことにした 曖昧な名前はかえって混乱を生むので、意図的に無機質な名前にした 13
17. プロパガンダのようす 14
18. 大方針 明らかに不要なものをゴソッと減らして認知負荷を減らした うえで、 各チームに連携して不明なリソースを地道になくしていく これをリソース種別ごとに行い、完了したらその状態を維持する 要調査 最初の状態 要調査 要調査 露払い 要調査 要調査 特定作業とタグ付けの繰り返し 持ち主が明確 掃除済み … 完了 15
19. やったこと 1. Cost Explorer で全体を俯瞰し、不要リソースを掃除 2. 運用ルールの周知、タグによるオーナー明確化 3. CloudTrail + Config で持ち主探し 4. VPC Flow Logs の有効化 16
20. 1. 不要リソースの掃除 1/2 Cost Explorer で「サービス別」や「使用タイプ別」でグループ化して、 何に対して課金が発生しているのかを調査した 知らないアカウントに入ったらよくやっていることの一つ EC2, RDS, S3, CloudWatch 等、どのシステムでもベーシックな サービス群で構成されていることを改めて確認した 棚卸しを進めていくうえで、重点的にやるべきサービス を絞り込んだ 加えて、上記のサービス群以外のサービスの用途を確認した 結果、「とりあえず触ってみた」後の消し忘れのようなものが多かった 17
21. 1. 不要リソースの掃除 2/2 Resource Explorer では、アカウント内のリソースを柔軟に検索できる 各サービスページを開かなくていいし、リージョンを横断して検索できる 例えば 「利用しているリージョン」以外 を条件にリソースを検索する ⇒ 東京・大阪以外に、サンパウロやムンバイ等にも EC2 が……。 他リージョンでのリソースは検証目的で作られたものだったので掃除 18
22. 2. 運用ルールの周知、タグによるオーナー明確化 各システムに対して、「これは自分たちのものですよ」と判別するための タグを付与することを改めて 共通運用ルール として周知 EC2 ならインスタンス, Security Group, ELB 等を対象 元々ある程度タグは付与されていたが、 付与すべき対象も命名もチーム間で統一されていなかった 19
23. Tips: IaC 管理でのタグ付与 IaC の持っている機能を使うと、まとめて付与できる Terraform では default_tags Default Tags in the Terraform AWS Provider CloudFormation ではスタックレベルのタグ CloudFormation リソースへのタグ付け - AWS CloudFormation 自分はよく、由来を示すために managed_by: {repo_name} をつけています 20
24. 3. CloudTrail + Config で持ち主探し ここで、タグがつかなかった・つけられなかったリソース が問題となる i. 複数のシステムが使っているもの ii. もう使っていないとみなされたもの（本当に不要かは別） CloudTrail で、怪しいリソースの作成者に聞き込みをして消したり （ラッキーなことに、2015 年に CloudTrail が有効になっていた！） Config でそのリソースにどのような変更が加わったかの履歴を確認したり それらを Athena でクエリできるようにもして、ガイドしたり 21
26. Tips: CloudTrail と Config は併用しよう CloudTrail だけではなく、Config も有効にしておくと便利 CloudTrail では、API 操作の履歴 （いつ / 誰が / 何をしたか）が分かる 例: ある EC2 について、誰が RunInstances で起動を試みたか？ しかし、今どういう設定なのか はわからない Config では、リソースの設定の履歴 （いつ / どう変わったか）が分かる 例: ある Security Group は、いつからいつまで 22/tcp が空いていたのか？ 他のリソースとの関連が分かることもある しかし、単体では 誰が変更したか はわからない 23
27. 4. VPC Flow Logs の有効化 以下のような課題を解決すべく、有効化 i. 結局そのインスタンスって どこと通信 しているんだ……？ ii. 一つのセキュリティグループを複数のシステムで流用してしまっている。 分離するうえで、あるシステムにとっては余分なルールが存在する ので、 実際の通信内容を判断材料にしたい 自分は「便利じゃん！」とテンション高く導入したが、実際には これを持ち出すほど手のかかる子は居なかったので、あまり出番はなかった 主に自分は「もう使っていないとみなされたもの」を安心して除却するた めに、CloudWatch Metrics と併用 24
28. そんなこんなで、とにかく列挙していく （Elastic IP の例。雰囲気だけ味わっていただきたい） 25
29. Tips: 強い気持ちを持つ 曖昧な名前で作られたリソースは、大体怪しい 例えば operator という名前の、誰も使っていない IAM user B
    さんのやろなあ…… C
    さんのやろなあ…… A
    さんのやろなあ…… A
    さん B
    さん C
    さん ※
    実際にはどのチームの持ち物でもない 誰もオーナーシップを持たないリソースは、強い気持ちで消す とはいえ、EC2 ならまずは stop してから様子を見るし、 一度に消すと困った時の切り分けが難しいのでじわじわ消す 26
31. 治安維持活動 リソースの持ち主が明確になったサービスは、今後もそれを維持するべく、 定められたタグのないリソースを Slack 通知してタグ付けを促す SCP や タグポリシー のような "強制する" 手段もあるが、 それらを導入する前に、まずは運用ギャップを解消したかった 28
32. その後
33. その翌年、解体完了 最終的に、各システムが主体となり、1 つを残してアカウント移動した かつての "メインアカウント" は、システム A 用アカウント になった 💯 それに伴い、各種リソース数はだいたい 1/2 〜 1/4 ぐらいに縮小 システム 規模 その後 A おおきめ 残留 B おおきめ 別アカウントへ移動 C ふつう 別アカウントへ移動 D ちいさい クローズ E ちいさい 別アカウントへ移動 29
34. ログ、大事です CloudTrail, Config, VPC Flow Logs, etc, とにかくログを記録しましょう 経緯を知る人がいなくても、ログがあれば判断できる可能性が高い 特に CloudTrail を有効にしない場合、難易度が激増する CloudTrail もデフォルトでは管理イベント（作成・削除・設定変更）のみ、 S3 の GetObject などのデータイベントは別途有効化が必要 最近では、How の詳細を詰めることに関しては AI の補助で だいぶなんとかやってくれますが、ログがなければ判断は難しい 一定期間蓄積して観察しないと分からないものもあるので、 とにかくログを記録しましょう 30
35. 日々、学び続けることの大切さ 今でこそ「一つのアカウントに混在させるべきではない」と言い切れるが、 当時は当時なりの合理的な判断があった 当時は AWS Organizations もないし、アカウント間でリソース共有を 行うような仕組みも成熟していなかった しかしプラットフォーム側の進化で日々セオリーは変化し続けるので、 いざというときにチャンスを逃さないために、準備をしておく ことが大事 今回も、最終的には全システムが分離するに至ったが、 棚卸しのような取り組みも確実にその準備になった…… はず 31
36. ありがとうございました まだまだ全然、話しきれていません。 ぜひ、懇親会で話しましょう！ #jawsug #jawsfesta2026
37. 余談
38. 今、同じことをやるなら？ 当時から比べても、棚卸しに使えるアップデートがいくつか出ている Compute Optimizer のアイドルリソース検出（2024/11〜） 使われていない EC2, EBS, RDS, NAT GW などを出してくれる セキュリティグループの関連リソース表示（2026/02） その SG に依存している EC2, ENI, RDS などが一覧で見える VPC Flow Logs に EC2 のタグが載るように（2026/06） タグさえ付いていれば、通信元の特定が楽になった 33
39. "作成日時" を持たないリソース 考古学において "作成日時" は重要な情報であり、 それくらいどのリソースにもあるだろう、と思いきや…… ない例 VPC 周辺: VPC, Subnet, Security Group, EIP, ... 更新日時だけの例 Lambda, CloudFront Distribution, SSM Parameter, ... 特殊な例 S3 の ListBuckets API のレスポンスの CreationDate は（その名前に反し 34 て）変更されうる
40. 思ったより普通だね？ もっと年代物の EC2 とかなかったの？と思われるかもしれませんが…… リタイア通知が来たら、止めるか作り直すことになるし、 そうそう生まれづらいのかもしれない 35