Капстоун: безопасная и устойчивая three-tier архитектура от края до края

К концу этого урока ты сможешь пройти полный путь запроса, назвать каждую границу доверия на нём и найти два структурных изъяна, из-за которых «three-tier» стартапа превратился в ждущий своего часа инцидент.

Форма: один VPC, две AZ, три тира

Всё живёт в одном VPC (Virtual Private Cloud, виртуальная частная облачная сеть), охватывающем минимум две Availability Zones — это «минимум две» и есть вся история надёжности, потому что AZ — это радиус поражения, который AWS позволяет отказать независимо. Внутри VPC подсети делятся на две зоны доверия. Публичные подсети (по одной на AZ) держат только обращённый в интернет край: Application Load Balancer и NAT Gateways. Приватные подсети держат всё, что никогда не должно быть напрямую доступно: Fargate-таски приложения и базу RDS. Правило безжалостно просто — если у ресурса есть маршрут к internet gateway, он открыт; у базы его быть не должно.

Путь запроса рассказывает всю историю. Пользователь обращается к твоему apex-домену; Route 53 разрешает его (ALIAS-запись на apex зоны — так указывают голый домен на ресурс AWS, ведь на apex нельзя сделать CNAME). Запрос попадает на CloudFront, который терминирует TLS на краю по сертификату ACM, отдаёт закэшированные статические ассеты и пробрасывает динамические запросы на Application Load Balancer. ALB живёт в публичных подсетях, слушает HTTPS и маршрутизирует в target group из Fargate-тасков в приватных подсетях. Таск выполняет твоё приложение и, чтобы делать свою работу, говорит с двумя бэкендами: RDS (Postgres, Multi-AZ) для реляционных данных и S3 для объектов. Ответ уходит обратно той же цепочкой. Каждая стрелка на этом пути — ещё и граница, которую ты можешь запереть.

Каждый тир маппится на управляемый сервис не просто так — мышцы крутишь не ты, а AWS, и своё внимание ты тратишь на границы.

Безопасность: границы, ссылающиеся друг на друга

Модель безопасности — это defense in depth, хребет Well-Architected Security Pillar: много слоёв, каждый бесполезно обходить в одиночку. Первый слой — разделение подсетей: у RDS в приватной подсети просто нет маршрута в интернет, поэтому «открытый порт для всего мира» перестаёт быть возможным. Второй — security groups, ссылающиеся друг на друга по ID, а не по CIDR. Ты пишешь три: ALB SG разрешает 443 из интернета; app SG разрешает трафик только из ALB SG; DB SG разрешает 5432 только из app SG. Никто не вбивает диапазон IP. Цепочка — интернет, ALB SG, app SG, DB SG, и каждое звено наименее привилегированно по построению — ровно тот провал, в который угодил стартап, только теперь структурно невозможный.

Остальные слои укладываются сверху. Секреты (пароль базы, API-ключи) живут в Secrets Manager и инжектятся в таск во время выполнения, никогда не запекаются в образ или env-файл в git. Шифрование в покое даёт KMS на RDS и S3; шифрование в транзите — TLS от края до края: ACM на CloudFront, а хоп app-to-RDS использует RDS CA. Task role у Fargate — наименее привилегированная IAM-роль, дающая ровно те бакеты S3 и пути Secrets Manager, что нужны этому сервису, и ничего больше, так что скомпрометированный контейнер не сможет распространиться по аккаунту. Ничто во всей системе не доступно публично, кроме CloudFront и ALB.

# Урезанный CloudFormation: границы безопасности — это и есть весь смысл.
Resources:
  AlbSG:
    Type: AWS::EC2::SecurityGroup
    Properties:
      VpcId: !Ref Vpc
      SecurityGroupIngress:
        - { IpProtocol: tcp, FromPort: 443, ToPort: 443, CidrIp: 0.0.0.0/0 }  # ALB = единственный публичный вход

  AppSG:                       # Fargate-таски — только приватные подсети
    Type: AWS::EC2::SecurityGroup
    Properties:
      VpcId: !Ref Vpc
      SecurityGroupIngress:
        - { IpProtocol: tcp, FromPort: 8080, ToPort: 8080, SourceSecurityGroupId: !Ref AlbSG }

  DbSG:                        # RDS — доступен app-tier и больше никому
    Type: AWS::EC2::SecurityGroup
    Properties:
      VpcId: !Ref Vpc
      SecurityGroupIngress:
        - { IpProtocol: tcp, FromPort: 5432, ToPort: 5432, SourceSecurityGroupId: !Ref AppSG }

  Db:
    Type: AWS::RDS::DBInstance
    Properties:
      Engine: postgres
      MultiAZ: true                          # синхронный standby во 2-й AZ, авто failover
      StorageEncrypted: true                 # KMS в покое
      PubliclyAccessible: false              # никогда не публичный IP
      DBSubnetGroupName: !Ref PrivateDbSubnets
      VPCSecurityGroups: [ !Ref DbSG ]
      ManageMasterUserPassword: true         # пароль живёт в Secrets Manager, не в шаблоне

Это infrastructure as code намеренно. Весь VPC, каждая подсеть, каждое правило SG, ALB, сервис Fargate и инстанс RDS объявлены в одном проверяемом шаблоне (CloudFormation, CDK или Terraform). Инцидент с открытой базой случился потому, что человек прогнал разовое изменение через консоль, которое никто не ревьюил и никто не мог увидеть позже. Когда архитектура — это код, такой дрейф всплывает в diff и ловится на ревью — правило SG выше не сможет тихо стать 0.0.0.0/0 без того, чтобы кто-то одобрил pull request.

Устойчивость и наблюдаемость: пережить AZ и увидеть это

Провал с одной AZ из хука исправлен структурно. ALB охватывает обе публичные подсети; Fargate-таски бегут по обеим приватным подсетям; а RDS Multi-AZ держит синхронный standby во второй AZ. Согласно докам RDS, репликация в этот standby синхронна, так что закоммиченная запись лежит в обеих AZ до того, как клиент получит ack, и при отказе primary AWS выполняет автоматический failover, переключая DNS-эндпоинт базы на standby — твоё приложение переподключается к тому же хостнейму. Цена этой безопасности реальна: синхронная репликация добавляет латентность записи/коммита против single-AZ, и ты платишь за standby. Это и есть центральный трейдофф устойчивости, и для production data-tier его почти всегда стоит платить. (Заметь: standby не обслуживает чтения — он существует для failover; если нужно масштабирование чтений, добавляют read replicas или Multi-AZ cluster.)

Нельзя эксплуатировать то, чего не видишь, поэтому наблюдаемость встроена с самого начала, как предписывает detection-руководство Well-Architected. CloudWatch собирает метрики и логи со всех тиров; алармы следят за сигналами, которые реально значат «пользователям больно»: HTTPCode_ELB_5XX_Count у ALB, утилизация CPU/памяти Fargate (она же гонит автомасштаб) и DatabaseConnections и свободное место у RDS. Алармы срабатывают в топик SNS, который пейджит человека. X-Ray трассирует запрос через CloudFront, ALB, Fargate, RDS, чтобы при скачке латентности ты видел, чей это тир, а не гадал. Смысл того, что мы раньше прошли путь запроса, ровно в этом: каждый хоп — место, где должны существовать метрика, лог и сегмент трассы.

Стоимость: тот же дизайн, в цене

Корректная архитектура, которую ты не можешь себе позволить, под давлением переписывается в некорректную, поэтому стоимость — часть дизайна, а не запоздалая мысль. App-tier на Fargate крутит постоянный baseline плюс запас под автомасштаб; baseline ты покрываешь Compute Savings Plan (обязательство на 1 или 3 года, дисконтирующее и Fargate, и Lambda) и даёшь on-demand гасить всплески. Standby Multi-AZ у data-tier примерно удваивает стоимость compute RDS — это премия за доступность, и это единственное место, где ты не режешь. Часы NAT Gateway и egress за ГБ — коварная статья; per-AZ NAT нужны ради устойчивости, но их счёт ты режешь, отправляя AWS-направленный трафик (S3) через бесплатный gateway endpoint и держа болтливый межзональный трафик в узде. S3 получает lifecycle-правила, чтобы перекладывать холодные объекты в более дешёвые storage-классы. Подгоняй vCPU/память Fargate-тасков и класс инстанса RDS под реальную утилизацию из CloudWatch, а не гадая — та наблюдаемость, что ты построил ради надёжности, заодно говорит, где у тебя перевыделение.