Amazon Web Services ブログ
ECS Anywhere のプライベート接続を確立する方法
本記事は、「How to establish private connectivity for ECS Anywhere」(2023 年 5 月 26 日公開)を翻訳したものです。
はじめに
2014 年、AWS は Amazon Elastic Container Service (Amazon ECS) を発表しました。これは、コンテナ化されたアプリケーションのオーケストレーション、デプロイ、スケーリングを支援するフルマネージド型サービスです。Amazon ECS は、さまざまな業界業種のお客様にご利用いただいていますが、アプリケーションをローカルで実行する必要がある場合もあります。特に規制の厳しい業界ではよくある要件になります。この課題を解決するためにAWSは Amazon ECS を拡張し、2020 年に Amazon ECS Anywhere (Amazon ECS-A)を発表しました。これは、お客様が Amazon ECS のシンプルさと機能性を利用して、コンテナベースのアプリケーションを AWS リージョン以外で、お客様のオンプレミス環境で実行できるオプションです。仮想マシン (VM)、ベアメタルサーバー、またはお客様が管理するその他のインフラストラクチャを使用することが可能となります。
ECS-A コントロールプレーンは AWS 上で動作し、Amazon ECS と同じ API ですが、コンテナベースのアプリケーションは任意のセルフマネージドのハードウェアでホストすることが可能です。このようにコントロールプレーンとデータプレーンを分離するためには、企業のデータセンターと Amazon ECS エンドポイント間の通信パスが必要であり、多くの場合、プライベート通信チャネルが必要になります。
この記事では、AWS リージョン外でホストされている Amazon ECS Anywhere 管理のコンテナベースのアプリケーションと、Amazon ECS コントロールプレーン API との間で、AWS サイト間 VPN (S2S VPN) または AWS Direct Connect (DX) を使用して、安全かつプライベートな方法でプライベート通信チャネルを確立する方法について説明します。
ECS-A ソリューションアーキテクチャ
Amazon ECS Anywhere を使用すると、お客様は独自のインフラストラクチャと Amazon ECS を合わせて活用することが可能となり、コンテナワークロードを大規模にスケジュールし、実行することが可能となります。独自のインフラストラクチャを使用するためには、VM を Amazon ECS マネージドインスタンスとして登録する必要があり、お客様の施設と AWS リージョン間の接続が必要です。この接続は、インターネット経由で公開することも、AWS Direct Connect または仮想プライベートネットワーク (VPN) を使用してプライベートに確立することもできます。
コンフィグの一部として、オンプレミス環境には AWS Systems Manager (SSM) エージェントと Amazon ECS エージェントの両方が必要です。
SSM エージェントは AWS Systems Manager のコンポーネントで、AWS Systems Manager のオンホスト機能を実行します。インスタンスから AWS API を実行できるようにするために、インスタンス登録プロセスで、AWS Systems Manager がアクティベーションキーとインスタンスロール認証情報を生成して SSM エージェントに送信します。もう 1 つのコンポーネントは Amazon ECS エージェントで、これは AWS リージョンの Amazon ECS コントロールプレーンと通信し、サーバーまたは VM をマネージドインスタンスとして登録し、コンテナ設定やタスクスケジューリングなどの指示を受信して実行します。図 1 はこのアーキテクチャを示しています。
図1
ソリューション概要
ECS-A プライベート通信アーキテクチャ
Amazon ECS Anywhere は接続切断や信頼性の低い接続に耐えられますが、AWS リージョンとお客様の施設間のプライベート接続により、より高いレベルのセキュリティ、信頼性、およびパフォーマンスが保証されます。図 2 は、Amazon ECS エージェントと SSM エージェントがコントロールプレーン API を使用してプライベートかつ安全に通信できるアーキテクチャを示しています。ECS Anywhere コントロールプレーン API 宛のプライベート VPC エンドポイントを作成し、DNS クエリを Route 53 インバウンドリゾルバーエンドポイントに転送し、プライベート IP アドレスで応答することで、エージェントはプライベート通信チャネル (DX やサイト間 VPN など) を介して AWS サービスと通信します。
図2
前提条件
このソリューションの前提条件は以下となります。
- AWS アカウント
- Amazon ECS Anywhere クラスタ
- AWS Direct Connect やサイト間 VPN によるVPC とオンプレミス環境間のプライベート接続
プライベート通信チャネル
この記事では、オンプレミス環境と AWS VPC の間にプライベート通信チャネルを設定する方法については詳しく説明しません。ただし、(1) AWS Direct Connect と (2) サイト間 VPN の 2 つのオプションがあります。
どちらを選択しても、この通信チャネルが設置されていれば、AWS とオンプレミス環境との間にプライベート IP アドレスを使用して双方向接続が可能になります。
ウォークスルー
以下のコンポーネントは任意の順序でデプロイできます。
- Amazon VPC 内で Amazon ECS と AWS Systems Manager のインターフェース VPC エンドポイント(AWS PrivateLink)
- Amazon VPC 内での Route 53 リゾルバーのインバウンドエンドポイント
- オンプレミス環境での DNS 条件付き転送ルール
最後に、オンプレミス環境の Amazon ECS-A エージェントが AWS とプライベートに通信するように設定します。
AWS PrivateLink
AWS PrivateLink は、トラフィックをインターネットに公開することなく、VPC、AWS サービス、オンプレミスネットワーク間のプライベート接続を提供します。AWS PrivateLink を使用するには、インターフェイス VPC エンドポイントを作成します。VPC エンドポイントを作成すると、指定したサブネットにネットワークインターフェイスが作成され、サブネットのアドレス空間からのプライベート IP がそのインターフェイスに割り当てられます。このアーキテクチャでは、6 つのエンドポイントを作成する必要があります。
図3
オプションとしてAmazon Elastic Container Registry (Amazon ECR) を使用してコンテナイメージを保存する場合は、以下のエンドポイントが追加で必要になります。
また、Amazon CloudWatch Logs でログを受信したい場合は、以下のエンドポイントも必要になります。
Route 53 インバウンドリゾルバー
オンプレミスリソースが VPC エンドポイントの DNS 名をプライベート IP アドレスに解決する必要があります。このステップを省略した場合、ドメイン名がパブリック IP アドレスに解決されます。
1 つの選択肢は、VPC エンドポイントの A レコードをオンプレミスの DNS サーバーに設定することです。ただし、エンドポイントを再作成したり、サブネットを変更したりする場合は、これらの A レコードを手動で変更する必要があります。言い換えると、これらのレコードが最新の状態に保たれるようにする責任をユーザーが持つ必要があります。
それに対して、推奨される解決策は、Amazon Route 53 リゾルバー用のインバウンドエンドポイントを作成することです。インバウンドエンドポイントを使用すると、外部ネットワークからの VPC に対する DNS クエリを解決できます。そして、オンプレミス DNS サーバーが特定のドメインのクエリを Route 53 リゾルバーに転送するように、条件付き転送ルールを設定します。これにより、VPC 内のリソースの DNS レコードの管理について心配する必要がなくなります。
「インバウンド転送の設定」セクションの手順に従って設定してください。図 4 は、2 つの IP アドレスを持つ構成済みのインバウンドエンドポイントの例を示しています。
図4
オンプレミスの DNS 解決
最後のステップは、前述の 6 つのサービスのクエリを転送するようにオンプレミス DNS サーバーを構成することです。<region>.amazonaws.com ドメインを Route 53 リゾルバーのインバウンドエンドポイントの IP アドレスに送信します。これは DNS サーバーソフトウェアに大きく依存します。図 3 の 6 つのエンドポイントに対して、次の DNS 転送を構成する必要があります。
これらの設定の後、オンプレミスエージェント (Amazon ECS と SSM) が AWS エンドポイントに到達しようとする際に、ターゲットドメイン名を解決すると、オンプレミス DNS サーバーは DNS クエリを Route 53 インバウンドリゾルバーに転送し、対応する VPC エンドポイントのプライベート IP が応答されます。エージェントは、事前に確立されたプライベート通信チャネル (DX や S2S VPN など) を使用して VPC エンドポイントのプライベート IP と通信します。
ハイブリッド DNS アーキテクチャの詳細については、Hybrid Cloud DNS Options for Amazon VPC のホワイトペーパーをご覧ください。
DNS 設定およびオンプレミス環境から Route 53 Resolver エンドポイントの IP へのアクセスを確認するには、dig、nslookup、またはその他任意の DNS ルックアップコマンドを使用できます。
結果には、インターフェイス VPC エンドポイントのプライベート IP(前の例では 10.0.0.45)が出力されるはずです。
設定の詳細とトラブルシューティングのヒントについて、「How do I configure a Route 53 Resolver inbound endpoint to resolve DNS records in my private hosted zone from my remote network」の記事には Route 53 Resolver インバウンドエンドポイントの詳細な設定手順が記載されています。
SSM エージェントと ECS-A エージェント
ここまできて、Amazon ECS-A をセットアップすることができます。クラスターのアクティベーションキーを取得し、両方のエージェントをインストールして、インスタンスを登録します。
詳細な手順については、「クラスターへの外部インスタンスの登録」のドキュメントページを参照してください。
クリーンアップ
追加の検証コストの発生を防ぐために、作成したすべての VPC エンドポイントとインバウンドエンドポイントを削除してください。
VPC エンドポイントの削除
- VPC コンソールを開きます。
- [仮想プライベートクラウド] の [エンドポイント] に移動します。
- 作成したエンドポイントを選択し、[アクション] → [VPC エンドポイントの削除] をクリックします。
インバウンドエンドポイントの削除
- Route 53 コンソールを開きます。
- [リゾルバー] セクションの [インバウンドエンドポイント] に移動します。
- インバウンドエンドポイントを選択します。
- [削除] を選択します。
結論
この記事では、AWS サイト間 VPN または AWS Direct Connect のプライベート接続を使用して、Amazon ECS Anywhere の高いレベルのセキュリティと信頼性を実現する方法を紹介しました。
AWS 側で必要な設定手順 (インターフェイスエンドポイントとリゾルバーエンドポイント) と、オンプレミスの DNS 転送の設定手順の概要について説明しました。
自身の環境でこのソリューションを試して、プライベート通信チャネルを活用してください。Amazon Simple Storage Service (Amazon S3) や Amazon CloudWatch など他のサービスにも同様のトラフィックフローを適用することができます。詳細については、「Hybrid Networking using VPC Endpoints (AWS PrivateLink) and Amazon CloudWatch for Financial Services 」と「Secure hybrid access to Amazon S3 using AWS PrivateLink」の記事をご覧ください。
著者について
Ivo Pinto
Ivo は AWS のシニアソリューションアーキテクトです。Ivo は、ネットワークを専門とし、オンプレミスとクラウドの両方で世界規模のインフラストラクチャを構築した経歴があります。3 つの CCIE を持ち、Cisco Press の「Network Automation Made Easy」という本を執筆しています。
Diogo Minhava Lopes
Diogo は AWS のシニアソリューションアーキテクトです。ソフトウェア開発の経歴があり、共同設立したスタートアップ企業を含め、異なる規模の企業にクラウドテクノロジーを活用する 8 年間の経験を持ちます。
Pedro Santos
Pedro は、リスボンを拠点とする AWS のシニアソリューションアーキテクトです。データエンジニアリングとクラウドアーキテクチャを専攻し、過去 8 年間クラウドテクノロジーに携わってきました。
翻訳はソリューションアーキテクトの陳誠が担当しました。