NATゲートウェイが請求書の1位である理由
一言でいうと
プライベートリソースが外へ出る道は3つで、料金とセキュリティがそれぞれ違います。何も考えずにNATを使うと、請求書の上位に上がってきます。
なぜ必要なのか
プライベートサブネットを作ると、その中のインスタンスは外へ出る道がありません。ところが、パッケージの更新も受け取る必要があり、ログもアップロードする必要があり、コンテナイメージも取得する必要があります。
最も簡単な答えがNATゲートウェイを1つ置くことなので、たいていそうして、そのあとは誰も見直しません。プライベートサブネットのすべてのアウトバウンドがその1か所に集まり、料金は通過したデータ量だけかかります。
数か月後に請求書を項目別に分けてみると、NATが1位に上がっています。そのトラフィックが不要だったのではなく、道を間違って選んだだけの場合が大半なので、経路を変えるだけで、その金額が消えます。そのため、出ていく道を3つに区別しておき、何をいつ使うかを決めておきます。
3つの道
| 方法 | 何か | 料金 | セキュリティ |
|---|---|---|---|
| インターネットゲートウェイ(IGW) | パブリックサブネットの双方向の通路 | ゲートウェイ自体は無料 | グローバルIPが公開される |
| NATゲートウェイ | プライベート → インターネットの一方向 | 時間あたり + データ処理量 | 安全。外から入れない |
| VPCエンドポイント | クラウドサービスへ直行 | ゲートウェイ型は無料/インターフェース型は有料 | インターネットを経由しない |
NATの料金が大きくなる構造
NATゲートウェイは、2つで課金されます。
1. 시간당 요금 — 켜 두기만 해도 나간다
2. 처리 데이터 요금 — GB 당. 나가는 것도 들어오는 것도
ここにAZごとに1つずつ置くと(可用性のために、そうする必要があります)、その倍数になります。3つのAZならNATは3つです。
問題は2番目です。プライベートサブネットのインスタンスがS3から大容量を読むと、そのトラフィックがすべてNATを通ります。同じリージョンのS3なのに、です。ログの取り込み、バックアップ、コンテナイメージのプル。すべてここへ流れます。
VPCエンドポイントが解決すること
エンドポイントは、クラウドサービスへ向かう専用の通路をVPCの中に作ります。トラフィックはインターネットを経由せず、NATも通りません。
- ゲートウェイ型(S3、DynamoDB): ルートテーブルに経路が追加されます。料金はかかりません。使わない理由がありません。
- インターフェース型(それ以外の大半): サブネットにENIができます。時間あたり + データの料金がありますが、たいていNATより安くなります。
S3ゲートウェイエンドポイントを作るだけで、NATの料金が半分以下に下がる場合がよくあります。クラウドのコスト最適化で、最初に確認する項目の1つです。
セキュリティ上の利点も大きいです。エンドポイントポリシーで、自分たちのアカウントのバケットにだけアクセスするよう制限できます。データ持ち出しの経路を絞る手段になります。
バスティオンの代わりに使うもの
プライベートインスタンスに接続するために、バスティオン(ジャンプサーバー)を置く構成が長く使われてきましたが、最近は代替のほうが優れています。
- セッションマネージャー系: エージェントが外へ向かって接続を張る方式なので、インバウンドポートを1つも開けなくてもかまいません。接続の記録も残ります。
- VPN / ゼロトラストアクセス制御: ユーザー単位の認証と監査。
バスティオンは、それ自体が管理対象で(パッチ、キー管理、ログ)、ポート22が開いている必要があります。なくせるなら、なくすほうがよいです。
オンプレミスとつなぐ
| 方法 | 特徴 |
|---|---|
| サイト間VPN | インターネット上の暗号化トンネルです。素早く構成できます。帯域・レイテンシはインターネット次第です |
| 専用線 | 安定した帯域・レイテンシです。構築に数週間–数か月かかり、高価です |
| トランジットゲートウェイ | 複数のVPCとオンプレミスを星型につなぎます。管理が単純になります |
VPCが3、4個を超えると、ピアリングを網の目のようにつなぐことが、すぐに限界にぶつかります(N個ならN(N-1)/2本の接続)。そのときが、トランジットゲートウェイを導入するタイミングです。
出ていく道を統制すると何が変わるか
入ってくる道は、たいていうまく塞いでいます。出ていく道を開けておく理由は「内から外へ出るのは安全だから」ですが、侵害後のすべての段階は、外へ出る通信です。ツールをダウンロードし、命令を受け取り、データを送ります。
デフォルトで塞ぎ、必要なものだけを開ける順序で進みます。ただし、一度に塞ぐとサービスが止まるので、実際にどこへ出ていくのかを、先に数えます。フローログの拒否記録ではなく、許可記録を数えるのが出発点です。
許可リストは、IPではなく名前で管理してこそ長持ちします。外部APIのアドレスは、しょっちゅう変わります。IPで書くと、ある日黙って切れ、そのとき一時的に広く開けたルールが永久に残ります。名前ベースのポリシーやプロキシを置き、そのリストを管理します。
プロキシを経由させると、2つのことが一緒についてきます。どこへ出ているかの記録が残り、リストにない場所を塞げます。その代わり、プロキシが単一障害点になり、TLSをどう扱うかを決める必要があります。内容を見るには、途中で証明書を差し替える必要がありますが、そうするとそのプロキシがすべての通信を平文で見る場所になります。ほとんどの組織は、宛先の名前(SNI)だけを見て、内容は見ないところで止めます。
メタデータサービスへ出る道が、最も特別です。クラウドで169.254.169.254は、インスタンスの資格情報を渡します。アプリケーションにSSRFの脆弱性があると、攻撃者はこのアドレスを呼び出させて、権限をまるごと持っていきます。この経路は、ファイアウォールではなく、メタデータサービス自体の設定(IMDSv2の強制、ホップ数の制限)で塞ぐのが確実です。
DNSも出ていく道です。すべてのポートを塞いでも、DNSクエリが出ていくなら、それで少しずつデータを持ち出せます。内部リゾルバーだけを使わせ、そのリゾルバーのクエリログを残し、普段と違うクエリ量を見ることが、実務的な対応です。
現場での姿
- 請求書の1位がNAT → S3エンドポイントがありませんでした。
- コンテナイメージのプルのトラフィックがNATへ → レジストリエンドポイントやキャッシュが必要です。
- VPC6個をピアリングですべてつないだ → 15本の接続。トランジットゲートウェイで整理しました。
次に見ること
名前解決と負荷分散。トラフィックが実際にどこへ行くかを決める、最後の層。