AWS

01Регионы, зоны доступности и разделённая ответственность

AWS разделён на регионы — отдельные географические области вроде Франкфурта или Ирландии, в каждой из которых есть своя копия большинства сервисов. Регион содержит несколько зон доступности (AZ): один или несколько дата-центров с независимым питанием, охлаждением и сетью, расположенных достаточно близко для быстрых соединений. Запуск приложения минимум в двух AZ защищает от отказа одного дата-центра; использование нескольких регионов защищает от отказа целого региона, но стоит гораздо дороже и сложнее. Выбирайте регион ближе к пользователям и соответствующий требованиям к данным. Безопасность разделена: AWS отвечает за безопасность самого облака (железо, дата-центры, гипервизор), а вы — за безопасность в облаке: ваши права IAM, сетевые правила, патчи для серверов EC2, шифрование и то, чтобы данные не торчали наружу.

• Регион = географическая область; AZ = изолированный дата-центр (или несколько) внутри неё.
• Высокая доступность = распределение минимум по двум AZ.
• Ошибки конфигурации на вашей стороне — самая частая причина утечек в облаке.

02Основные сервисы и когда их использовать

Сотни сервисов вам не нужны: дюжина покрывает большинство веб-приложений. Вычисления бывают трёх видов: виртуальные машины EC2, которыми вы управляете сами; контейнеры на ECS (проще, родной для AWS) или EKS (управляемый Kubernetes), при желании в serverless-режиме на Fargate; и функции Lambda, которые запускаются по событиям вообще без серверов. Данные живут в S3 для файлов и в RDS или Aurora для управляемых реляционных баз. CloudFront — CDN впереди, Route 53 — DNS и маршрутизация с health check'ами. VPC — ваша приватная сеть, IAM контролирует, кто что может делать, а SQS — управляемая очередь для развязки работы.

• EC2: полный контроль, долгоживущие серверы, любой софт.
• ECS / EKS (+ Fargate): контейнеры без самостоятельного управления планировщиками.
• Lambda: короткие задачи по событиям (до 15 минут), оплата за вызов.
• S3: объектное хранилище для загрузок, бэкапов, статических сайтов; версионирование и lifecycle-правила.
• RDS / Aurora: управляемые PostgreSQL или MySQL с бэкапами, Multi-AZ failover, репликами.
• CloudFront + Route 53: CDN и DNS; SQS: очереди; VPC + IAM: сеть и права доступа.

03Сеть: разумная схема VPC

VPC (virtual private cloud) — ваша изолированная сеть внутри региона. Вы делите её на подсети, каждая — в одной зоне доступности. У публичных подсетей есть маршрут к internet gateway, и в них живёт только то, что должно смотреть в интернет, — обычно load balancer. В приватных подсетях живут серверы приложений и базы данных; напрямую из интернета до них не достучаться. Security group'ы работают как stateful firewall'ы, привязанные к каждому ресурсу: load balancer принимает 443 откуда угодно, приложение — трафик только от security group балансировщика, база — только от security group приложения. Приватным ресурсам, которым нужен исходящий интернет (обновления пакетов или внешние API), нужен NAT gateway — это удобно, но это один из классических сюрпризов в счёте, поэтому стоит добавить VPC endpoint'ы для S3 и других сервисов AWS.

• Публичная подсеть: только load balancer.
• Приватная подсеть: приложение и база, доступ через ссылки на security group'ы.
• Между своими уровнями ссылайтесь на security group'ы, а не на диапазоны IP.

04IAM и принцип минимальных привилегий

IAM (Identity and Access Management) решает, кто может вызывать какой API AWS на каком ресурсе. Принцип минимальных привилегий означает, что каждая учётная запись получает только те права, которые нужны для её работы. Защитите root-аккаунт с помощью MFA и никогда не используйте его в повседневной работе. Люди должны входить через IAM Identity Center с временными учётными данными, а не с долгоживущими access key. Приложения должны использовать роли: instance profile у EC2, task role у ECS или execution role у Lambda автоматически дают коду короткоживущие учётные данные, так что никаких ключей в .env-файлах. Пишите узкие политики вроде примера, который разрешает приложению читать и писать только в один префикс бакета. Используйте IAM Access Analyzer, чтобы находить неиспользуемые или слишком широкие права, и включите CloudTrail, чтобы записывать каждый вызов API.

1{
2  "Version": "2012-10-17",
3  "Statement": [
4    {
5      "Effect": "Allow",
6      "Action": ["s3:GetObject", "s3:PutObject"],
7      "Resource": "arn:aws:s3:::example-app-uploads/uploads/*"
8    }
9  ]
10}

05Ловушки в расходах и как их избежать

Счета AWS редко бывают большими из-за одного крупного сервера; они растут из мелочей, за которыми никто не следит. NAT gateway'и берут плату за час и за каждый обработанный гигабайт. Исходящий трафик в интернет и между зонами доступности тихо накапливается. Каждый публичный IPv4-адрес оплачивается почасово. Неподключённые тома EBS, старые снапшоты, простаивающие load balancer'ы и забытые тестовые окружения продолжают списывать деньги. Приём логов в CloudWatch может стоить дороже серверов, которые эти логи пишут. RDS Multi-AZ примерно удваивает стоимость базы — часто это правильно, но это должно быть осознанным выбором. Защищайтесь с первого дня: настройте алерты AWS Budgets, тегируйте каждый ресурс проектом и окружением, раз в месяц смотрите Cost Explorer, задайте срок хранения логов и используйте Savings Plans или зарезервированные мощности для стабильной нагрузки.

1aws budgets create-budget --account-id 111122223333 \
2  --budget '{"BudgetName":"monthly","BudgetLimit":{"Amount":"200","Unit":"USD"},"TimeUnit":"MONTHLY","BudgetType":"COST"}' \
3  --notifications-with-subscribers '[{"Notification":{"NotificationType":"ACTUAL","ComparisonOperator":"GREATER_THAN","Threshold":80},"Subscribers":[{"SubscriptionType":"EMAIL","Address":"[email protected]"}]}]'

06AWS или VPS?

VPS от DigitalOcean, Hetzner и им подобных даёт фиксированную месячную цену, щедрый включённый трафик и одну простую панель управления. Для одного приложения хорошо настроенный VPS с Docker Compose, бэкапами вне площадки и мониторингом часто в разы дешевле аналога на AWS и понятнее маленькой команде. AWS выигрывает, когда нужно то, что трудно построить самому: управляемые базы с автоматическим failover и point-in-time recovery, автомасштабирование под всплески трафика, множество регионов, сертификаты соответствия, которых требуют корпоративные клиенты, или глубокая интеграция с другими сервисами AWS. Распространённый средний путь — VPS для вычислений плюс несколько точечных управляемых сервисов, например S3-совместимое хранилище для загрузок и CDN. Решайте по требованиям и навыкам команды, а не по моде.

07Как IAM решает: разрешить или запретить

Каждый вызов AWS API проверяется по всем политикам, которые к нему относятся, и логика здесь строгая. Всё начинается с неявного запрета. Явный Deny в любой применимой политике всегда побеждает. Внутри аккаунта запрос разрешён, только если его разрешает какая-то identity-based или resource-based политика и ничто его не запрещает. Поверх этого есть ограничители, которые могут только отнимать права и никогда их не выдают: service control policies из AWS Organizations, permission boundaries на роли и session policies тоже должны разрешать действие. Условия (Condition) делают политики точными: ограничение по исходному VPC endpoint, обязательное шифрование при передаче, обязательный MFA или доступ только к ресурсам с тегом одного проекта. Когда доступ не проходит, сообщение об ошибке и CloudTrail обычно подсказывают, какой тип политики его запретил, а IAM policy simulator может воспроизвести решение.

1{
2  "Version": "2012-10-17",
3  "Statement": [
4    {
5      "Sid": "DenyInsecureTransport",
6      "Effect": "Deny",
7      "Principal": "*",
8      "Action": "s3:*",
9      "Resource": ["arn:aws:s3:::example-app-uploads", "arn:aws:s3:::example-app-uploads/*"],
10      "Condition": { "Bool": { "aws:SecureTransport": "false" } }
11    }
12  ]
13}

08Мультиаккаунтная структура с AWS Organizations

Аккаунт AWS — самая сильная граница изоляции, которую предлагает AWS: отдельные права, отдельные квоты и отдельная строка в счёте. Поэтому зрелые установки используют много аккаунтов под управлением AWS Organizations, а не один аккаунт на всё. Типичная схема: management-аккаунт только для биллинга и настроек организации; аккаунт-архив логов, куда стекаются CloudTrail и config-логи из всех остальных аккаунтов и который команды приложений не могут изменить; security-аккаунт для инструментов аудита; и отдельные workload-аккаунты для продакшена, staging и песочниц. Service control policies на уровне организации задают правила, которые никто не может обойти внутри аккаунта: запрет выхода из организации, запрет отключения CloudTrail или запрет любых регионов, кроме используемых. Люди входят один раз через IAM Identity Center и переключаются в роли каждого аккаунта. AWS Control Tower может развернуть такую landing zone с разумными настройками по умолчанию.

• Радиус поражения: утёкший ключ от staging не может затронуть продакшен.
• Квоты и расходы разделены по аккаунтам и по командам.
• SCP — это ограничители: они сужают права, но никогда их не выдают.

09Правильный доступ к EC2: IMDSv2 и Session Manager

Каждый EC2-инстанс может читать свои метаданные, включая временные учётные данные своей instance role, с локального адреса 169.254.169.254. В исходной версии IMDSv1 работал любой простой GET-запрос, поэтому SSRF-уязвимость в приложении (когда сервер можно заставить запросить URL, подставленный атакующим) могла слить эти учётные данные. Именно так произошло несколько известных утечек. IMDSv2 требует сессионный токен, полученный PUT-запросом, и ограничение на число хопов, что закрывает большинство путей SSRF; включайте его обязательным на каждом инстансе — новые типы инстансов и AMI всё чаще делают это по умолчанию. Для shell-доступа AWS Systems Manager Session Manager открывает сессию через SSM-агент с аутентификацией через IAM и логированием в CloudTrail — без входящего порта 22, без bastion-хоста и без SSH-ключей, которые нужно ротировать. Через него же можно пробросить порт и достучаться до приватной базы для отладки.

1# require IMDSv2 on an existing instance
2aws ec2 modify-instance-metadata-options --instance-id i-0123456789abcdef0 \
3  --http-tokens required --http-endpoint enabled
4 
5# shell without SSH or open ports
6aws ssm start-session --target i-0123456789abcdef0
7 
8# tunnel to a private RDS instance through that host
9aws ssm start-session --target i-0123456789abcdef0 \
10  --document-name AWS-StartPortForwardingSessionToRemoteHost \
11  --parameters '{"host":["db.internal.example.com"],"portNumber":["5432"],"localPortNumber":["5432"]}'

10Куда уходят деньги на сеть и как их сохранить

Сеть — то место, где счета AWS чаще всего удивляют, потому что трафик тарифицируется по маршруту. Данные из интернета в AWS бесплатны. Данные наружу, в интернет, оплачиваются за гигабайт, причём тарифы CloudFront обычно ниже, чем при раздаче напрямую из EC2 или S3, и есть бесплатный месячный объём, так что CDN часто экономит и деньги, и задержку. Трафик между availability zones оплачивается в обе стороны, поэтому «болтливые» сервисы в разных зонах или реплики в других зонах стоят реальных денег. NAT gateway берёт плату за час и за каждый обработанный гигабайт сверх обычной передачи, так что приватные серверы, тянущие через NAT большие образы или бэкапы, платят дважды. Gateway VPC endpoints для S3 и DynamoDB бесплатны и убирают этот трафик с пути через NAT; interface endpoints для других сервисов стоят денег за час, но всё равно могут оказаться дешевле. Каждый публичный IPv4-адрес тоже оплачивается почасово.

• Добавляйте бесплатный S3 gateway endpoint в каждый VPC с приватными подсетями.
• Раздавайте публичные ассеты через CloudFront, а не напрямую из S3 или EC2.
• Используйте Cost Explorer с группировкой по usage type, чтобы найти расходы на NAT и передачу данных.