AWS ECR が PrivateLink に対応しました。

はじめまして。メディアドゥでインフラエンジニアをしている土屋です。

当ブログにて以前公開した「AWS FargateでNATを利用するときの注意点」では、ECSでNAT利用時に発生した過課金問題とその回避策について紹介しました。

その後、ECSをよりセキュアな構成でECRと併用できる新機能 Amazon ECR PrivateLink Support が、正式にリリースされました。

今回は、ECSでPrivateLinkをつかったECRの利用方法と、その費用感などを簡単にまとめます。

AWS PrivateLinkとは

PrivateLink自体は以前からあるサービスなのでご存知の方も多いと思いますが、

AWS PrivateLink を使用して、データがパブリックインターネットに晒されることを防ぐことで、クラウドベースのアプリケーションで共有されるデータのセキュリティを簡素化できます。AWS PrivateLink は Amazon のネットワーク内で、VPC、AWS のサービス、オンプレミスアプリケーション間のセキュアなプライベート接続を提供します。AWS PrivateLink を使用することで、異なるアカウントにかけたサービスと VPC を簡単に接続し、ネットワークアーキテクチャを大幅に簡素化できます。

と説明されています。

つまり、PrivateLinkを使うことでVPCと様々なAWSサービスをプライベートに接続できるようになります。ざっくり書くと以下のようなイメージです。

f:id:tschyyy:20190227181738p:plain

PrivateLinkを使用するには、対応したAWSサービス(上記ではECR)のEndpointをSubnet内に作成します。Endpointは基本的にプライベートIPアドレスを持つ仮想インターフェース(正しくはElastic Network Interface)として動作し、この場合はSubnetからECRへのエントリポイントとなります。

ECSはこのEndpointをめがけて通信するため、インターネットゲートウェイやNATを使わなくてもECRと接続することができるようになります。

ECRがPriavteLinkに対応したことによる効果

シンプルに言えば、

「ECS＋ECRでPrivate Subnetの利用が可能になった。」

となります。今までPrivate Subnetのように閉じたネットワーク上でサービスを稼働させた場合、以下のような選択肢のみでした。

Private SubnetにNATを配置し、ECRへのアクセスはNATを経由するようにルーティングする。
ECRの利用を断念し、VPC内にPrivate Registoryを立てて運用する。

1の方法を選択した場合、ECRからのpull回数およびdockerイメージのサイズにも依存しますが、安くない費用が必要です。

そこで登場したのが、ECR PrivateLinkとなります。これにより、第3の選択ができるようになりました。

3. Private SubnetにECR向けEndpointを設置し、ECRへのアクセスはEndpointを経由するようにルーティングする。

後述しますが、NATに比べてPrivateLinkの料金は安いため、Private SubnetでECR利用を行うハードルが下がりました。

ECSの起動タイプによるPrivateLinkへの対応状況

公式のリリース情報(2019年1月25日) を確認すると、

Amazon Elastic Container Service (ECS) および Amazon Elastic Container Registry (ECR) が AWS PrivateLink のサポートを開始しました。

AWS Fargate での PrivateLink のサポートは、間もなく開始される予定です。

とあるように、リリース直後はEC2タイプのみをサポートしていたようですが、

下記のIssueを追ってみると2月上旬あたりでFargateも正式にサポートしたようです。
https://github.com/aws/containers-roadmap/issues/1

ちなみに、本記事の執筆時点(2019/2/19)では東京リージョンでもばっちりEC2タイプ・Fargateタイプともに利用可能になっていました。

実際に触ってみる

せっかくFargateタイプにも対応したようなので公式ガイドページを参考にしつつ、Private Subnetに置いたECS(Fargate)でコンテナを起動させるまでの流れを試しました。

コンテナ起動までの流れ

道中でいくつかハマったりもしましたが、最終的に下記の流れでコンテナを起動することができました。

事前にコンテナを配置するためのPrivate Subnetを作成.
適当なdockerイメージをECRへpush
タスク定義を作成(先程あげたdockerイメージを指定)
ECSクラスタを作成(今回はFargateタイプを選択)
ECR、S3、CloudWatch用のEndpointを作成して、Private Subnetへアタッチ
- ECR用に2種類のEndpoint(ecr.api と ecr.dkr)がありますが、Fargateで使う場合は"ecr.dkr"を選択
- S3はdockerのイメージレイヤの保存先として使われるため必要
- CloudWatchはログ保存先として使われるので必要
最後に、作成したタスク定義を選択し、タスクを実行
- コンテナ配置先のSubnetは、事前に作成しておいたPrivate Subnetを選択
- タスクには適切なセキュリティグループを割り当て

ハマったポイント

ECSでコンテナを起動するために、CloudWatch用のEndpointも作成しておかないとエラーになるのですが、公式ページにはその旨の記載がなかったためハマりました。
同様の部分でつまずいた方がいらしたので、こちらの記事を参考にさせてもらいました。

また、タスクに割り当てるセキュリティグループですが、コンテナ自身が所属するセキュリティグループからのインバウンドトラフィックはすべて許可しておく必要があります。(私はここらへんがよくわかっておらずハマってしまいました)

NAT GatewayとPrivateLinkの比較

これまでの流れでも触れてきた通り、Private SubnetでECRを利用するには NAT Gateway もしくは PrivateLink のどちらかを設置する必要があります。ここでは、NAT GatewayとPrivateLinkを使った場合の料金を比較してみます。

料金比較

下記はすべて東京リージョンでの料金となります。(2019年2月時点)

項目	NAT Gateway	PrivateLink(endpoint 1つあたり)
利用可能な時間に対する料金	0.062(USD/時) →30日で約4,910円	0.014(USD/時) →30日で約1,100円
処理データ1GBあたりの料金	0.062(USD) →1TBで約6,820円	0.01(USD) →1TBで約1,100円

PrivateLinkの考慮すべきポイント

料金を考えるうえで一点考慮しなければならないのが、複数のEndpointを並行利用しなければいけないケースがある点です。

例えば、ECSを動かすためには「ECR」だけではなく「S3」と「CloudWatch」の計3つのEndpointを用意しなければ正常に動作しません。このようなAWSサービスごとの仕様により、Endpointの設置コストが掛け算的に増えていく可能性があるため注意が必要になります。

比較まとめ

上記の結果をまとめると以下が言えると思います。

NAT Gatewayを使うよりPrivateLinkを使うほうがお安く、処理データ課金においては1/6程度の費用に抑えられる。
とはいえ、dockerイメージのpullなどによって処理データ(通過するデータの総トラフィック)が増えがちな環境ではPrivateLinkを使ったとしてもそこそこ費用はかかる。
ECSのように複数のAWSサービスとの連携が必須のものがあるので、PrivateLinkを使う場合は必要になるEndpointにかかる費用も考慮しておく。