Transit Gateway（TGW）を学ぶと、ほぼ全員が同じ壁にぶつかります。「association（アソシエーション）」と「propagation（プロパゲーション）」がどうしても混同する——この2つです。私もAWS SAPの学習で、単体では区別できていたのに、複数サービスが絡む統合問題になった瞬間に取り違えて減点しました。本記事は、私がその事故を経て「二度と混同しなくなった」覚え方——associationは「地図を見る」、propagationは「住所を載せる」——を軸に、両者の違いと、それを使ったルートテーブル設計（セグメント分離）までを実体験で解説します。
1. 結論：associationは「地図を見る」、propagationは「住所を載せる」
細かい説明の前に、混同を消す1行を置きます。これさえ握れば、設問でも実務でも迷いません。
- association ＝「自分がどの地図(ルートテーブル)を見るか」。1つのアタッチメントはちょうど1つのルートテーブルに紐づく（1対1）。そのアタッチメントが通信先を決めるとき参照する地図を1枚だけ選ぶ行為です。
- propagation ＝「自分の住所(CIDR)をどの地図に載せるか」。1つのアタッチメントは複数のルートテーブルに自分のCIDRを広告できる（1対多）。「ここに私はいますよ」と地図に書き込む行為です。
動詞で覚えるのがコツです。association＝見る（1枚）、propagation＝載せる（複数枚）。この「見る／載せる」の主語と数の違いが、混同を完全に断ち切ります。
2. なぜ混同するのか：TGWを3要素に分解する
混同の原因は、TGWを「ひとかたまり」で捉えているからです。私がDay2の学習で腹落ちしたのは、TGWは次の3要素に分けて考えると一気に整理できる、という点でした。
| 要素 | 役割 |
|---|---|
| アタッチメント | TGWに何を繋ぐか（VPC / VPN / Direct Connect Gateway / TGWピアリング） |
| TGWルートテーブル | その路線がどこへ行けるか（経路表＝地図） |
| association / propagation | アタッチメントとルートテーブルの紐付け方 |
つまり association と propagation は、3つ目の「紐付け方」の話です。同じ「アタッチメントとルートテーブルを繋ぐ」操作でも、向きと数が逆——ここを分けずに覚えるから混ざります。鉄道で例えるなら、アタッチメント＝駅、ルートテーブル＝時刻表（地図）、associationは「その駅がどの時刻表を見るか」、propagationは「その駅をどの時刻表に載せるか」です。
3. association ＝ 1対1「どのルートテーブルを見るか」
アタッチメントは、必ず1つだけのルートテーブルにassociateされます。これは「このVPC（アタッチメント）が通信先を判断するとき、どの地図を見るか」を決める設定です。1つのアタッチメントが2枚の地図を同時に見ることはできません（1対1）。
だから、通信のグルーピングは association で作ります。「本番系の通信」「開発系の通信」「共有系の通信」のように、ふるまいの違うグループごとにルートテーブルを用意し、各アタッチメントをそのグループの地図にassociateする。ここがセグメント設計の骨格です。
4. propagation ＝ 1対多「自分のCIDRをどの地図に載せるか」
propagationは逆向きです。あるアタッチメント（VPC）のCIDR（住所）を、どのルートテーブルに広告するか。これは1枚に限らず、複数のルートテーブルに同時に載せられます（1対多）。
「共有サービスのVPCは、本番からも開発からも到達したい」なら、共有VPCのCIDRを本番用RTにも開発用RTにも propagateする。こうして初めて、本番・開発の各アタッチメントが地図上に「共有VPCへの行き方」を見つけられます。associationで「どの地図を見るか」を決め、propagationで「その地図に何を書くか」を決める——役割がきれいに分かれます。
5. 実践：Prod/Dev遮断＋Shared共有を「往復」で設計する
この2つを使う典型が、本番(Prod)と開発(Dev)は相互遮断しつつ、共有(Shared)サービスには双方からアクセスさせる設計です。手順はこうなります。
- association（地図を割り当てる）：Prodアタッチメント→Prod-RT、Dev→Dev-RT、Shared→Shared-RT に、それぞれ1対1でassociate。
- propagation・行き（Sharedへ到達させる）：SharedのCIDRを Prod-RT と Dev-RT の両方 にpropagate。
- propagation・戻り（Sharedから返せるように）：ProdのCIDRとDevのCIDRを Shared-RT にpropagate。
- 遮断（ここが肝）：ProdのCIDRをDev-RTに載せない／DevのCIDRをProd-RTに載せない。地図にお互いの住所が無い＝経路が存在しないので、Prod↔Devは通信できません。
私が2日連続でやらかしたのが、この「戻り」の載せ忘れでした。SharedのCIDRをProd/Dev側に載せて満足し、Prod/DevのCIDRをShared-RTに載せ忘れる。すると行きだけ通って戻れず、通信が成立しません。ルーティングは必ず「行き」と「戻り」を声に出して2回確認する——これは実務のオンプレ／クラウド問わず効く鉄則です。
6. 私がやらかした混同（実体験）
整理して書いていますが、私はここに何度も落ちました。失点パターンは2つです。
- ルートテーブルの枚数をVPCの数で数えた：8VPCあるから8枚、と誤答。正解は「ふるまい（通信パターン）の数」でグルーピングするので、Audit/Business/Shared の3パターンなら3枚。VPCが何個でも、挙動が3種なら3枚です。association（どの地図を見るか）の本質を分かっていれば、枚数は挙動数だと即わかります。
- 統合問題で association と propagation を取り違えた：単体では区別できるのに、複数サービスが1問に同居した瞬間に逆に書いた。対策は本記事の冒頭——「見る(1枚)／載せる(複数枚)」の動詞と数で毎回確認すること。これで事故は止まりました。
まとめ
associationは「どの地図を見るか」(1対1)、propagationは「住所をどの地図に載せるか」(1対多)。通信のグルーピングはassociationで作り、到達性はpropagationで「行き」と「戻り」の両方を載せて初めて成立する。ルートテーブルの枚数はVPC数ではなく「ふるまいの数」で決まる。この3点を握れば、TGW最頻出の引っかけはもう踏みません。
このTGWの設計知識は、その手前の「そもそもVPCをどう繋ぐか（ピアリング／TGW／PrivateLink）」が前提になります。3つの使い分けは別記事で整理しているので、合わせてどうぞ。学習の全体像はまとめページから追えます。