[アドカレ2023]Elastic BeansTalk環境下におけるAuto Scalingの設定変更について

はじめに

こんにちは。
寒かったり暑かったりここ数年で一番異常気象を感じているshitanishiです。
ブログを書くのは久々になりますがお付き合いください。

前置き

今回はElastic BeansTalkの環境下でAuto Scalingを設定している状態でのEC2のセキュリティグループの追加や、新規に作成したALBのターゲットリストへのインスタンス追加設定を行った際の注意点を簡単にですが書いていきます。

Auto Scalingとは

クラウドリソースを自動的にスケールアップまたはスケールダウンするサービスでトラフィックが増えると追加のインスタンスを自動的に起動し、需要が減少するとインスタンスを自動的に停止し、必要最小限のリソースを使用することで使用しないリソースに対するコストを削減できるものです。
参考URL
https://aws.amazon.com/jp/autoscaling/

現状の環境と解決したい問題

・Elastic BeansTalk環境下でAuto Scalingを使用しているサーバAとBの2台がある
・サーバA,B共にAutoScalingによってサーバ2台を保持
・サーバA,B共に上段にALBがあり、サーバBは外部からの80,443接続が可能
・サーバBにてハードコーディングされたホワイトリスト設定があり、これをセキュリティグループに置き換えたい
・サーバAに保持するアプリにてサーバBへの通信を行っているが、現状はGIPを用いたグローバル通信のため、ローカル通信に変更したい

設定変更した内容

・サーバA,B間にALBを新規作成し、サーバAからのインバウンド、サーバBへのアウトバウンドを許可したセキュリティグループをアタッチ
・サーバ間ALBをDNS登録し、アプリの向き先をサーバ間ALBに向ける
・サーバBの上段ALBによりIPを制限
・サーバBのセキュリティグループのインバウンドを上段ALBとサーバ間ALBのみに制限

これによりサーバAからBの通信がローカルなものとなり、外部からの接続も制限されました！
が…　Auto Scalingを使っていることに注意を払えておりませんでした。。

構成としてはこうなった

問題だった点

サーバ間ALBのターゲットリストとサーバBに新規でセキュリティグループを付けた際、手動で普段通り設定を行っていました。
すると、Auto ScalingにてサーバBが刷新されたときに、サーバ間ALBのターゲットグループも、サーバBに手動で追加したセキュリティグループも空の設定となり、誰にも見向きされない可哀そうなインスタンスに(笑)

解決策として

Auto Scalingグループ環境下でセキュリティグループを設定するには、起動設定（Launch Configuration）または起動テンプレート（Launch Template）にて設定を行う必要があります。
これらの設定では、Auto Scalingグループによって生成されるEC2インスタンスに適用されるセキュリティグループを指定できます。

AutoScaling的に変更する方法は2つ

1つは「起動設定(Launch Configuration)」を使用する場合ですが、AutoScalingは2022年12月31日以降にリリースされた新しいEC2機能や新しいEC2インスタンスタイプをローンチコンフィギュレーションではサポートしなくなり、ローンチテンプレートを使用して新しいAutoScalingグループを作成し、既存のローンチ構成をローンチテンプレートに移行することを推奨しています。
そのため「起動テンプレート(Launch Template)」を使用する方法が望ましいのですが、、

ただしElastic BeansTalk環境なので

今回はElastic BeansTalk用いた環境の為、より上位で機能するElastic BeansTalkにてセキュリティグループの設定を行いました。
Elastic Beanstalk > Environments > 対象の環境 > 設定 にて
インスタンスのトラフィックとスケーリングを編集
EC 2 セキュリティグループ欄で付けたいセキュリティグループを選択し、適用。

※注意点としてこの適用を行うとインスタンスの刷新が行われます

これによりサーバがAuto Scalingにて刷新されても設定しておいたセキュリティグループが適用されて見向きされるサーバが誕生しました。

おわりに

文字数多めですね。
わかりやすくかけるよう改善していきます！
伸びしろですね。