Міграція на AWS крок за кроком — практичний гайд для компаній, які ніколи цього не робили
Ти працюєш на VPS у Hetzner. Або на HOSTiQ, або на HostPro, або на якомусь сервері, який хтось колись підняв і з того часу ніхто точно не знає, що саме на ньому крутиться. Або — і це реальність для багатьох українських компаній — твій сервер фізично в Україні, і питання «а що буде, якщо дата-центр відключать від світла» перестало бути теоретичним.
Хтось сказав: треба переїхати на AWS. Цей гайд — для тебе. Не для того, хто керує флотом із 200 інстансів. Для компанії, в якої є один додаток, одна база, може якийсь фоновий процес — і яка хоче це перенести на AWS без революції, без тижневого простою і без рахунку, якого ніхто не очікував.
Перш ніж щось переносити: інвентаризація
Найбільша помилка, яку ми бачимо при міграціях — люди кидаються переносити, не розібравшись, що саме мають. Звучить банально, але на практиці дивовижна кількість компаній не знає точно, що працює на їхньому сервері.
Перед тим як відкривати консоль AWS, дай відповідь на кілька запитань:
Що крутиться на сервері? Не «сайт і база». Конкретно: який веб-сервер (nginx, Apache), яка версія PHP/Node/Python, який двигун бази (MySQL 5.7? PostgreSQL 14? MariaDB?), які додаткові сервіси (Redis, Elasticsearch, Memcached), чи є крони, скрипти, фонові процеси.
Скільки даних у тебе є? Не «мало» чи «багато». Точно: скільки важить дамп бази, скільки важать файли (аплоади, ассети), скільки займає код. Ці цифри визначають час міграції та вартість трансферу.
Який трафік обслуговуєш? Середній та піковий. Скільки запитів/секунду у звичайний день, скільки в пік (розпродаж, рекламна кампанія, вирусний пост). Від цього залежить вибір інстансу.
Які домени і DNS? Хто керує DNS — реєстрація домену це одне, але куди дивляться A/CNAME записи? Який TTL? Це впливає на стратегію переключення.
Чи є бекапи? І чи пробував ти коли-небудь з них відновити працюючу систему? Міграція — гарний момент це з'ясувати.
Запиши все. Не в голові — на папері, в таблиці, де завгодно. Цей документ — твоя карта міграції.
Стратегія: lift-and-shift чи перебудова?
Є два підходи до міграції, і треба свідомо обрати один.
Lift-and-shift — береш те, що маєш, і переносиш на AWS із мінімальними змінами. Твій VPS стає інстансом EC2. База лягає на RDS або на той самий EC2. Файли — на EBS. Архітектура не змінюється, змінюється тільки місце, де це працює.
Плюси: швидко, передбачувано, мало що може зламатися на рівні додатку. Мінуси: не використовуєш те, що AWS пропонує — масштабування, керовані сервіси, оптимізацію витрат. Платиш за EC2, що крутиться 24/7, так само як платив за VPS.
Перебудова — переписуєш архітектуру під сервіси AWS. База йде на керований RDS. Статичні файли — на S3 + CloudFront. Частина логіки переходить на Lambda. Моніторинг — на CloudWatch.
Плюси: нижчі витрати в довгостроковій перспективі, краще масштабування, менше обслуговування. Мінуси: більше роботи, потрібні знання AWS, довший час міграції, ризик нових багів.
Наша рекомендація: Починай із lift-and-shift. Переїдь на AWS, стабілізуйся, переконайся, що все працює. Потім — у своєму темпі — оптимізуй. Не намагайся робити обидві речі одночасно.
Крок 1: Акаунт AWS та базове налаштування
Створи акаунт AWS. Кілька речей, які варто зробити відразу:
Увімкни MFA на root-акаунті. Це перше, що робиш. Root без MFA — це відчинені двері. Фізичний U2F ключ найкращий, але TOTP-додаток (Google Authenticator, Authy) теж підійде.
Створи окремого IAM-користувача для щоденної роботи. Не заходь на root для адміністрування.
Постав Billing Alarm. У CloudWatch налаштуй алерт, який надішле листа, коли місячний рахунок перевищить поріг — наприклад, $50 чи $100. Це рятує від сюрпризів. Для українських компаній, які звикли до фіксованих цін за VPS, це особливо критично — в AWS рахунок залежить від використання.
Обери регіон: Франкфурт (eu-central-1). Для українських компаній це оптимальний вибір. Найближчий повний регіон AWS в ЄС, широка палітра сервісів, прийнятна латенсі до українських користувачів (~30–40 мс). В Україні Local Zone немає, тому Франкфурт — це базовий варіант. Якщо більшість твоїх користувачів в Україні і ти сервіруєш статику через CloudFront — вона все одно летить із найближчого edge location.
Крок 2: Мережа (VPC)
AWS створює дефолтний VPC у кожному регіоні, але для продакшн-навантажень краще підняти власний.
Практичний сетап для типового додатку:
Створи VPC із CIDR-блоком, наприклад 10.0.0.0/16. Створи два публічних сабнети (по одному в кожній зоні доступності, наприклад eu-central-1a та eu-central-1b) і два приватних. Публічні — для лоад-балансерів і того, що повинно бути видимим з інтернету. Приватні — для EC2-інстансів та баз даних.
Додай Internet Gateway та підключи його до публічних сабнетів. Якщо інстанси в приватних сабнетах потребують доступу до інтернету (наприклад, для оновлень) — потрібен NAT Gateway. Але обережно: NAT Gateway — один із найдорожчих «прихованих» коштів AWS. Саме його існування обходиться у ~$38/місяць у Франкфурті плюс оплата за оброблені дані. Де можеш — використовуй VPC Endpoints для сервісів AWS (S3, DynamoDB) замість того, щоб пускати трафік через NAT.
Крок 3: База даних
Тут є рішення, яке треба прийняти: перенести базу на керований RDS одразу чи спочатку поставити її на EC2 (як на VPS) і перенести на RDS потім?
Варіант А: Відразу на RDS — рекомендований, якщо у тебе стандартний MySQL/PostgreSQL/MariaDB без екзотичних конфігурацій. RDS сам керує бекапами, патчінгом, фейловером. Менше твоєї роботи, менше ризику втрати даних.
Створи RDS-інстанс. Для типового додатку МСБ: db.t4g.micro (2 vCPU, 1 GB RAM) або db.t4g.small (2 vCPU, 2 GB RAM). Single-AZ на старті — Multi-AZ подвоює ціну, а для більшості невеликих компаній не є критичним із першого дня. 20–50 GB сховища з gp3.
Зроби дамп бази на старому сервері, перекинь його на RDS через mysql/psql клієнт. При базах до кількох GB — це справа хвилин. При більших — розглянь AWS Database Migration Service (DMS), який вміє мігрувати з мінімальним простоєм.
Варіант Б: База на EC2 — якщо маєш нестандартну конфігурацію, плагіни, специфічні налаштування, які RDS не підтримує. Піднімаєш EC2, ставиш двигун бази як на VPS, переносиш дамп. Працює ідентично, але відповідальність за бекапи та патчінг — на тобі.
Крок 4: Додаток
Тепер сам додаток. У варіанті lift-and-shift:
Запусти EC2-інстанс у приватному сабнеті. Для типового веб-додатку t3.small (2 vCPU, 2 GB) або t3.medium (2 vCPU, 4 GB) — нормальний старт. Обери AMI зі своєю ОС (Ubuntu, Amazon Linux, Debian).
Встанови свій стек — так само як робиш це на VPS. nginx, PHP-FPM, Node, Python, що завгодно. Якщо маєш скрипти провіжнінгу (Ansible, bash-скрипт) — зараз час їх використати. Якщо не маєш — зараз час їх написати. Ручне налаштування сервера, який не можеш відтворити — це технічний борг.
Залий код додатку. Налаштуй підключення до бази (ендпоінт RDS замість localhost чи старого IP). Перевір, що додаток працює.
Важливо: Не давай цьому інстансу публічний IP. Трафік з інтернету повинен іти через лоад-балансер (ALB), а інстанс — сидіти в приватному сабнеті. Навіть якщо у тебе один сервер.
Крок 5: Лоад-балансер та HTTPS
Постав Application Load Balancer (ALB) у публічних сабнетах. Підключи до нього EC2-інстанс як таргет. Налаштуй лісенер на порті 443 (HTTPS) із сертифікатом із AWS Certificate Manager — сертифікати ACM безкоштовні та автоматично оновлюються. Прощавай, ручне оновлення Let's Encrypt.
Додай редирект із HTTP (порт 80) на HTTPS. Готово — додаток доступний через інтернет, через ALB, з SSL.
ALB коштує ~$22–27/місяць (фіксована плата + плата за трафік). Це витрата, якої на VPS не було — але натомість отримуєш: автоматичний health check, можливість додати другий EC2 у майбутньому без зміни конфігурації, і розділення публічного трафіку від додатку.
Крок 6: Статичні файли та CDN
Якщо додаток сервірує статичні файли (картинки, CSS, JS, аплоади) безпосередньо з сервера — перенеси їх на S3 + CloudFront.
Створи S3-бакет. Залий туди статику. Підніми CloudFront-дистрибуцію, що роздає контент із бакету. Зміни в додатку URL-и статичних ресурсів так, щоб вони вказували на CloudFront замість сервера.
Результат: файли летять з найближчого до користувача edge location, сервер додатку розвантажений, сторінка вантажиться швидше. Для українських користувачів CloudFront сервірує з найближчих точок — це помітно швидше, ніж із Франкфурту напряму. S3 + CloudFront для типового додатку МСБ — це кілька доларів на місяць, мізерна ціна за великий виграш.
Крок 7: DNS та переключення
Найнапруженіший момент психологічно, хоча технічно — простий.
Перед переключенням знизь TTL записів до 60 секунд — зроби це за 24–48 годин до дня Х, щоб старий TTL встиг протухнути в усіх резолверах. Після переключення користувачі потраплять на новий сервер протягом хвилини, а не годин.
Зміни A-запис (або CNAME) так, щоб вказував на ALB. Якщо переносиш DNS на Route 53 — гарний момент. Якщо залишаєш DNS у поточного реєстратора — просто зміни запис.
Протягом кількох годин після переключення — моніторь. Перевіряй логи, час відповіді, чи не задихається база, чи не летять 5xx. Тримай старий сервер увімкненим ще хоча б тиждень. Якщо щось піде не так — відкат DNS займе хвилину.
Крок 8: Моніторинг та бекапи
На VPS-і, мабуть, моніторинг виглядав як «заходжу і дивлюся, чи працює». На AWS можна зробити це нормально.
CloudWatch дає базові метрики безкоштовно: CPU, мережевий трафік, стан інстансу. Додай алерти на CPU > 80% та на status check failed — нехай летять листи. Налаштуй Log Groups у CloudWatch Logs, щоб логи додатку не зникали після рестарту інстансу.
Бекапи: RDS робить автоматичні снепшоти раз на добу — переконайся, що ретенція налаштована (7 днів — мінімум). Для EC2 розглянь автоматичні AMI-снепшоти (через AWS Backup або простий крон).
Що піде не так: список проблем, до яких варто бути готовим
Не лякаємо — просто хочемо, щоб не було сюрпризів.
Права на файли та користувачі. AMI на AWS можуть мати іншого дефолтного юзера, ніж твій VPS (ec2-user, ubuntu замість root). Права на файли додатку можуть посипатися. Перевір після заливки.
Часові зони. EC2-інстанси за замовчуванням мають UTC. Якщо додаток залежить від часової зони (крони, логування, відображення дат) — встанови явно або обробляй у конфігурації додатку.
Підключення до бази. На VPS-і база була на localhost із латенцією 0 мс. На RDS — на окремій машині з латенцією 1–2 мс. Для 99% додатків це непомітно, але якщо додаток робить сотні запитів до бази на один реквест — різницю відчуєш.
Ліміти відправки пошти. AWS за замовчуванням блокує порт 25 (SMTP) на EC2-інстансах. Якщо додаток шле листи напряму із сервера — переходь на SES або зовнішній сервіс (Mailgun, Postmark, SendGrid). Це в будь-якому разі краща опція.
Security Groups. AWS за замовчуванням блокує весь вхідний трафік. Треба явно відкрити порти (80, 443 для ALB, 22 для SSH із твого IP). Не відкривай SSH на 0.0.0.0/0 — це запрошення для ботів.
Витрати на трансфер даних. Вхідний трафік у AWS — безкоштовний. Вихідний — платний. При типовому додатку МСБ це центи, але якщо роздаєш багато файлів (відео, важкий медіаконтент) — порахуй заздалегідь.
Скільки це буде коштувати: реалістичний рахунок
Типова українська компанія після lift-and-shift міграції, один веб-додаток:
EC2 t3.small (24/7): ~$18/місяць on-demand, ~$12 із Savings Plan. ALB: ~$22/місяць. RDS db.t4g.micro Single-AZ: ~$13/місяць. S3 + CloudFront: ~$3–5/місяць. Route 53: ~$1/місяць. CloudWatch (базовий): безкоштовно. NAT Gateway (якщо потрібен): ~$38/місяць.
Усього без NAT: ~$55–70/місяць. З NAT Gateway: ~$90–110/місяць.
Порівняй із тим, скільки платиш за поточний VPS. Hetzner CX31 коштує ~€7/місяць, HOSTiQ VPS — від $5–15/місяць. AWS буде дорожчим за базовий VPS — це факт. Але ти отримуєш за це: автоматичні бекапи бази, безкоштовний SSL із авто-оновленням, моніторинг, можливість масштабування, і — що для українських компаній часто вирішальне — інфраструктуру, яка не залежить від стану енергомережі в Україні. Твій сервер у Франкфурті працює, навіть коли в Києві немає світла.
Якщо твій VPS коштує $5–15/місяць і чудово працює — подумай двічі, чи потрібна міграція. Якщо ж сервер регулярно падає, бекапів немає, а кожен збій — це години простою і втрачені гроші — міграція окупиться в перший же місяць.
Графік: скільки це реально займає
Для типового додатку (один сервер, одна база, стандартний стек):
Інвентаризація та планування: 1–2 дні. Налаштування акаунту AWS, VPC, security groups: пів дня. Підняття RDS та міграція бази: пів дня — один день. Підняття EC2, інсталяція стеку, заливка коду: 1 день. ALB, SSL, CloudFront: пів дня. Тести: 1–2 дні. Переключення DNS та моніторинг: 1 день.
Реально: робочий тиждень — не обов'язково фулл-тайм, але розтягнутий на 5–7 днів. Якщо робиш це вперше, додай буфер на навчання — два тижні це безпечне припущення.
Не плануй міграцію на п'ятницю ввечері. Не плануй у пік сезону. Найкращий момент — спокійний тиждень, коли трафік низький і команда має час реагувати.
Після міграції: що далі
Lift-and-shift зроблено. Додаток працює на AWS. Тепер можна — у своєму темпі — оптимізувати:
Перейди на Savings Plans або Reserved Instances, коли переконаєшся, що конфігурація стабільна. Економія 30–40% на EC2 та RDS.
Розглянь контейнеризацію (ECS Fargate), якщо хочеш відв'язатися від конкретного EC2-інстансу та спростити деплойменти.
Перенеси більше логіки на керовані сервіси: SES замість власного SMTP, ElastiCache замість Redis на EC2, CloudWatch Logs замість логів на диску.
Налаштуй auto-scaling — навіть простий, який додає другий EC2 при високому CPU — щоб пережити несподівані сплески трафіку без ручного втручання.
Кожна з цих оптимізацій — окремий невеликий проєкт. Жодна не є терміновою в день міграції.
В Otocolobus ми проводимо міграції на AWS для компаній різного масштабу — від однієї аплікації до десятків мікросервісів. Якщо хочеш, щоб хтось зробив це за тебе (або разом із тобою) — напиши нам. Скажемо чесно, чи має сенс міграція у твоєму випадку — і скільки це буде коштувати.