Створення Production-Ready мультисередовищної AWS інфраструктури з Terraform

Виклик мультисередовищної інфраструктури

Управління кількома AWS середовищами—розробка, тестування, production—створює фундаментальну дилему: дублювати все і потроїти витрати, або ділити ресурси і ризикувати зв'язаністю середовищ. Ручні AWS розгортання ускладнюють проблему через дрейф конфігурації, повільне провіжнінг (години замість хвилин) та документацію, яка ніколи не відповідає реальності.

Infrastructure as Code з Terraform вирішує ці проблеми, але патерни реалізації мають значення. Ця стаття документує протестовані в production підходи для мультисередовищної AWS інфраструктури, демонструючи як збалансувати економічну ефективність, операційну простоту та швидкість команди.

Ключові результати:

40% оптимізація ресурсів через стратегічне спільне використання інфраструктури
88% скорочення часу розгортання (120 хвилин → 15 хвилин)
Спільна інфраструктура масштабується на ~40% на середовище (vs 100% дублювання)
Повне провіжнінг середовища за хвилини через terraform apply

Архітектура: спільний фундамент, ізольовані сервіси

Основний патерн: ділити інфраструктуру з незначним ризиком ізоляції (VPC, RDS, ECR), дублювати ресурси, що вимагають незалежності (ECS, CloudFront, S3).

Стек сервісів:

Обчислення: ECS на EC2 (на 40% дешевше ніж Fargate з прийнятною складністю)
База даних: Єдиний RDS PostgreSQL з ізоляцією на рівні схем
Зберігання: S3 + CloudFront для кожного середовища (запобігає забрудненню кешу між staging/prod)
Serverless: Lambda для обробки зображень, AI генерації контенту (AWS Bedrock)
Черги: SQS для фонових завдань з dead-letter чергами

Структура мультисередовищ

Оптимізація ресурсів:

Єдиний RDS vs 3 інстанси: 65% зниження витрат
Спільний VPC усуває дублювання мережевих витрат
ECR з тегами (dev-v1.0.0, prod-v1.0.0) vs окремі реєстри
Загалом: 40% оптимізація ресурсів

Реалізація: структура директорій

Реалізація організовує Terraform конфігурацію в два окремі шари з чітким розділенням відповідальності.

Організація директорій

terraform/
├── shared/              # Розгорнути один раз, обслуговує всі середовища
│   ├── main.tf         # Remote state backend
│   ├── vpc.tf          # VPC, subnets, NAT
│   ├── rds.tf          # PostgreSQL Multi-AZ
│   ├── ecr.tf          # Container registry
│   ├── security.tf     # Security groups
│   └── outputs.tf      # Export IDs
│
├── environments/        # Змінні для кожного середовища
│   ├── dev.tfvars      # Конфігурація розробки
│   ├── staging.tfvars  # Конфігурація тестування
│   └── prod.tfvars     # Конфігурація production
│
├── main.tf             # Remote state references
├── ecs.tf              # Task definitions
├── lb.tf               # Load balancers
├── cloudfront.tf       # CDN distributions
├── s3.tf               # Storage buckets
├── ssm.tf              # Credentials
└── sqs.tf              # Async queues

Поля спільної інфраструктури

Конфігурація VPC (shared/vpc.tf):

Розподіл CIDR блоків (зазвичай /16)
Публічні підмережі через зони доступності
Приватні підмережі для бази даних та контейнерів
NAT інстанси (не NAT Gateway для оптимізації витрат)
Таблиці маршрутизації та асоціації

Конфігурація RDS (shared/rds.tf):

Розмір класу інстансу (почати з db.t3.micro)
Multi-AZ розгортання для автоматичного failover
Збереження резервних копій (7-30 днів)
Версія движка (PostgreSQL 16+)
Групи підмереж посилаються на приватні підмережі VPC
Security groups обмежують доступ тільки для ECS
Захист lifecycle prevent_destroy

Конфігурація ECR (shared/ecr.tf):

Конвенція імен репозиторіїв
Налаштування мутабельності тегів образів
Політики життєвого циклу для очищення (нетеговані образи, старі релізи)
Конфігурація шифрування (AES256)

Поля для кожного середовища

ECS Task Definition (ecs.tf):

Іменування сімейства з суфіксом середовища
Розподіл CPU та пам'яті (змінюється за середовищем)
Визначення контейнерів через templatefile
Мережевий режим (awsvpc для сучасних конфігурацій)
IAM execution та task ролі
Змінні середовища та секрети з SSM

Конфігурація ECS Service:

Бажана кількість task (масштабується за середовищем)
Тип запуску (EC2 vs Fargate)
Мережева конфігурація посилається на спільний VPC
Приєднання load balancer до target groups
Політики автомасштабування на основі CPU/пам'яті

CloudFront Distribution (cloudfront.tf):

Конфігурація origin вказує на S3 buckets
Політики поведінки кешу
SSL сертифікати з ACM
Вибір класу ціни (всі edges vs регіональні)
Користувацькі відповіді на помилки для SPA маршрутизації

S3 Buckets (s3.tf):

Іменування bucket з суфіксом середовища
CORS конфігурація для завантаження assets
Політики bucket обмежують доступ до CloudFront
Конфігурація шифрування в спокої

Патерн управління станом

Remote State Backend (shared/main.tf):

S3 bucket для зберігання стану
DynamoDB таблиця для блокування стану
Увімкнене шифрування
Версіонування для можливості відкату

Remote State References (main.tf):

Джерела даних terraform_remote_state
Споживання виводів спільного шару (VPC ID, subnet IDs, security groups)
Управління залежностями між шарами

Ця структура дозволяє незалежне розгортання спільної інфраструктури, водночас дозволяючи кожному середовищу масштабувати та налаштовувати ресурси незалежно через файли змінних.

Результати та уроки

Ключові метрики

Виграш в ефективності:

Розгортання інфраструктури: 2 години → 15 хвилин (88% скорочення)
Витрати на ресурси: 40% оптимізація через стратегічне спільне використання
Характеристики масштабування: Додавання середовища = +40% вартості (не +100%)
Провіжнінг середовища: Хвилини через terraform apply vs дні ручної роботи

Операційний вплив:

Multi-AZ RDS: Автоматичний failover без ручного втручання
Інфраструктура як документація: Terraform файли визначають всі ресурси
Disaster recovery: Відновити всю платформу з коду
Швидкість команди: Розробники самообслуговують тестові середовища

Що спрацювало

✅ Спільний RDS зі схемами: Надійно, економічно, операційно просто ✅ ECS на базі EC2: На 40% дешевше ніж Fargate з прийнятною складністю ✅ Remote state в S3: Дозволяє співпрацю команди з DynamoDB блокуванням ✅ Terraform як документація: Код завжди відповідає реальності

Підводних каменів уникати

❌ Обробка state файлу: Вимагає ретельного управління та регулярних резервних копій ❌ Накопичення резервних копій RDS: Моніторити та очищати старі snapshot ❌ CloudFront invalidations: Використовувати версійовані імена файлів для уникнення зборів ❌ Зміни спільних ресурсів: Координувати ретельно—впливає на всі середовища

Висновок

Мультисередовищна Terraform інфраструктура забезпечує 40% оптимізацію витрат та 88% швидше розгортання при збереженні належної ізоляції. Патерн—спільні VPC/RDS/ECR, окремі ECS/CloudFront/S3 для середовищ—балансує ефективність з незалежністю.

Шлях реалізації:

Розгорнути спільну інфраструктуру (VPC, RDS, ECR)
Повністю налаштувати одне середовище
Реплікувати патерн на додаткові середовища
Використовувати remote state та state locking з першого дня

Коли це має сенс:

Управління 3+ середовищами
Команди більше 5 інженерів
Часті зміни інфраструктури
Потреба у відтворюваних розгортаннях

Ресурси: