条件

インフラ構成を考える前に、事前にもらった前提条件を整理しました。
条件は大きく分けて下記の4つです。

1. ドメインはAWS外のシステムで管理しているが、新システムには未使用のサブドメインが割り当てられる
2. AWS環境はDirectConnectによりオンプレ環境と接続される
3. DirectConnectを使うのだから、システムがインターネットに公開されているという状況は避けたい
4. 開発環境にDockerを使用しているので、本番環境にもDockerを使用できるようにECSを使いたい

考えてみた

1. ドメインはAWS外のシステムで管理しているが、新システムには未使用のサブドメインが割り当てられる

AWSのサービスを使用してシステムを構築する上でDNSはできればRoute53で管理したいところですが、今回はドメイン全体を移管することが難しそうです。
なので、こちらを参考に、新たに割り当てられるサブドメインのみをRoute53で管理するようにしましょう。

2. AWS環境はDirectConnectによりオンプレ環境と接続される

こちらに関しては特に言及することはありません。
強いていうなら、ALBを使うことになるので、AWS側にそれなりの大きさのサブネットが割り当ててもらえるように政治力を発揮しましょう。

3. DirectConnectを使うのだから、システムがインターネットに公開されているという状況は避けたい

今回はプライベートサブネット上にシステムを展開すれば良いだけですが、インターネットから諸々ダウンロードしてくる必要がある場合でも、NATゲートウェイを使えば簡単に解決できそうです。
ただし、完全にインターネットからのアクセスが遮断されることになるため、管理用の踏み台サーバーを作成するか、セッションマネージャー経由でSSHアクセスできるようにしておくようにしましょう。

4. 開発環境にDockerを使用しているので、本番環境にもDockerを使用できるようにECSを使いたい

遅くなりましたが、これが本記事の本題です。
WEBシステムのためにECSを使用するということは、ほぼ間違いなくALBを使用することになります。

普段ALBを使用する際は、パブリックサブネットにまたがるALBを使用するかと思いますが、今回は要件的にパブリックサブネット上にシステムを構築することができません。
しかし、ALBにはinternal ALBというVPC内部向けの種類があり、今回はこちらを使用することでプライベートサブネットにまたがるALBが構築でき、プライベート環境でもECSが使用できるようになります。

また、ECSではECRからコンテナイメージをPULLするためにインターネット接続が必要となりますが、NATゲートウェイを構築していれば問題にはなりません。

あとはALBのドメインをRoute53のALIASレコードに設定することで、オンプレ環境からALBに割り当てられたプライベートIPを解決することができるようになります。

最終的な構成図

これまでの設計を図に起こすとこんな感じです。

おわりに

今回はDirectConnectと接続したVPCないにシステムを構築するという条件付きでAWS構成を考えてみました。
普段だとあまり意識しないことにも注意しながら構築しないと、AWSの良さを十分に発揮できないことがわかりました。

余談ですが、オンプレ側のPCがインターネットに繋がっていない場合は、今回の構成ではALBの名前解決ができないはずなので、もう一歩踏み込んだ構成にする必要がありそうです。