EC2 Application Status Checks не равны system check: матрица endpoint, security group и Auto Scaling. На одном canary instance создать минимальный health path без данных, указать port, IP version, timeout, status matcher и пороги; позволить вход от source security group, зафиксировать healthy, затем на коротком тесте вернуть контрольный код и доказать.
1. Зафиксируйте точный симптом и границу ответа
EC2 instance и system status показывают OK, но приложение не отвечает; новый application status check может проверять HTTP/HTTPS path, но ошибочный matcher, firewall или Auto Scaling integration могут вызвать ложную замену здорового instance. Рабочая граница материала — именно запрос «как настроить ec2 application status checks для http https path security group и auto scaling и отличить от system instance status». До любого действия запишите версию, один наблюдаемый симптом, время и ожидаемый результат. Не переносите вывод на другую версию, роль, операционную систему или соседний продукт без повторной сверки. Новостная карточка или форумное обсуждение могут быть лишь lead: они не доказывают причину, охват или популярность.
2. Отделите свежее событие от технического доказательства
10 августа 2026 года AWS объявил EC2 Application Status Checks во всех Regions; 28 августа whats-new и текущая EC2-документация сверены: проверки идут раз в 60 секунд по HTTP/HTTPS, а HTTPS-режим не валидирует сертификат сервера. Первый источник фиксирует: AWS What's New от 10 августа 2026 года объявляет EC2 Application Status Checks для выявления проблем на уровне приложения, разделяя их с system и instance status, и указывает доступность во всех AWS Regions. Второй официальный контракт уточняет: Официальная EC2-документация разделяет system, instance, attached EBS и application checks; для application check она указывает HTTP/HTTPS path, 60-секундный интервал, status matcher, network prerequisites и факт отсутствия валидации server certificate в HTTPS-проверке. Из этих двух текстов не следует, что любой похожий симптом вызван тем же механизмом. Дата, версия, область действия и оговорки источника остаются частью ответа.
3. Проведите один обратимый контрольный тест
На одном canary instance создать минимальный health path без данных, указать port, IP version, timeout, status matcher и пороги; позволить вход от source security group, зафиксировать healthy, затем на коротком тесте вернуть контрольный код и доказать impaired без Auto Scaling replacement. До теста сохраните исходное значение или копию только затрагиваемого объекта, заранее определите признак успеха, отрицательный исход и команду возврата. Меняйте ровно один фактор и повторяйте тот же контрольный вход. Не сбрасывайте профиль, не удаляйте данные, не отключайте защиту и не подменяйте сетевой маршрут ради удобного результата.
4. Прочитайте матрицу исходов без подмены причины
Матрица «system/instance/application check × path/port × status matcher × SG/firewall × Auto Scaling action», обратимый синтетический failure на одном canary, отдельная TLS-проверка и стоп-линия до связывания с автоматической заменой. Сначала разделяют отказ приложения, недоступность порта, ошибочный matcher и expected downtime; HTTPS application check не подтверждает валидность TLS-сертификата, поэтому этот риск проверяется другим контролем. В каждой ячейке записывайте только наблюдаемый факт, а не предполагаемую причину. Если симптом исчез, это подтверждает границу контрольного теста, но не универсальную причину для всех конфигураций. Если результат неоднозначен, верните исходное состояние и соберите минимальный воспроизводимый пример.
5. Остановитесь до необратимого шага и эскалируйте минимум
Не подключать Auto Scaling replacement до контрольного failure/recovery, не открывать health port всем адресам и не считать HTTPS check заменой certificate monitoring; при ложном impaired сначала отвязать автодействие. Для поддержки соберите версию продукта, время с timezone, один обезличенный код ошибки или статус, один контрольный шаг и его результат. Удалите имена, email, IP, account IDs, tokens, ключи, полные конфиги и приватные ссылки. Красные флаги для немедленной остановки: потеря данных, секрета или доступа, влияние на несвязанных пользователей, отсутствие копии или невозможность возврата.
Материал подготовлен редакцией VOne с помощью ИИ; технические утверждения постатейно сверены с указанными официальными и первичными источниками 28 августа 2026 года.
Источники и проверка
- AWS EC2 Application Status Checks announcement проверено 2026-08-28
- EC2 application status checks documentation проверено 2026-08-28
Информация актуальна на дату публикации. Правила сервисов, приложений и сетей могут меняться.