AWS Client VPN か EC2 上の VPN か: 運用ランブック

どちらの選択肢もチームにリモートアクセス VPN を提供します。したがって重要なのはどちらが存在するかではなく、どちらを運用できるかです。違いは、午前3時にエンドポイントを所有しているのが誰か、障害時にどの制御に手が届くかという点にあります。以下の五つのステップを順番に進めてください。どれも早い段階で比較を打ち切る可能性があるからです。棚卸しのステップを飛ばすと、チームは二度の移行をすることになります。

ステップ1: 請求の前に要件を書く

一枚の紙に五つの事実が必要です。誰が何に対して認証するのか、どのクライアントプラットフォームが動く必要があるのか、どのプライベート宛先に到達できるのか、どの可用性を約束したのか、トラフィックは実際どうなっているのか。これらがなければ、後の比較は機能リストの議論になります。

宛先については具体的に書きます。「VPC へのアクセス」は通常、三つの異なるものを指します。VPC の CIDR、ピア接続されたネットワーク、Transit Gateway の背後にあるオンプレミスのレンジです。マネージドエンドポイントは三つすべてに到達できますが、それぞれにルートと認可ルールが必要で、それぞれが要件の別の行になります。

ステップ2: すでに動いているものを洗い出す

何かを設計する前に、既存のエンドポイントと EC2 上でホストしているサーバーをセキュリティグループとともに一覧にします。これらの呼び出しは読み取り専用で、describe 権限を持つアカウントから安全に実行できます。

aws ec2 describe-client-vpn-endpoints
aws ec2 describe-client-vpn-authorization-rules --client-vpn-endpoint-id cvpn-endpoint-xxxx
aws ec2 describe-client-vpn-routes --client-vpn-endpoint-id cvpn-endpoint-xxxx
aws ec2 describe-client-vpn-connections --client-vpn-endpoint-id cvpn-endpoint-xxxx
aws ec2 describe-instances --filters Name=tag:role,Values=vpn

出力は、クライアントがすでに到達できる範囲の地図として読みます。認可ルールの欠落はルーティングの問題に見える障害を説明し、単一のサブネットに関連付けられたエンドポイントは、ゾーン障害がサービス全体を落とした理由を説明します。

自前でホストするインスタンスに付いているセキュリティグループも記録します。それらのルールはアクセスモデルの一部であり、誰かがテンプレートからインスタンスを再構築したときに最初に静かに壊れるものです。

ステップ3: 責任を分界する

マネージドサービスはエンドポイント群、そのパッチ適用、リージョン内の可用性を所有します。あなたは ID の登録、認可ルール、エンドポイント背後のネットワーク経路、ログ設定、関連付けるサブネット数を所有します。

自前ホスティングはこれを反転させます。あなたはゲスト OS、VPN デーモンとその設定、証明書と鍵、バックアップ、監視、復旧を所有します。EC2 のセキュリティモデルはゲストとアプリケーションのセキュリティを顧客に置き、VPN サーバーも他のゲストと同じゲストです。

分界は右側の列に名前を入れた表として書きます。証明書の更新の隣に誰の名前も来ないなら、それが最大の発見であり、時間単価の差より重要です。

ステップ4: 説明できるワークロードと比較する

コストは大きさではなく形に従います。マネージドの場合、エンドポイントの関連付け時間、クライアント接続時間、転送、有効にする ID とログのサービスを数えます。自前ホスティングの場合、コンピューティング、ストレージ、ネットワーク、ライセンス、サーバーをパッチ適用済みに保つエンジニア時間を数えます。両方の数値を同じ時間軸の一枚の表に置きます。パッチ作業の時間を無視した三年比較は、すでに所有しているサーバーに常に有利になります。

性能の比較にも同じ規律が必要です。対話的なデスクトップセッション一つ、大きな転送一つ、同時の小さなリクエスト五十件は、経路の異なる部分に負荷をかけます。暗号化のための CPU、インスタンスのネットワーク能力、クライアント自身のスタック、そして宛先です。代表的なクライアントと同じ作業で両方の設計を試してください。

大きなインスタンスは転送が速くなる証拠ではなく、一度の成功したセッションは容量計画ではありません。引き継いだインスタンスファミリーの言い伝えは、購入のルールではなく検証すべき仮説として扱います。

ステップ5: 実行済みのロールバックを伴って切り替える

両方のエンドポイントを定めた期間だけ並行して動かし、新しいクライアントプロファイルをまず小さなグループに配布し、そのグループが実務で新しい方を使うまで古いエンドポイントの認可ルールは触らないでおきます。ロールバックは再構築ではなくプロファイルの切り替えなので、古いプロファイルをどこに置くかを今決めます。

次の順で確認します。認証が成功し、クライアントが想定どおりのルートを受け取り、認可された宛先は応答し、認可されていない宛先は失敗し、ログに両方の事象が残ります。どのステップか失敗したら、次のクライアントグループに進むのではなく、そのステップを止めて直します。各確認の結果を書き留めてください。「動いた」とだけ記憶された切り替えは、一か月後にデバッグできません。

切り替え後は地味な確認を予定します。証明書の失効、関連付けの数、もうグループと一致しない認可ルール、想定に対する接続数です。Client VPN 管理ガイドは、設定したエンドポイント、認証、ルーティングの各部分の参照先です。