한 회사에서 IaC를 사용하여 수년간 변경되지 않은 두 개의 EC2 인스턴스를 생성했습니다. 급격한 비즈니스 성장으로 인해 운영팀은 스파이크 발생 시 인스턴스를 교체하는 Auto Scaling 그룹을 도입했습니다. 회사 정책에 따라 매월 OS 보안 업데이트를 수행해야 하며, 이로 인해 재부팅이 필요할 때도 있습니다. 최근 재부팅이 필요한 패치 적용 후, Auto Scaling 그룹은 패치된 인스턴스를 종료하고 패치되지 않은 새 인스턴스를 시작했습니다. 솔루션스 아키텍트는 이러한 상황이 다시 발생하지 않도록 어떤 조치 조합을 권장해야 할까요? (두 가지 선택)

Auto Scaling 그룹은 새 인스턴스를 시작할 때 항상 최신 시작 구성 또는 시작 템플릿을 사용합니다. 인스턴스 새로 고침을 사용하면 Auto Scaling 그룹이 기존 인스턴스를 새 시작 구성/템플릿을 사용하는 새 인스턴스로 점진적으로 교체할 수 있습니다. AMI 패치를 자동화하고, 패치된 AMI로 시작 구성을 업데이트한 다음, Auto Scaling 인스턴스 새로 고침을 호출하는 스크립트를 생성하면 패치된 인스턴스가 유지되도록 할 수 있습니다. "Auto Scaling 그룹의 업데이트 정책을 수정하여 가장 오래된 시작 구성을 교체 대상으로 지정합니다"는 잘못된 설명입니다. Auto Scaling 그룹에는 "업데이트 정책"이라는 개념이 없으며, 시작 구성을 교체 대상으로 지정하는 옵션도 없습니다. "두 번째 Auto Scaling 그룹을 생성합니다"는 복잡성을 증가시키고 수동 개입이 필요하므로 확장 가능한 솔루션이 아닙니다. "Elastic Load Balancer를 배치하고 대상 그룹 상태 확인을 구성합니다"는 인스턴스 상태를 모니터링하지만, 패치되지 않은 인스턴스가 시작되는 문제를 해결하지 못합니다. "Elastic Load Balancer를 배치하고 개별 인스턴스에 종료 보호를 활성화합니다"는 Auto Scaling 그룹의 목적에 어긋나며, 종료 보호는 Auto Scaling 그룹이 인스턴스를 교체하는 것을 방해합니다.