Справочник

Трехуровневое приложение: веб, приложение, БД. БД должна быть недоступна из интернета ни при каких обстоятельствах.

→Публичные подсети для веб-уровня (ALB). Приватные подсети для уровня приложений и уровня БД. Группа безопасности БД разрешает трафик только из группы безопасности уровня приложений (не из диапазонов CIDR).

Почему: Таблицы маршрутизации подсетей обеспечивают достижимость; ссылки между группами безопасности кодируют принцип наименьших привилегий на уровне SG и сохраняются при изменении IP-адресов.

Источник↗

Экземпляру EC2 требуется доступ к S3. Избегайте встроенных учетных данных.

→Роль IAM, прикрепленная через профиль экземпляра. SDK извлекает временные учетные данные из IMDSv2.

Почему: Долгоживущие ключи доступа на экземплярах являются главной причиной утечки учетных данных. Роли автоматически ротируются, никогда не сохраняются.

Источник↗

Блокировать атаки SSRF, пытающиеся читать метаданные экземпляра EC2.

→Обеспечить IMDSv2 (`HttpTokens=required`) при запуске экземпляра. Отклонять неаутентифицированные запросы IMDSv1.

Почему: IMDSv2 требует токен сессии через PUT перед ответом конечной точки метаданных; атаки SSRF, выполняющие только GET-запросы, блокируются.

Источник↗

Сервис A в аккаунте A вызывает Lambda в аккаунте B. Наименьшие привилегии.

→Политика на основе ресурсов в целевой Lambda, предоставляющая `lambda:InvokeFunction` роли-сущности аккаунта A. Вызывающий принимает на себя свою собственную роль и вызывает напрямую — не требуется цепочка ролей.

Почему: Политики ресурсов — это самый простой шаблон меж-аккаунтного взаимодействия для ресурсов, ориентированных на сервисы (Lambda, S3, SNS, SQS, KMS).

Источник↗

Другие аккаунты AWS должны загружать данные в центральный S3-бакет.

→Политика бакета, предоставляющая `s3:PutObject` внешним аккаунтным сущностям. Добавить требование ACL `bucket-owner-full-control`, чтобы владелец бакета сохранял контроль над объектами.

Почему: Без `bucket-owner-full-control` (или `BucketOwnerEnforced` Object Ownership) загруженные объекты принадлежат аккаунту-загрузчику.

Источник↗

Предотвратить публичный доступ к любому S3-бакету в организации.

→Включить S3 Block Public Access на уровне аккаунта (и для всей организации через SCP). Это переопределяет ACL и политики на уровне бакета.

Почему: Настройка на уровне аккаунта имеет приоритет над настройками для отдельных бакетов — защита от случайной неправильной конфигурации.

Источник↗

Разработчики должны самостоятельно создавать роли IAM, но не могут предоставлять разрешения, выходящие за рамки определенного максимального набора.

→Границы разрешений (Permission boundaries) для сущности разработчика. Эффективные разрешения = политика идентификации ∩ граница.

Почему: SCP применяются на уровне аккаунта/OU; границы определяют область действия для отдельных сущностей. Используйте границы для делегированных административных шаблонов.

Источник↗

Ограничить OU определенными регионами для соответствия требованиям к резидентности данных.

→Политика управления сервисами (SCP) в Organizations, запрещающая любое действие, если `aws:RequestedRegion` отсутствует в разрешенном списке.

Почему: SCP — это единственный механизм, который может запрещать действия, разрешенные самим аккаунтом. IAM не может запретить то, что может предоставить root-аккаунт.

Источник↗

Единый вход для сотрудников в нескольких аккаунтах AWS; интеграция с корпоративным IdP.

→AWS IAM Identity Center (ранее AWS SSO) с федерацией SAML/OIDC к корпоративному IdP. Наборы разрешений сопоставляются с ролями в членских аккаунтах.

Почему: Identity Center — это каноническое решение для многоаккаунтной идентификации сотрудников. Cognito предназначен для конечных пользователей приложений, а не для сотрудников.

Источник↗

Выбрать Cognito User Pool или Identity Pool.

→User Pool = регистрация / вход / выдача JWT для пользователей приложения. Identity Pool = обмен токенов на временные учетные данные AWS. Большинство приложений используют оба: User Pool аутентифицирует, Identity Pool авторизует доступ к AWS.

Источник↗

Добавить настраиваемый шаг проверки в процесс входа Cognito (например, домен электронной почты из белого списка).

→Триггеры Lambda: Pre Sign-up, Pre Authentication, Define/Create/Verify Auth Challenge. Проверить или отклонить в Lambda.

Источник↗

Требуется полный контроль над ротацией ключей, удалением и журналом аудита для каждого ключа.

→Ключ KMS, управляемый клиентом (CMK). Ключи, управляемые AWS (`aws/<service>`), проще, но не предлагают контроля над политиками ключей или видимости использования отдельных ключей.

Почему: CMK позволяют ограничивать доступ к каждому ключу в CloudTrail, устанавливать политики ключей для использования между аккаунтами, а также отключать/планировать удаление.

Источник↗

Аккаунту B нужно расшифровать объекты S3, зашифрованные с помощью CMK аккаунта A.

→Политика ключа на CMK предоставляет `kms:Decrypt` сущностям аккаунта B. IAM аккаунта B также требуется `kms:Decrypt` для ARN ключа. Требуются обе части.

Почему: KMS cross-account требует явного разрешения как в политике ключа, так и в IAM-идентификаторе вызывающего (в отличие от большинства политик ресурсов).

Источник↗

Зашифровать данные в `us-east-1`; расшифровать в `us-west-2` после репликации, без повторного шифрования.

→Мультирегиональный ключ KMS. Основной в одном регионе, реплика в другом, оба с одним и тем же ключевым материалом и ID.

Почему: Избегает сложной процедуры перешифрования шифротекста для межрегионального аварийного переключения или DR.

Источник↗

Шифровать большие объекты без чрезмерных затрат на вызовы API KMS для каждого объекта.

→Конвертное шифрование. KMS генерирует ключ данных (один вызов API); использовать ключ данных для локального шифрования полезной нагрузки; хранить зашифрованный ключ данных вместе с шифротекстом.

Почему: KMS имеет ограничения по скорости и тарифицируется за запрос. Шаблон конвертного шифрования — это канонический способ шифрования данных размером > нескольких КБ.

Источник↗

Выбрать Secrets Manager или SSM Parameter Store SecureString.

→Учетные данные БД с автоматической ротацией, совместное использование между аккаунтами, большие секреты → Secrets Manager. Флаги конфигурации, настройки приложений, простые секреты, минимальная стоимость → SSM Parameter Store.

Почему: Secrets Manager имеет встроенные Lambda для ротации RDS/Aurora/DocumentDB/Redshift; Parameter Store не имеет нативной ротации, но бесплатен для уровня Standard.

Источник↗

Автоматически ротировать пароль RDS каждые 30 дней.

→Secrets Manager с управляемой ротацией. Встроенный шаблон Lambda обрабатывает ротацию одного пользователя против конечной точки RDS. Приложения получают секрет во время подключения (кешируется) — без повторного развертывания приложения.

Источник↗

Смягчить атаку HTTP-флуда Layer 7 без блокировки легитимных всплесков.

→Правило AWS WAF на основе скорости (например, 2000 запросов / 5 мин на IP) на ALB или CloudFront. Объединить с управляемыми группами правил для известных плохих IP.

Почему: Правила скорости WAF отслеживают по исходному IP; автоматически блокируют при превышении порога; снимают блокировку после окончания окна.

Источник↗

Критически важное приложение нуждается в защите от DDoS-атак и круглосуточной поддержке SRT.

→AWS Shield Advanced на CloudFront / ALB / NLB / Global Accelerator. Включает защиту от затрат (возмещение расходов на масштабирование во время атаки) + доступ к команде Shield Response Team.

Почему: Shield Standard автоматический и бесплатный; Advanced добавляет защиту и SLA. CloudFront всегда рекомендуется в качестве основного входного шлюза.

Источник↗

Выбрать группу безопасности (security group) или NACL.

→Stateful, прикрепляется к ENI, только разрешение → группа безопасности (по умолчанию). Stateless, на уровне подсети, разрешение + явный запрет → NACL. Используйте NACL для общих правил запрета (блокировка диапазонов IP); SG для всего остального.

Почему: NACLs оценивают входящий и исходящий трафик отдельно. SG автоматически разрешают обратный трафик.

Источник↗

EC2 в приватной подсети должен достигать S3/DynamoDB без затрат на NAT-исходящий трафик.

→VPC Gateway Endpoint для S3 и DynamoDB. Бесплатно, запись в таблице маршрутизации, без NAT.

Почему: Gateway Endpoints предназначены только для S3/DynamoDB. Экономит плату за обработку данных NAT и сохраняет трафик в магистрали AWS.

Источник↗

Приватная подсеть должна приватно достигать API сервисов AWS (KMS, Secrets Manager, ECR и т. д.).

→VPC Interface Endpoint (PrivateLink) для каждого сервиса. ENI в вашем VPC, оплачивается за час + за ГБ.

Почему: Interface Endpoints работают практически для каждого сервиса AWS. Используйте для устранения исходящего трафика NAT для вызовов сервисов.

Источник↗

SaaS-провайдер предоставляет свой сервис внутри VPC аккаунтам клиентов приватно, без VPC-пиринга и без поддержания маршрутизации клиентов.

→Сервис конечных точек AWS PrivateLink, поддерживаемый NLB. Клиенты создают Interface Endpoints для потребления.

Почему: Нет проблем с пересечением CIDR, нет пирингового мешинга, односторонняя экспозиция (провайдер не видит трафик клиентов).

Источник↗

Соединить 30+ VPC между аккаунтами и локальными средами в топологии "звезда".

→AWS Transit Gateway. Одно присоединение на VPC; таблицы маршрутизации сегментируют трафик.

Почему: Полностью связанный пиринг требует N×(N-1)/2 подключений. TGW масштабируется линейно и поддерживает меж-аккаунтное взаимодействие через RAM.

Источник↗

Гибридное подключение, требующее предсказуемой пропускной способности, низкой задержки и шифрования.

→Direct Connect с Site-to-Site VPN поверх DX (MACsec или IPsec). Сам по себе DX нешифрован; VPN поверх DX приватен + зашифрован + имеет низкий джиттер.

Почему: Обычный VPN через интернет дешев, но имеет переменную задержку. Один DX быстр, но передает данные в открытом виде на канальном уровне.

Источник↗

Непрерывное обнаружение угроз по VPC Flow Logs, DNS, CloudTrail, аудиту EKS, событиям данных S3.

→Amazon GuardDuty. Для всей организации через делегированного администратора Organizations.

Почему: Управляемое обнаружение угроз. Обнаружения передаются в Security Hub или EventBridge для автоматизации реагирования.

Источник↗

Обнаружение и классификация PII / PHI в S3-бакетах.

→Amazon Macie. Обнаружение конфиденциальных данных на основе ML, с областью действия S3, интегрируется с Security Hub.

Источник↗

Непрерывное сканирование CVE для EC2, образов ECR, функций Lambda.

→Amazon Inspector v2. Автоматически обнаруживает ресурсы через Systems Manager Agent, сканирует на предмет опубликованных CVE.

Источник↗

Агрегировать обнаружения из GuardDuty, Inspector, Macie, IAM Access Analyzer в одну панель управления.

→AWS Security Hub. CSPM с AWS Foundational Security Best Practices и стандартами CIS.

Источник↗

Обеспечить шифрование всех томов EBS; автоматически исправлять несоответствующие ресурсы.

→Правила AWS Config (управляемые `encrypted-volumes`) + runbook Systems Manager Automation для исправления, запускаемые через действие исправления Config.

Источник↗

Единый, защищенный от подделок журнал аудита для всех аккаунтов в организации.

→Организационный журнал (Organization trail) с включенной проверкой файлов журналов, записываемый в центральный S3-бакет с политикой бакета, запрещающей удаление.

Почему: Организационные журналы автоматически включаются во всех членских аккаунтах (текущих и будущих). Хеши проверки доказывают, что журналы не были изменены.

Источник↗

Нескольким отделам требуется ограниченный доступ к различным префиксам в общем S3-бакете.

→Точки доступа S3 (S3 Access Points) — по одной на отдел, каждая со своей собственной политикой доступа и (опционально) ограничением VPC.

Почему: Чище, чем разветвленная политика бакета; точки доступа имеют свои собственные ARN и имена DNS.

Источник↗

Рабочая нагрузка PCI DSS — строгая изоляция от аккаунтов, не относящихся к PCI.

→Выделенный аккаунт AWS внутри OU в Organizations с SCP, ограничивающими доступ к сервисам/регионам. Отдельные VPC, ключи KMS, роли IAM. Network Firewall или GWLB для проверки исходящего трафика.

Почему: Граница аккаунта — это сильнейшая изоляция зоны поражения в AWS.

Источник↗

Публичный TLS-сертификат для `*.example.com` на ALB и CloudFront. Автоматическое продление.

→Публичный сертификат AWS Certificate Manager (ACM) с DNS-валидацией в Route 53. Автоматически продлевается за 60 дней до истечения срока действия.

Почему: Бесплатно для использования с интегрированными сервисами AWS. Проверка по электронной почте работает, но для автоматизации предпочтительна проверка DNS.

Источник↗

Продакшн-база данных RDS с переключением на резервный сервер менее чем за минуту.

→Развертывание RDS Multi-AZ (или Multi-AZ DB Cluster). Синхронная репликация на резервный сервер; автоматическое переключение с помощью смены DNS-конечной точки.

Почему: Multi-AZ предназначен для обеспечения высокой доступности, а не для масштабирования чтения. Реплики чтения предназначены для масштабирования чтения (и асинхронны; возможна задержка).

Источник↗

Выбрать Aurora или RDS для новой рабочей нагрузки MySQL/PostgreSQL.

→Aurora для более высокой пропускной способности, более быстрого переключения, до 15 реплик для чтения, Global Database, Serverless v2. RDS для старых движков (MariaDB, Oracle, SQL Server) или более простых/дешевых развертываний.

Почему: Хранилище Aurora совместно используется между репликами (нет задержки репликации от хранилища). Переключение обычно < 30 секунд.

Источник↗

Активно-пассивная многорегиональная база данных с задержкой репликации < 1 с и RTO < 1 мин.

→Aurora Global Database. Репликация на уровне хранилища до 5 вторичных регионов; повышение вторичного до первичного в случае катастрофы.

Почему: Репликация использует выделенную инфраструктуру; задержка между регионами обычно < 1 с. Реплики чтения в удаленных регионах для локального чтения с низкой задержкой.

Источник↗

Переменная / непредсказуемая нагрузка на базу данных с периодами простоя.

→Aurora Serverless v2. Масштабируется с шагом 0,5 ACU; события масштабирования менее чем за секунду; нет полной паузы, но очень низкий минимум.

Почему: v2 сохраняет соединение открытым во время событий масштабирования (в отличие от v1). Оплата за ACU-секунду.

Источник↗

Чтение + запись в 3+ регионах с задержкой в единицы мс, с репликацией "последний писатель побеждает".

→DynamoDB Global Tables. Мультиактивная репликация с разрешением конфликтов по принципу "последний писатель побеждает".

Почему: Активно-активная работа в каждом регионе; без лидера. Используйте, когда допустима толерантность к конфликтам на уровне приложения.

Источник↗

Восстановить таблицу DynamoDB до определенного момента за последние 35 дней после случайного удаления.

→Включить восстановление на определенный момент времени (PITR). Восстановление создает новую таблицу в выбранную секунду.

Источник↗

Маршрутизировать трафик в основной регион; переключаться на вторичный при сбое проверки работоспособности.

→Политика маршрутизации Route 53 с переключением при сбое. Активная проверка работоспособности на основной конечной точке; вторичная запись обслуживает, когда основная неработоспособна.

Почему: Проверка работоспособности на уровне приложения (HTTP-путь) обнаруживает частичные сбои, которые пропускают TCP-зонды.

Источник↗

Отправлять каждого пользователя в регион с наименьшей задержкой и работоспособностью.

→Маршрутизация Route 53 на основе задержки. Проверка работоспособности каждой конечной точки; Route 53 возвращает наиболее работоспособный ответ с наименьшей задержкой для каждого запроса.

Источник↗

Канареечный запуск: отправить 10% на v2, 90% на v1.

→Взвешенная маршрутизация Route 53. Две записи с одинаковым именем, разными целями, весами 10 и 90.

Источник↗

Инициализация экземпляров EC2 занимает 3 минуты; масштабирование слишком медленное во время всплесков трафика.

→Пул "теплого" запуска Auto Scaling (Warm pool). Предварительно инициализированные экземпляры находятся в остановленном состоянии (дешевле) и готовы к запуску за считанные секунды.

Почему: Холодный запуск + загрузка — это узкое место. Warm pool перемещает эту работу за пределы критического пути.

Источник↗

При масштабировании уменьшения, завершить выполняющиеся работы и сохранить логи до завершения работы экземпляра.

→Хук жизненного цикла Auto Scaling в `Terminating:Wait`. Хук публикует в SNS/EventBridge; обработчик завершает опустошение и вызывает `complete-lifecycle-action`.

Источник↗

Сократить затраты на вычисления для некритичной группы, которая терпима к прерываниям.

→ASG с политикой смешанных экземпляров: базовая емкость на On-Demand, дополнительная емкость на Spot, несколько типов экземпляров и AZ для диверсификации.

Почему: Диверсификация по типам экземпляров снижает риск прерывания Spot по сравнению с использованием одного пула.

Источник↗

Выбрать ALB или NLB.

→HTTP/HTTPS, маршрутизация по пути/хосту, интеграция с WAF, OIDC-аутентификация → ALB. TCP/UDP/TLS при экстремальном масштабе, статический IP на AZ, минимальная задержка, сохранение исходного IP клиента → NLB.

Источник↗

Встроить сторонний набор устройств безопасности для инспекции трафика между VPC.

→Gateway Load Balancer (GWLB) с набором устройств в качестве целей. Трафик инкапсулируется через GENEVE; прозрачная вставка через маршрутизацию.

Источник↗

Проблемные сообщения постоянно вызывают сбои обработчиков и ставятся в очередь повторно.

→Очередь "мертвых" сообщений SQS (Dead-Letter Queue). Настроить `maxReceiveCount` для исходной очереди; сообщения, превышающие это количество, перемещаются в DLQ для проверки.

Источник↗

Строгий порядок и обработка точно один раз для каждой группы сообщений.

→Очередь SQS FIFO с дедупликацией на основе содержимого или явным `MessageDeduplicationId`. Используйте `MessageGroupId` для параллельных упорядоченных групп.

Почему: Стандартный SQS обеспечивает обработку "хотя бы один раз" без гарантии порядка. FIFO имеет более низкую пропускную способность, если не используется режим высокой пропускной способности.

Источник↗

Асинхронная Lambda завершается по тайм-ауту нижестоящего сервиса — перехватить неудавшиеся события для повторного воспроизведения.

→Lambda Destinations: настроить место назначения при сбое как SQS / SNS / EventBridge / другую Lambda. Поддерживаются также места назначения при успехе.

Почему: Чище, чем DLQ на функции: места назначения получают полный полезный груз события + ответа; DLQ получают только событие триггера.

Источник↗

Многошаговый рабочий процесс требует повторной попытки для каждой задачи с экспоненциальной задержкой и перехватом ошибок.

→Стандартный рабочий процесс AWS Step Functions. Блок `Retry` с `IntervalSeconds`, `MaxAttempts`, `BackoffRate`. Блок `Catch` маршрутизирует конкретные ошибки в состояние восстановления.

Источник↗

Origin CloudFront (S3 или ALB) выходит из строя — переключиться на вторичный origin без изменений DNS.

→Группа origins CloudFront с первичным + вторичным. Настроить критерии переключения при сбое (коды 4xx/5xx). CloudFront повторяет запрос к вторичному.

Источник↗

Централизовать резервное копирование для EBS, RDS, DynamoDB, EFS, FSx с одной политикой хранения.

→AWS Backup с планами резервного копирования + выбор ресурсов по тегам. Поддерживается копирование между аккаунтами / регионами. Vault Lock для неизменяемости в целях соответствия требованиям.

Источник↗

Резервные копии, устойчивые к вымогателям: даже администратор не может удалить их до истечения срока хранения.

→AWS Backup Vault Lock в режиме соответствия. Принудительное WORM (Write Once, Read Many); даже root не может сократить срок хранения.

Источник↗

Выбрать шаблон DR в соответствии с требованиями RPO/RTO.

→Backup & Restore: RPO часы, RTO часы, самый дешевый. Pilot Light: RPO минуты, RTO десятки минут. Warm Standby: RPO секунды, RTO минуты. Multi-Site Active-Active: RPO ~ноль, RTO секунды, самый дорогой.

Источник↗

Реплицировать критически важный бакет между регионами для DR с RPO менее 15 минут.

→S3 Cross-Region Replication (CRR) с S3 Replication Time Control (RTC). 99,99% объектов за 15 минут.

Почему: Стандартный CRR является best-effort. RTC добавляет SLA + метрики репликации в CloudWatch.

Источник↗

Защитить объекты S3 от случайного удаления и перезаписи программами-вымогателями.

→Включить S3 Versioning + MFA Delete + Object Lock (режим governance или compliance) на критически важных бакетах.

Почему: Версионирование сохраняет перезаписи/удаления; Object Lock блокирует удаление до истечения срока хранения; MFA Delete добавляет второй фактор для окончательного удаления.

Источник↗

Глобальному приложению требуется аварийное переключение с RTO = ноль между двумя регионами.

→Активно-активная конфигурация между регионами: Global Accelerator или маршрутизация Route 53 на основе задержки для входящего трафика; DynamoDB Global Tables / Aurora Global Database для данных; межрегиональная репликация для хранилищ объектов.

Источник↗

Трафик TCP/UDP с низким джиттером в ближайший работоспособный регион; статические Anycast IP.

→AWS Global Accelerator. Два Anycast IP; маршрутизирует к ближайшей конечной точке через магистраль AWS.

Почему: Лучше, чем задержка Route 53 для не-HTTP. Более быстрое аварийное переключение (Anycast) + статическая IP-адресация для белого списка.

Источник↗

Lambda обрабатывает заказы из SQS — сообщение может быть доставлено дважды.

→Идемпотентность: хранить хеш запроса в DynamoDB с TTL; PUT-IfNotExists при каждой повторной попытке. Или использовать очередь FIFO с дедупликацией.

Источник↗

Добровольные вытеснения подов (осушение узла, кластерный автомасштабировщик) отключают все реплики развертывания.

→Kubernetes PodDisruptionBudget, указывающий `minAvailable` или `maxUnavailable`. Кластер соблюдает его при добровольных сбоях.

Источник↗

Выбрать класс хранения S3.

→Частый доступ → Standard. Неизвестный шаблон доступа → Intelligent-Tiering. Редкий доступ более 30 дней → Standard-IA. Допустимо Single-AZ, редкий доступ → One Zone-IA. Архив, извлечение за мс → Glacier Instant. Архив, извлечение за минуты → Glacier Flexible. Архив, извлечение за часы, самый дешевый → Glacier Deep Archive.

Источник↗

Бакет со смешанным доступом и непредсказуемыми шаблонами; автоматическая оптимизация стоимости.

→S3 Intelligent-Tiering. Мониторит доступ; автоматически перемещает объекты между уровнями (Frequent / Infrequent / Archive Instant / Archive / Deep Archive). Без платы за извлечение.

Почему: Небольшая плата за мониторинг каждого объекта, но дешевле, чем ошибиться. По умолчанию для неизвестных шаблонов.

Источник↗

Надежная и быстрая загрузка больших объектов (> 100 МБ) через интернет.

→S3 Multipart Upload (параллельные части) + S3 Transfer Acceleration (инжестирование через граничные узлы CloudFront).

Почему: Параллельные части насыщают полосу пропускания; Transfer Acceleration переносит нагрузку WAN-перехода на магистраль AWS.

Источник↗

Выбрать тип тома EBS.

→Общего назначения, по умолчанию → gp3 (базовые 3000 IOPS, 125 МБ/с; настраиваемо). База данных с высоким IOPS → io2 Block Express. Последовательная пропускная способность для больших данных → st1. Холодный архив → sc1. Загрузочные тома → gp3.

Почему: gp3 отделил IOPS/пропускную способность от размера; дешевле, чем gp2 при эквивалентной производительности.

Источник↗

Несколько экземпляров EC2 должны читать и записывать в один и тот же блочный том.

→EBS Multi-Attach с io2 / io1 (только для экземпляров Nitro). Одновременное подключение до 16 экземпляров в той же AZ.

Почему: Приложение должно координировать записи (кластерная файловая система). EFS — это решение по умолчанию для общего доступа к файлам; Multi-Attach предназначен для кластеризованных БД, которым требуется блочный доступ.

Источник↗

Выбрать общую файловую систему.

→Совместимая с POSIX Linux NFS, Multi-AZ, автомасштабирование → EFS. Windows SMB / интегрированная с AD → FSx for Windows. HPC, Lustre, связанная с S3 → FSx for Lustre. Функции NetApp ONTAP (снимки, инструменты NetApp) → FSx for ONTAP. ZFS → FSx for OpenZFS.

Источник↗

EFS — выбрать режим пропускной способности.

→Переменная нагрузка, масштабируется с размером → Bursting. Предсказуемая высокая пропускная способность → Provisioned. Чувствительна к всплескам, но требуется эластичная оплата → Elastic (по умолчанию для новых файловых систем, масштабируется автоматически).

Источник↗

Локальное резервное копирование файлов/блоков/лент, интегрированное с S3 / Glacier.

→AWS Storage Gateway: File Gateway (NFS/SMB → S3), Volume Gateway (iSCSI → S3 + снимки EBS), Tape Gateway (VTL → Glacier).

Источник↗

Статические ресурсы + ответы API с глобальными пользователями; снижение нагрузки на origin.

→CloudFront с соответствующей политикой кеширования. Длительные TTL для статики; ключ кеша включает только важные заголовки/строки запроса. Используйте Origin Shield для origin с высокой кардинальностью.

Почему: Коэффициент попаданий в кеш определяет как производительность, так и стоимость. Неправильный ключ кеша (например, включающий все заголовки) уничтожает коэффициент попаданий.

Источник↗

Манипулировать запросом/ответом на граничной ноде.

→Легковесные, на стороне пользователя, суб-миллисекундные (перезапись заголовков, редиректы, A/B) → CloudFront Functions. Более тяжелые, Node.js / Python, более длительные вычисления, сетевой доступ → Lambda@Edge.

Источник↗

Выбрать ElastiCache Redis или Memcached.

→Репликация, персистентность, pub/sub, отсортированные наборы, Multi-AZ failover → Redis. Многопоточность, простое хранение ключ/значение, только горизонтальное шардирование → Memcached.

Источник↗

Хранилище сессий Redis нуждается в высокой доступности с автоматическим переключением между AZ.

→Группа репликации ElastiCache for Redis с включенным Multi-AZ + автоматическим переключением. Первичный в одной AZ, реплики в других.

Источник↗

Задержка чтения DynamoDB измеряется микросекундами; кеширование без изменений приложения.

→DynamoDB Accelerator (DAX). Управляемый кеш в VPC; тот же SDK DynamoDB; прозрачное чтение сквозь кеш (read-through).

Почему: ElastiCache требует логики кеширования на уровне приложения. DAX — это "вставляемый" кеш для DynamoDB.

Источник↗

Выбрать стратегию кеширования.

→Ленивая загрузка (промах кеша → получение + заполнение): просто, кеширует только то, что запрашивается. Сквозная запись (запись в кеш + БД при обновлении): кеш всегда актуален, но дополнительные записи. TTL: ограничение устаревания для любого шаблона.

Источник↗

Выбрать вычислительную платформу.

→Управляемая событиями, менее 15 минут, масштабирование за доли секунды, без инфраструктуры → Lambda. Длительно работающие контейнеры, без управления узлами → Fargate. Пользовательское ядро, GPU, постоянное состояние, самое дешевое для постоянной нагрузки → EC2.

Источник↗

Холодный запуск Lambda Java негативно влияет на задержку p99.

→Lambda SnapStart (Java, Python, .NET). Снимок инициализированной среды выполнения восстанавливается при вызове; до 10 раз быстрее холодный запуск.

Источник↗

Предсказуемая пиковая нагрузка; холодные запуски недопустимы.

→Provisioned Concurrency. Предварительно "разогретые" среды, готовые к вызову с любой пропускной способностью. Сочетать с Application Auto Scaling для запланированного масштабирования.

Почему: Стоит дороже, чем On-Demand, но устраняет холодный запуск. Не требуется для стабильного трафика, где загрузка Provisioned Concurrency остается высокой естественным образом.

Источник↗

Выбрать тип API Gateway.

→Полный набор функций (валидация запросов, трансформации, ключи API, планы использования) → REST API. Более низкая стоимость, меньшая задержка, нативная поддержка JWT/OIDC, проще → HTTP API. Двунаправленное взаимодействие в реальном времени → WebSocket API.

Источник↗

Мобильному/веб-приложению требуется GraphQL с подписками в реальном времени, поддерживаемыми DynamoDB / Lambda.

→AWS AppSync. Управляемый GraphQL, подписки WebSocket, гранулированная авторизация через Cognito / IAM / Lambda-авторизаторы.

Источник↗

Выбрать Kinesis Data Streams против Firehose против Managed Service for Apache Flink против MSK.

→Пользовательские потребители, задержка в мс, повторное воспроизведение, веерная рассылка нескольким потребителям → Data Streams. Просто доставка в S3/Redshift/OpenSearch с буферизацией → Firehose. Обработка потоков (окна, соединения) → Managed Service for Apache Flink. Совместимый с Kafka → MSK.

Источник↗

Запросы Athena сканируют терабайты; стоимость / время чрезмерны.

→Разделить данные по предикату запроса (дата, регион). Преобразовать в столбчатый формат Parquet/ORC. Использовать проекцию партиций, чтобы избежать круговых обращений к каталогу.

Почему: Athena взимает плату за сканирование ТБ. Столбчатое хранение + партиционирование часто сокращает стоимость в 10–100 раз.

Источник↗

Запрашивать данные, находящиеся в S3, из Redshift без их загрузки.

→Redshift Spectrum. Внешняя схема поверх Glue Data Catalog; узлы Spectrum сканируют S3 и передают результаты обратно в кластер.

Источник↗

Выбрать режим емкости DynamoDB.

→Непредсказуемые / пиковые / новые рабочие нагрузки → On-demand. Стабильные, предсказуемые, горячие — и чувствительные к стоимости → Provisioned с автомасштабированием. Переключать режимы не чаще одного раза в 24 часа.

Источник↗

Запрашивать DynamoDB по атрибуту, который не является ключом раздела.

→Global Secondary Index (GSI) для запросов по другому ключу раздела. Local Secondary Index (LSI) для альтернативного ключа сортировки по тому же ключу раздела (LSI должен быть создан во время создания таблицы).

Источник↗

Таблица сессий DynamoDB бесконтрольно растет; сессии истекают через 24 часа.

→DynamoDB TTL для числового атрибута эпохи. DynamoDB асинхронно удаляет истекшие элементы, без взимания платы за емкость записи.

Источник↗

Рабочая нагрузка HPC нуждается в минимально возможной задержке между узлами.

→Группа размещения кластера (Cluster placement group): экземпляры в одной AZ на одном физическом стоечном оборудовании. До 10 Гбит/с на один поток.

Почему: Spread placement → максимальная изоляция (HA); Partition → большие данные (Hadoop, Cassandra); Cluster → минимальная задержка.

Источник↗

Выбрать опцию покупки EC2 для стабильного парка, работающего 24×7.

→Compute Savings Plan (1 год или 3 года) — скидка 66% от прайса, гибкий по семейству экземпляров, размеру, ОС, типу аренды, региону. RIs только когда требуется резервирование емкости.

Почему: Savings Plans превосходят RIs для большинства сценариев, ориентированных только на стоимость (более гибкие, та же скидка).

Источник↗

Выбрать Compute Savings Plan против EC2 Instance Savings Plan против SageMaker Savings Plan.

→Compute SP: максимальная гибкость (охватывает EC2, Fargate, Lambda) — лучший вариант по умолчанию. EC2 Instance SP: привязка к семейству, большая скидка. SageMaker SP: только для SageMaker.

Источник↗

Использовать Spot для экономии средств на толерантных рабочих нагрузках.

→Spot через политику смешанных экземпляров ASG со стратегией выделения, оптимизированной по емкости, + несколько типов экземпляров. Обрабатывать уведомление о прерывании за 2 минуты через метаданные экземпляра.

Почему: capacity-optimized выбирает пулы с наименьшей вероятностью восстановления. Множество типов диверсифицируют риск пула.

Источник↗

Имеются неиспользуемые зарезервированные экземпляры после миграции.

→Продать на Reserved Instance Marketplace (только Standard RIs). Или конвертировать через Convertible RIs в другое семейство.

Почему: Convertible RIs предлагают немного меньшую скидку за право обмена.

Источник↗

Сократить расходы на вычисления без переписывания архитектуры.

→Мигрировать на экземпляры Graviton (ARM64). Примерно на 20% дешевле, примерно на 40% лучше соотношение цена/производительность для многих рабочих нагрузок. Требует многоархитектурных образов контейнеров или перекомпилированных бинарных файлов.

Источник↗

Функции Lambda, где среда выполнения поддерживает ARM.

→Установить архитектуру на `arm64` (Graviton). На 20% дешевле за мс, чем x86, часто быстрее. Требует архитектурно-совместимых нативных зависимостей.

Источник↗

Стоимость Lambda слишком высока; время выполнения ограничено CPU.

→Увеличить память (что пропорционально масштабирует CPU и сеть). Используйте Lambda Power Tuning (инструмент Step Functions), чтобы найти оптимальное соотношение — часто большая память означает быстрее И дешевле.

Источник↗

Логи и старые объекты накапливаются в S3 Standard.

→Правила S3 Lifecycle: переход в IA через 30 дней, Glacier Flexible через 90 дней, Deep Archive через 180 дней, истечение срока действия после сохранения. Сочетать с Intelligent-Tiering для неизвестных шаблонов.

Источник↗

Визуализировать расходы на S3 по аккаунтам; найти кандидатов для оптимизации.

→S3 Storage Lens. Панель управления для всей организации с информацией об использовании, активности, рекомендациями по экономии. Уровень Advanced metrics для детализации на уровне префиксов.

Источник↗

Платежи за обработку данных NAT Gateway доминируют в счете.

→Заменить трафик сервисов AWS на VPC Endpoints (gateway для S3/DynamoDB; interface для всего остального). Перемещать рабочие нагрузки, требующие выхода в интернет, в публичные подсети только при необходимости.

Почему: NAT Gateway взимает плату за каждый обработанный ГБ, даже для трафика сервисов AWS. Endpoints устраняют этот путь.

Источник↗

Сократить расходы на передачу данных.

→Одна AZ, один VPC = бесплатно. Между AZ = $0.01/ГБ в каждую сторону. Между регионами = дорого. Исходящий трафик в интернет = самый дорогой, но бесплатно через CloudFront для кешируемого контента. Всегда используйте CloudFront для исходящего трафика, когда это возможно.

Источник↗

Стоимость CloudWatch Logs выходит из-под контроля.

→Установить явный срок хранения (по умолчанию "Никогда не истекает"). Экспортировать старые логи в S3 + Glacier. Использовать Logs Insights только для "теплых" данных. Фильтровать на агенте (не отправлять отладочные логи в продакшн).

Источник↗

Найти кандидатов для правильного выбора размера ресурсов в EC2, Auto Scaling Groups, EBS, Lambda.

→AWS Compute Optimizer. Считывает метрики CloudWatch + ML, рекомендует уменьшение размера или смену семейства. Бесплатно для всей организации при opt-in.

Источник↗

Проактивно обнаруживать неожиданные всплески расходов.

→AWS Cost Anomaly Detection (в Cost Explorer). Мониторы на основе ML для каждого сервиса / связанного аккаунта / категории затрат. Оповещения через SNS / email.

Источник↗

Остановить неконтролируемые расходы в аккаунте-песочнице.

→AWS Budgets с действием: при пороге 80% отправить уведомление SNS; при 100% прикрепить политику deny SCP / IAM через Budgets Action.

Источник↗

Распределение затрат по командам или продуктам без отдельных аккаунтов.

→Теги распределения затрат (Cost allocation tags). Активировать пользовательские теги в консоли Billing; отображать в Cost Explorer + CUR. Сочетать с `aws:CreatedBy` для атрибуции идентификации.

Источник↗

Экземпляры EC2 для разработки/тестирования работают 24×7 — используются только с 9 до 17.

→AWS Instance Scheduler (развернутая через CloudFormation Lambda). Пометить экземпляры тегами с именами расписаний; запускает старт/стоп по расписанию. Или просто `aws:autoscaling:scheduledActions` на ASG для разработки.

Почему: ~70% сокращение расходов на вычисления для разработки при остановке в нерабочее время.

Источник↗

Экземпляр Dev RDS простаивает по ночам/выходным.

→Остановить экземпляр RDS (Single-AZ; до 7 дней, затем автозапуск). Или Aurora Serverless v2 с min ACU = 0.5 (нет полной остановки, но минимальная стоимость при простое).

Источник↗

Оптимизация стоимости контейнерного парка.

→Стабильная, высокая утилизация → ECS на EC2 (со Spot/Savings Plans) — самое дешевое. Пиковая / короткоживущая / без управления узлами → Fargate. Fargate Spot на 70% дешевле обычного Fargate для толерантных рабочих нагрузок.

Источник↗

Уменьшить исходящий трафик S3 / EC2 в интернет.

→Использовать CloudFront. Передача от Origin к граничному узлу бесплатна; от граничного узла к пользователю дешевле, чем прямой исходящий трафик EC2/S3 в масштабе. Включить сжатие + соответствующие TTL.

Источник↗

Мигрировать 100 ТБ с локального NFS в S3.

→Агент AWS DataSync локально; запланированная передача в S3. Зашифровано, проверено на целостность, с ограничением скорости. Snowball Edge для 100 ТБ+ или низкой пропускной способности.

Источник↗

Переместить > 1 ПБ из локальной среды в AWS; пропускная способность слишком низка для онлайн-передачи.

→AWS Snow Family. Snowball Edge Storage Optimized (80 ТБ) для обычных случаев; несколько устройств параллельно для сотен ТБ. Snowmobile снят с производства — используйте несколько Snowball для петабайтного масштаба.

Источник↗

Продакшн RDS / ElastiCache / OpenSearch / Redshift работает 24×7.

→Зарезервированные экземпляры (Reserved Instances) для управляемых баз данных (нет эквивалента Savings Plan для этих сервисов). 1 год или 3 года; частичная предоплата обычно дает лучшую чистую приведенную стоимость.

Источник↗

Быстрые и легкие способы экономии затрат по всему аккаунту.

→Проверки стоимости AWS Trusted Advisor: простаивающие балансировщики нагрузки, EC2 с низкой утилизацией, неприсоединенные EBS, недоиспользуемые RDS, простаивающие Redshift. Бесплатный уровень ограничен; полный набор с Business / Enterprise Support.

Источник↗