【アーキテクチャ紹介】AWS上の社内VPN環境を作り直した話

AWS運用自動化サービス「Cloud Automator」

こんにちは、技術2課 長崎です。

ログインでIP固定が必要なシステムなどがあり、社内でVPN環境を構築、利用しているところも多いかと思います。
SWXでもVPNサーバをAWS上に構築し、運用していました。
依存度が高いわけではなく、止まったら基本的に再起動すれば良いので
コスト面を考慮しシングルインスタンスで稼働していましたが、最近社員数増加(エンジニアの数で作った当初の5倍以上)に伴い、サーバへの負荷も増加し「VPNに繋がらない」という事象が頻繁に発生するようになりました。

そこで、さらなる負荷増加を見据えてVPN環境をリプレースする事となりました。

ClientVPNにはまだ行けない事情(主にIdpとの連携)がある中で
新たに社内VPN環境として採用した、SWXで使っていて他の人にも参考になるような
アーキテクチャを紹介したいと思います。

OS/ソフトウェア

  • Amazon Linux 2
  • Softether VPN(OpenVPN機能利用)

AWS Client VPNを利用しなかった理由

私たちが利用しているIdpにはまだ未対応な為です。

IPSecVPNではなく、OpenVPNを採用した理由

IPSecVPNではポート4500と500(デフォルト)の2ポートを使用します。
それに対し、OpenVPNはポート1194(デフォルト)の1ポートしか使用しません。

以下構成図通りに構築すると、LBによってそれぞれ別のサーバに振り分けられてしまう可能性が
ある事と、今後の運用を考えると複数ポートよりは単一ポートで運用したかった為です。

構成

いたってシンプル。NLB配下にAutoScalingグループでEC2インスタンスを構成し、NATGWを利用してインターネットに出ます。

スパイク負荷増加に耐える為に

スケーリングポリシーにてCPU使用率が低い段階から細かくしきい値を設ける事で柔軟にスケールアウトするような設計にしました。
以下、詳細

参考

OpenVPNの設定

以下コマンドを実行
※コマンドの詳細はこちらをご確認ください。

最後に

個人的に今回の社内VPN環境更改は、VPNについて理解を深める良い機会となりました。
ゆくゆくはAWS Client VPNで作り直したいですね。

AWS運用自動化サービス「Cloud Automator」