[Boto3 Adv-Cal DAY24]AutoScalingの指定を必要なサービスを含めて0から行う場合の最小限ボリュームをざっくりと触ってみた

boto3 で楽しむ AWS PythonLife 一人AdventCalendarです。24日目はAutoScalingをboto3で組み立てる場合に、生成する必要がある依存サービスを大まかに調べてみました。
2018.12.24

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

boto3 で楽しむ AWS PythonLife 一人AdventCalendarです。

boto3のドキュメントを通して、サービス別にどういった事が出来るのかを理解したり、管理コンソールを通さずにTerminalだけで完結できるように検証していくことが目的になります。

24日目はBoto3ベースでAutoScalingを設定する際に、0から行うとどれくらいの依存が発生するのかをたどってみました。

AutoScalingについて

AWSドキュメント - Amazon EC2 Auto Scalingとは

順を追って理解する場合はBlackBeltをおすすめします。

Boto3でのAutoScalingについて

管理コンソールがフォローしてくれていた箇所をすべて手作業で指定する必要があります。

関連するサービスとしては規模や要素を抑えた場合に大体以下の通りです。RDSや、Lambda等のサーバレスアーキテクチャが増えると更に広がります。

  • AutoScaling
  • IAM
  • EC2

EC2にてネットワークの指定等も必要になってくるため、実際に組み立てる要素は多めです。実装したコードに目が通しづらくなってきます。

ざっくりとした最小依存と思われる関係は大体以下のようになります。

実際に組み立てる場合

Boto3は以下の前提がある時に、管理コンソールからの操作ではやや作業コストがかかる場合に大きな効果を発揮します。

  • 何度も繰り返して同じ処理を実行する
  • 不意の状況に対して動的な変更も加えたい

生成過程の観察等も踏まえて、Boto3でフルに組み立てるのではなく、管理コンソールで事前にいくつかのリソースを生成するか、CloudFormationからのスタック生成がオススメです。

まとめ

AutoScalingについてはBoto3を利用してスクラッチで検証を行う予定でした。しかし、必要になる要素が予想を大幅に超えていたことと、コードの管理が手に負えなくなったこともあり、今回のエントリーにて代替としました。

ただ、AutoScalingを構成しているものを一つ一つ把握したい場合等には割と効果的だったと感じています。気になる方は試してみてはいかがでしょうか。