DNSが要求されたときにEC2インスタンスを自動的に起動する

DNSが要求されたときにEC2インスタンスを自動的に起動する

Docker 内で Web アプリケーションを実行する EC2 インスタンスがいくつかあり、コスト削減のため、営業時間外 (午前 7 時から午後 7 時など) は自動的に停止するように設定しています。以前に設定した営業時間外にアクセスしたい場合に備えて、Web アプリの URL が要求されたときに (EC2 が停止している場合でも) インスタンスが起動するように自動化できるかどうかを知りたいです。

AWS Lambda 内でアプリケーションを実行することを勧める人もいますが、DNS 呼び出しで関数を開始するにはどうすればよいでしょうか?

答え1

これは簡単にはできません。Lambda と Route 53 のログ記録を使用して複雑な方法を見つけることもできますが、たとえそれができたとしても、EC2 インスタンスを起動するのに 5 分かかることがあります。つまり、EC2 インスタンスが起動するまでに、リクエストがタイムアウトしていることになります。

ラムダ

アプリケーションを Lambda / サーバーレス コンピューティングで書き直すと、この問題は解消されます。料金はリクエストごとに支払うだけなので、ほとんどの場合、それほど高額な料金はかかりません。ほとんどのサーバーレス アプリケーションのコストは非常に低額です。ただし、一部のアプリケーションでは、EC2 インスタンスよりもはるかにコストがかかる場合があります。

実用的なオプション

コストを抑える最も実用的な方法は、おそらく、大きなインスタンスの数を減らすのではなく、自動スケーリングと小さなコンピューティング ユニットを使用してスケール アウトすることです。1 つの小さなリソース セットを 24 時間 365 日実行し、忙しい時間帯にはより多くのリソースを実行します。

コンテナでは、Fargate を使用して、リソースの少ないコンテナを 24 時間 365 日稼働させ、負荷が増大したときにリソースを増やすことを検討できます。これは、自動スケーリングまたはスケジュールされたスケーリングのいずれかです。同じ ECS クラスター内で Fargate と EC2 を使用できるかどうかはわかりませんが、使用できる場合は問題が解決する可能性があります。

答え2

Web アプリの URL が要求されたときに ec2 インスタンスを起動することはできません。インスタンスが要求を処理できる状態になる前に、http 要求がタイムアウトになります。

認証は行われないため、ボットからのランダムなリクエストによって ec2 インスタンスの起動がトリガーされます。

理論的には、たとえば、EC2 インスタンスを起動できる Lambda 関数への特定のパスにリクエストをルーティングする ALB を使用することで、これを実行するスタックを作成できるはずです。ただし、それに関連するリソースは、インスタンスを 24 時間 365 日実行するよりも高価になります。

コストを削減したい場合、AWS は最適なプロバイダーではない可能性があります。

関連情報