AWS для backend-разработчика — это четыре концепции, без которых любой разговор про облако превращается в перечисление аббревиатур: аккаунты (границы всего), IAM (кто что может), регионы и зоны доступности (где живёт отказоустойчивость) и VPC (как устроена сеть). Остальные двести сервисов — надстройки над этим фундаментом.
Аккаунты: граница безопасности и бюджета
Аккаунт AWS — жёсткая граница: ресурсы, права и счета одного аккаунта не видны из другого. Зрелая организация живёт не в одном аккаунте, а в множестве под AWS Organizations: отдельные аккаунты на прод/стейдж/песочницы, часто — по аккаунту на команду или домен. Это не бюрократия: радиус поражения утёкшего ключа или сбежавшего скрипта ограничен одним аккаунтом, а счёт за облако раскладывается по командам без детективной работы.
Что это значит для разработчика: «у нас есть AWS» — всегда вопрос «в каком аккаунте?»; доступ между аккаунтами — через assume role (ниже), а не через копирование ключей.
IAM: роли вместо ключей
IAM отвечает на вопрос «кто может делать что с каким ресурсом». Три сущности:
- Политика — JSON-документ с разрешениями:
Allow s3:GetObject на arn:aws:s3:::orders-export/*. - Роль — набор политик, который принимают (assume): нет постоянных ключей, есть временные креды на часы.
- Пользователь — человек или система с постоянными ключами. В современном AWS почти рудимент: люди ходят через SSO, сервисы — через роли.
Главное правило, экономящее инциденты: код никогда не носит с собой ключи. Сервис на EC2/ECS/EKS получает роль от платформы (instance profile, task role, IRSA в Kubernetes), SDK подхватывает её автоматически через credentials chain (подробно). Ключи в application.yml, в переменных CI, в git — три ступени одной и той же ошибки.
Второе правило — least privilege: роль сервиса заказов умеет читать свою очередь и писать в свой bucket, а не s3:* «чтобы работало». Просить у платформы узкие права дольше на десять минут и дешевле на один инцидент.
Регионы и зоны доступности
Регион — географическая площадка (Франкфурт, Стокгольм...), полностью независимая от других: ресурсы региональны, данные между регионами сами не перемещаются. Зона доступности (AZ) — изолированный кампус внутри региона: своё питание, сеть, охлаждение; между AZ — миллисекунды задержки.
Практический смысл: отказоустойчивость по умолчанию строится на нескольких AZ одного региона — реплики БД в разных AZ, поды/инстансы размазаны по AZ, балансировщик поверх. Падение зоны (бывает) сервис переживает; падение региона (редкость) — уже дисциплина disaster recovery с репликацией в другой регион, и её цена обсуждается отдельно. Для разработчика отсюда два следствия: ресурсы создаются «в регионе и AZ», и cross-AZ трафик стоит денег — чатти-обмен между сервисами в разных зонах виден в счёте.
VPC: сеть без магии
VPC — ваша приватная сеть внутри AWS. Минимальная модель, которой хватает разработчику:
- Подсети бывают публичные (есть маршрут в интернет через Internet Gateway) и приватные (наружу — только через NAT). Сервисы и БД живут в приватных; в публичных — балансировщики и bastion.
- Security group — файрвол на ресурсе: «кто может ко мне на какой порт». Правила пишутся ссылками на другие security groups («к БД может группа app»), а не IP-адресами — это AWS-аналог NetworkPolicy.
- Эндпоинты к сервисам AWS (VPC endpoints) — чтобы S3/SQS были доступны из приватной подсети напрямую, без выхода в интернет и без оплаты NAT-трафика.
Типичная ошибка проектирования — БД в публичной подсети «чтобы удобно подключаться с ноутбука». Удобство решается bastion/SSM, а публичная БД — это сканеры, перебор и место в новостях.
Как это сочетается с Kubernetes
Если сервисы живут в EKS, маппинг прямой: кластер — в приватных подсетях VPC, Ingress-контроллер — за ALB в публичных, роли подам выдаёт IRSA (роль на ServiceAccount), security groups дополняются NetworkPolicy. Вся k8s-серия применима без изменений — AWS лишь поставляет ноды, сеть и IAM.
Что почитать дальше
- Вычисления: где жить сервису — EC2 vs ECS/EKS vs Lambda.
- Managed-данные — RDS, ElastiCache, SQS/MSK против self-hosted.
- Интеграция из Spring — SDK v2 и credentials chain в коде.
- Безопасность и наблюдаемость — Secrets Manager, KMS, CloudWatch.