Начните с вашей рабочей нагрузки, а не с тарифного плана
Составьте список путей, которые приносят ценность или риск: первый визит, поиск, вход, страница товара, отправка формы, оформление заказа, обновление в редакторе или API‑вызов. Для каждого укажите пиковые запросы или одновременных пользователей, объём полезных данных (payload), персонализацию, зависимости и регионы посетителей. Включите плановые и административные задания — они потребляют те же ресурсы.
Преобразуйте список в критерии приёмки. Largest Contentful Paint, или LCP, измеряет загрузку основного содержимого; Interaction to Next Paint, или INP, — отзывчивость; а Cumulative Layout Shift, или CLS, — неожиданное смещение макета. Google приводит ориентиры: LCP в пределах 2.5 секунд, INP ниже 200 миллисекунд и CLS ниже 0.1. Добавьте целевые показатели завершения маршрута, времени ответа сервера и уровня ошибок.
Не позволяйте быстрой закэшированной странице заменить аутентифицированную или транзакционную операцию с базой данных.
Определите пиковый период, ожидаемый рост, всплески кампаний и пересечения пакетной работы.
Укажите, контролирует ли потенциальный узкий горлышко хост, ваша команда или третья сторона.
Сравните ёмкость, ограничения и поведение масштабирования
Запросите ограничения, скрытые за предложением: ресурсы вычислений и памяти, производительность хранения, соединения с базой данных, лимиты воркеров, сетевые ограничения, плата за трафик, механизмы управления запросами и влияние соседних пользователей на общей платформе. «Неограниченный трафик» сам по себе не говорит, выдержит ли приложение достаточную некэшированную нагрузку в пик. Спросите, какие метрики видны и как долго они хранятся.
Масштабирование важно только когда известны триггер, задержка, потолок и стоимость. Уточните, автоматическое ли оно, сохраняются ли сессии и задания, и что происходит при достижении потолка. Предпочтительнее тест у ожидаемого пика и выше, чем теоретическое утверждение о мощности. Запас потока — это бизнес‑решение, а не универсальный процент.
Сравнивайте p95 или p99 времени отклика, а не только среднее.
Собирайте тайминги базы данных, очередей и внешних API во время теста.
Оцените расходы на масштаб, доставку, резервное копирование и второй регион до заключения сделки.
Размещайте origin осознанно и валидируйте доставку
Выберите регион origin, исходя из местонахождения аудитории, зависимостей приложения, требований к размещению данных и операционного доступа. Тестируйте из репрезентативных географий и сетевых условий. CDN (сеть доставки контента) — распределённый кэш, который может обслуживать подходящие ресурсы ближе к посетителям и снизить нагрузку на origin; это не замена здорового origin, базы данных или приложения.
Проверяйте заголовки и поведение, а не только настройку в панели. Версионированные статические ресурсы обычно можно хранить дольше, потому что обновление меняет URL. Динамические и персонализированные ответы требуют явных правил. HTTP различает общие и приватные кэши; данные аккаунта не должны становиться доступны другим клиентам. Отрепетируйте очистку кэша и откат.
Фиксируйте первый визит и повторный, потому что состояние кэша отличается.
Проверьте Cache‑Control и ключи кэша для страниц, ресурсов, cookie, параметров и локализации.
Документируйте, как уполномоченный персонал отключает вредное правило без раскрытия чувствительного контента.
Рассматривайте доказательства восстановления как требование к производительности
Уточните, что именно резервируется, где хранятся копии, сроки хранения, кто имеет право на восстановление и покрывают ли бэкапы базы данных, загруженные файлы, код, конфигурации и инфраструктуру. Определите RPO (recovery point objective) — допустимую потерю данных во времени, и RTO (recovery time objective) — допустимое время восстановления. Устанавливайте обе величины, исходя из бизнес‑последствий, а не из стандартного пакета.
Успешное создание резервной копии не равно проверке восстановления. CISA рекомендует регулярные плановые тесты восстановления, а AWS указывает на необходимость оценки и тестирования аварийного восстановления. Восстановите недавнюю копию в изолированной среде, проверьте важные записи и медиа, выполните документацию последовательности действий и зафиксируйте затраченное время. Альтернативный регион снижает некоторые риски, но добавляет расходы и сложность.
Восстановите один файл или запись без перезаписи текущих данных.
Ограничьте доступ на восстановление и держите учетные данные и руководства по процедурам доступными для уполномоченных ответственных лиц.
Снимок базы данных может не воспроизвести настройки, версии приложения или правила доставки.
Оцените поддержку и модель совместной ответственности до того, как она понадобится
Сравните объём поддержки, часы работы, каналы, эскалации и различие между платформенными инцидентами и отладкой приложения. Получите чётко прописанную ответственность за патчи, управляемые базы данных, TLS, правила брандмауэра, бэкапы и восстановление. Обещание поддержки полезно, если в нём названы владелец и следующий шаг в реалистичном сценарии.
Проверьте роли доступа, многофакторную аутентификацию, журналы аудита, обработку секретов и изоляцию аккаунтов. Для карт оплаты или других чувствительных данных возможности хостинга сами по себе не обеспечивают соответствие требованиям. Используйте это сравнение как технический вход и привлекайте квалифицированную экспертизу по безопасности, юриспруденции или комплаенсу для проверки архитектуры платёжных систем и применимых обязательств.
Спросите, как провайдер поступит при неудавшемся восстановлении, насыщенной базе данных или вредном кэш‑правиле.
Проверьте, кто может изменять продукцию, читать бэкапы, просматривать логи и создавать учётные данные.
Сервисные кредиты и зоны управляемого покрытия могут иметь существенные условия.
Проводите реалистичные, безопасные сравнивающие тесты и ведите таблицу оценки
Используйте один и тот же релиз, намерение конфигурации и тестовый сценарий для каждого кандидата. Прогоните базовый тест, ожидаемый пик, кратковременный всплеск, устойчивый период и безопасную проверку восстановления или упражнение по деплою. AWS рекомендует среды, похожие на продакшен, определённые сценарии, мониторинг всей архитектуры, обезличенные или синтетические данные и регулярное ретестирование. Получите одобрение провайдера и соблюдайте его политику тестирования.
Комбинируйте лабораторные контролируемые тесты с полевыми данными после запуска. Лабораторные тесты повторяемы и удобны для отладки; полевые данные отражают реальные устройства, сети, географию, состояние кэша и поведение пользователей. Пересматривайте таблицу оценки после крупных релизов или изменения зависимостей. SIU может преобразовать выводы в проактивное усиление до релиза, назначенные владельцем исправления и готовые к откату улучшения.
Сохраняйте одинаковые локации, конкуренцию, состояние кэша и полезные нагрузки.
Сохраняйте тайминги маршрутов, ошибки, метрики ресурсов, версии, затраты и наблюдения.
Отдавайте предпочтение варианту, который отвечает документированным требованиям при устойчивой стоимости эксплуатации.