【AWS新機能】CloudFormationがEC2 Auto Scalingの「Instance Refresh」を直接サポート!より安全で柔軟なデプロイが可能に

はじめに

AWSを実務で利用するエンジニアの皆さん、Infrastructure as Code(IaC)でEC2 Auto Scalingグループ(ASG)を運用する際、AMIの更新や起動テンプレートの変更をどのように適用していましたか?

これまで、AWS CloudFormationでASGのインスタンスを段階的に更新するには、AutoScalingRollingUpdate ポリシーを使用するのが一般的でした。しかし、これではEC2 Auto Scalingが持つ最新かつ強力なデプロイ機能(Instance Refresh)の恩恵を十分に受けられませんでした。

今回のアップデートにより、CloudFormationの新しいアップデートポリシーとして AutoScalingInstanceRefresh がサポートされました!これにより、CloudFormationでのスタック更新をトリガーとして、EC2 Auto Scalingネイティブの高度な「インスタンスリフレッシュ(Instance Refresh)」を自動実行できるようになります。

この機能の概要とメリット

新しい AutoScalingInstanceRefresh アップデートポリシーを設定すると、インスタンスの再作成を必要とするプロパティ(AMI、インスタンスタイプ、起動テンプレートなど)がCloudFormationで更新された際、自動的にInstance Refreshがトリガーされます。

この統合により、以下のようなInstance Refreshならではの強力なデプロイ制御機能が、すべてCloudFormation経由で利用可能になります。

  • Launch-before-Terminate(先起動・後終了): サービス容量(キャパシティ)を削減することなく、先に新しいインスタンスを起動してから、古いインスタンスを順次終了します。これにより、デプロイ中の負荷耐性を維持できます。
  • ルートボリューム置換(Replace Root Volume): インスタンス自体を完全に再作成する代わりに、OSやアプリケーションが格納されたルートボリュームのみをインプレースで置き換えることで、更新処理を劇的に高速化します。
  • アラームベースの監視(Alarm-based Monitoring): 指定したCloudWatchアラームをデプロイ中に監視し、エラー率の上昇などを検知した場合に自動でアップデートを停止・ロールバックできます。
  • チェックポイントとベイク時間(Bake Time): 「まず10%のインスタンスを更新し、1時間様子を見る(ベイクする)」といった段階的なカナリアリリースのようなデプロイ制御が可能です。
  • Auto Scaling機能の継続稼働: デプロイ中であっても、ASGのスケーリングポリシーやヘルスチェックは有効なまま維持されるため、トラフィックの急増にも柔軟に対応できます。

設定例(CloudFormation YAMLテンプレート)

この機能を利用するための、CloudFormationテンプレートでの設定例を紹介します。UpdatePolicy セクションに AutoScalingInstanceRefresh を定義します。

Resources:
  MyAutoScalingGroup:
    Type: AWS::AutoScaling::AutoScalingGroup
    Properties:
      AutoScalingGroupName: "my-asg"
      MinSize: "2"
      MaxSize: "10"
      DesiredCapacity: "4"
      LaunchTemplate:
        LaunchTemplateId: !Ref MyLaunchTemplate
        Version: !GetAtt MyLaunchTemplate.LatestVersionNumber
      VPCZoneIdentifier:
        - !Ref SubnetA
        - !Ref SubnetB
    UpdatePolicy:
      AutoScalingInstanceRefresh:
        Preferences:
          MinHealthyPercentage: 50
          InstanceWarmup: 300
          CheckpointPercentages: [25, 50, 100]
          CheckpointDelay: 600 # 10分のベイク時間
          SkipMatching: true
          AlarmSpecification:
            Alarms:
              - !Ref MyDeploymentCloudWatchAlarm

想定されるユースケース

  • ミッションクリティカルなWebアプリケーションのゼロダウンタイムデプロイ: Launch-before-Terminate を有効にすることで、デプロイ中も常に100%以上のサービス容量を維持しながら、安全にAMIを更新できます。
  • 本番環境でのカナリアリリース: CheckpointPercentagesCheckpointDelay を組み合わせ、段階的に新バージョンをデプロイし、CloudWatchアラームでエラーが起きないことを確認しながらリリースを進行させます。
  • 大規模なASGの高速パッチ適用: Replace Root Volume を活用して、数百台規模のASGインスタンスのOSパッチ適用を、インスタンスのプロビジョニング時間をカットして高速に完了させます。

注意点や従来の機能(AutoScalingRollingUpdate)との違い

1. 制御の主体が「CloudFormation」から「EC2 Auto Scaling」へ

従来の AutoScalingRollingUpdate は、CloudFormationが主体となって1台ずつインスタンスの追加・削除を指示していました。そのため、進行状況の可視性や柔軟な制御に限界がありました。

今回の AutoScalingInstanceRefresh では、CloudFormationは「インスタンスリフレッシュの開始」をEC2 Auto Scalingサービスに指示するだけです。実際の複雑なローリングデプロイやヘルスチェック、ボリューム置換などは、EC2 Auto Scalingの高度なネイティブ機能が自律的に実行します。

2. ロールバックの統合

デプロイ中に問題が発生した場合(CloudWatchアラームの検知など)、EC2 Auto Scalingは自動的にリフレッシュを停止します。この際、CloudFormationスタックのロールバックと連携して、安全に元の状態(以前の起動テンプレートやAMI)へスタック全体がロールバックされます。

まとめ

今回のアップデートにより、CloudFormationを利用したインフラ運用の安全性とデプロイの柔軟性が大幅に向上しました。特に本番環境でEC2 Auto Scalingを運用しているチームにとって、待望の機能と言えます。

従来の AutoScalingRollingUpdate を利用しているテンプレートがあれば、ぜひこの機会に AutoScalingInstanceRefresh への移行を検討し、より高度で安全なモダンデプロイパイプラインを構築しましょう!

上部へスクロール