2022年2月9日にApp RunnerがVPCアクセスをサポートしたと発表がありました。
App Runnerについては以前も記事にしましたが、VPC内のリソースへアクセスできないことが課題のひとつとなっており実用が難しい状態でした。
今回のアップデートで、それが改善されたので実用性がグッと上がったことになります。
早速、触ってみたのでまとめてみます。
◆以前の記事はこちら
要点
・App RunnerがVPCへのアクセスをサポートした
・App RunnerがVPC内で実行できるようになった訳ではないので注意
・App Runnerへのアクセスをセキュリティグループで制御とかはできない
・VPCコネクタを設定中はアウトバウンドがVPCからになる
・Natゲートウェイ、Natインスタンス、インターネットゲートウェイなどインターネットへ出られる設定が必要になる
・PrivateLinkを利用できるので、必要に応じて設定すると良き
新機能:VPCコネクタ
App Runnerのネットワーキング設定に[カスタムVPC]が追加されています。
接続したいVPCと、接続先のリソースがあるサブネットを登録します。
VPCコネクタにはセキュリティグループを設定する必要があります。
このセキュリティグループのおかげで、RDSやElastiCacheなどのアクセス制御が容易になりますね。
例えば、PrivateSubnet上に実行しているRDSやElastiCacheのセキュリティグループのインバウンド設定に、VPCコネクタに設定したセキュリティグループからの通信を許可する設定を追加するだけで良いことになります。
実用的な構成案
App Runnerを使った実用的な構成案を考えてみました。
App Runnerは指定したECRに新規イメージがpushされたら自動的に新規コンテナをデプロイすることができます。
そのため、DockerイメージのビルドはCodeBuildに任せてしまい、ECRへのpushをトリガーに新バージョンのコンテナをリリースします。
App Runnerから実行されたコンテナは、VPCコネクタのおかげでPrivateSubnet内にあるRDSやElastiCacheなどに安全にアクセスができますね。
ただし、あくまでApp RunnerをVPC内で実行できるようになったわけではなく、VPC内のリソースへアクセスが可能になっただけです。
そのため、外部からのユーザーアクセスのためにセキュリティグループを使うなどといった機能は実装されていないため注意が必要です。
また、公式のドキュメントにも注意事項としてVPCコネクタを設定しているとApp Runnerからのアウトバウンドは全てVPC経由になるそうなので、Natゲートウェイはインターネットゲートウェイなどのインターネットへ出られる経路が必要になります。
(Fargateに慣れてるなら大丈夫だとは思いますが) Natゲートウェイを使う場合はS3やECRなど一部リソースに対してアクセス頻度が多くなる場合にはPrivateLinkを貼っておかないと通信コストが大幅にかかってしまう可能性があるので注意です。
おわりに
App RunnerがVPCへのアクセスをサポートしたことにより実用性がグッと上がりました。
正直なところ、まだまだ死活監視の自由度やリソースの問題(上限が2vCPU/メモリ4GB)などが解決していませんので、多くの場合はECSやEKSを引き続き利用していくことになるかと思われます。
ロードバランサーもALBのようなアクセス制御の柔軟さもなく、リスナールールなどのリッチな機能も使えないですしね。
しかしコンテナへの割り当てリソースの上限が上がるだけでも一気に実用性が増すので、将来的にはApp Runnerがコンテナ環境の主流になる可能性もありますね。
比較的新しいサービスなので、ユーザーの声を聞いてどんどんアップデートされていくことが予想されます。
今後のアップデート情報に期待しましょう!
参考
◆AWS公式ドキュメント -Enabling VPC access for your service-
https://docs.aws.amazon.com/apprunner/latest/dg/network-vpc.html
◆AWS News Blog – New for App Runner – VPC Support –
https://aws.amazon.com/jp/blogs/aws/new-for-app-runner-vpc-support/
◆Twitter for Tori
https://twitter.com/toricls/status/1491202012209623040
コメントを残す