Как перенести сайт и сервер с AWS на свой VPS

MAATRIX

AWS мощен, но его сложность и непредсказуемый счёт заставляют многих искать простую альтернативу — обычный VPS с фиксированной ценой и полным контролем. Добавьте к этому проблемы с оплатой AWS из России, и переезд становится не роскошью, а необходимостью. Перенос с AWS на свой сервер проходит по понятной схеме: снять данные с EC2 и RDS, развернуть на новом месте, переключить домен без простоя. Ниже пошаговое руководство, как перенести сайт и сервер с AWS на свой VPS.

Коротко: план переезда

Общая канва проста. Забираете с инстанса EC2 файлы и код, из базы (на самом инстансе или в RDS) — дамп. Поднимаете на новом VPS тот же стек и разворачиваете копию. Проверяете её по IP, не трогая домен. Переключаете DNS в самом конце. Инфраструктура на AWS остаётся включённой до полного переезда, так что простоя нет и откат возможен всегда.

Особенность AWS — данные и сервисы могут быть раскиданы по разным управляемым компонентам: код на EC2, база в RDS, файлы в S3, DNS в Route 53, балансировка в ELB. Переезд с AWS — это в первую очередь инвентаризация этих компонентов, а уже потом выгрузка. Чем точнее вы соберёте карту зависимостей, тем ровнее пройдёт переезд, потому что на обычном VPS все эти роли совмещаются в одном сервере.

Что нужно перенести

Составьте полную карту вашей инфраструктуры AWS. Типовой набор: инстанс EC2 (ОС, код, конфиги), база в RDS или на самом инстансе, файлы и медиа в S3, DNS-зона в Route 53, сертификаты, переменные окружения и секреты, IAM-доступы, cron или запланированные задачи. На AWS роли разнесены по сервисам, и легко упустить компонент, о существовании которого вспоминаешь, только когда что-то ломается.

Отдельно отметьте, что живёт в managed-сервисах: RDS — это база, которую вы выгрузите дампом, но подключение поднимете сами; S3 — хранилище, содержимое которого переносится отдельной синхронизацией; SQS, SES, ElastiCache и прочее — аналоги на своём сервере вы разворачиваете сами (Redis, локальная отправка почты, очереди). Полная карта на старте — залог того, что после переезда приложение не окажется без привычного сервиса, который на AWS работал незаметно.

Забираем данные с AWS

С доступом по SSH к EC2 выгрузка стандартна. Синхронизируйте файлы и снимите дамп базы:

# файлы с EC2 на новый сервер
rsync -avz -e "ssh -i key.pem" ec2-user@EC2_IP:/var/www/ /var/www/
# дамп базы: с RDS или локальной
mysqldump -h RDS_ENDPOINT -u admin -p --single-transaction db_name > db.sql

Если база в RDS, дамп снимается с её эндпоинта тем же mysqldump. Содержимое S3 переносите отдельно — синхронизацией бакета в каталог нового сервера. Не забудьте про конфиги EC2: настройки веб-сервера, systemd-юниты, переменные окружения. Собрав код, дамп базы и файлы из S3, вы получили полную копию, которая больше не зависит от AWS.

Поднимаем всё на новом VPS

На новом сервере воспроизведите стек. Совпадение версий ПО с тем, что было на EC2 и в RDS, важно для совместимости:

apt update && apt install nginx php-fpm php-mysql mariadb-server -y
mysql -e "CREATE DATABASE db_name CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci"
mysql db_name < db.sql

Разложите код, восстановите конфиги, впишите реквизиты новой локальной базы вместо RDS-эндпоинта, положите файлы из S3 в нужный каталог (или поднимите совместимое объектное хранилище, если приложение жёстко завязано на S3-API). Настройте cron и системные сервисы. После этого приложение работает по IP нового сервера. Прогоните его полностью, включая интеграции, — сейчас лучшее время найти всё, что было завязано на managed-сервисы AWS.

Проверка и переключение домена

Для теста под доменом без правки DNS пропишите домен и новый IP в локальный hosts. Убедившись, что копия исправна, снизьте TTL до 300 секунд за сутки. Если DNS-зона была в Route 53, вы либо продолжите управлять ей там, поменяв A-запись, либо перенесёте зону к другому DNS-провайдеру:

dig +short example.com A
dig @8.8.8.8 example.com A

В момент переезда сделайте финальную досинхронизацию и поменяйте A-запись на новый IP. Низкий TTL даст быстрое переключение. Инфраструктуру AWS не выключайте пару дней — часть трафика придёт на старый адрес из кэша. Выпустите или перенесите сертификаты, проверьте HTTPS. Если использовался SES для почты — настройте отправку на новом сервере и перенесите MX, если почта обслуживалась через AWS.

Особенности переезда именно с AWS

Ключевых моментов несколько. Первый — оплата: счёт за AWS из России оплатить трудно, и это часто и есть главная причина переезда. Второй — стоимость исходящего трафика: на AWS платный egress может составлять заметную долю счёта, тогда как у VPS-провайдеров трафик обычно включён в тариф щедрым лимитом, что для проектов с большой отдачей даёт прямую экономию. Третий — сложность: десяток связанных сервисов AWS на обычном VPS сворачивается в один управляемый сервер, что проще в поддержке для команды без выделенного DevOps.

Оцените размен честно. AWS даёт эластичность, автоскейлинг и глобальную инфраструктуру — но платите вы за это всегда, даже если реально не используете. Для проекта с ровной нагрузкой фиксированный VPS с понятной ценой закрывает задачу дешевле и проще, а свободы root у вас столько же. Если же вам критична именно эластичность под резкие пики, это стоит взвесить отдельно — переезд оправдан там, где сложность и цена AWS не окупаются реальными потребностями.

Куда переезжать и как оплатить

Локацию выбирайте под аудиторию. Для доступа к зарубежным сервисам и иностранной аудитории — US и UK с чистыми IP. Для российских проектов — RU с минимальным пингом и соответствием 152-ФЗ. У MAATRIX есть все три локации, а оплата — картой российского банка, по СБП, криптовалютой или токеном MAAT. Именно это снимает главную боль ухода с AWS: платить за новый сервер можно из России привычными способами, без иностранной карты.

Новый VPS у MAATRIX поднимается за минуты, а инфраструктура AWS всё время переезда остаётся страховкой. После переключения домена вы получаете предсказуемую фиксированную цену вместо пугающего счёта, включённый трафик вместо платного egress и простой в поддержке сервер — то, ради чего и уходят с облачного гиганта.

Частые вопросы