Конфиденциальные вычисления на VPS: как это работает

Что на самом деле означает конфиденциальные вычисления на VPS

Конфиденциальные вычисления на VPS означают, что процессор шифрует оперативную память вашей виртуальной машины с помощью ключа, который никогда не попадает к гипервизору. Благодаря этому оператор физического сервера не может прочитать данные, с которыми работает ваш сервер. Почти ни один VPS, продаваемый сегодня, не работает таким образом. На обычном VPS гипервизор провайдера может прочитать любой байт памяти вашей гостевой системы, и шифрование диска этого не меняет.

Опубликованное руководство предназначено для двух категорий пользователей, и арендатор VPS не относится ни к одной из них. Материалы Canonical по конфиденциальным вычислениям — это либо образ, который вы запускаете у облачного провайдера (определенный размер инстанса в Azure или Confidential VM в Google), либо инструкция по превращению вашего собственного оборудования в хост для конфиденциальных ВМ. Оба варианта предполагают, что вы сами являетесь облачным провайдером или владельцем хоста. Ни один из них не объясняет человеку, арендующему VPS с 4 GB памяти, применимо ли это к серверу, за который он уже платит. Начните с модели угроз, так как любой практический ответ вытекает из нее.

Кто может прочитать память вашего VPS прямо сейчас

Ваш VPS является гостевой системой. Нечто другое создает его, выделяет ему память и планирует выполнение на физическом ядре. Большинство VPS на базе Linux работают через KVM, где оперативная память гостя — это обычная анонимная память, принадлежащая процессу QEMU на хосте. Пользователь root на хосте может прочитать память этого процесса так же, как и любого другого, через /proc/<pid>/mem или с помощью virsh dump, который записывает весь образ памяти гостя в файл. Ничто внутри вашей VM не может предотвратить это, и ничто внутри вашей VM не может это обнаружить, поскольку сторона, выполняющая чтение, контролирует уровень, который должен был бы заниматься обнаружением.

Это не недостаток конкретного провайдера. Это суть виртуализации. Задача гипервизора — владеть памятью гостя, поэтому возможность чтения этой памяти вытекает из самой архитектуры. Именно поэтому вопрос о том, безопасен ли VPS-хостинг для реальных рабочих нагрузок, зависит от практики оператора и контроля доступа персонала, а не от технологий: сама по себе технология никак не ограничивает оператора. Граница еще тоньше в тарифных планах на основе контейнеров, где гость LXC или OpenVZ использует общее ядро хоста, и хост может читать ваши процессы вообще без необходимости создания дампа. Эту разницу стоит понять до сравнения цен, и именно в ней заключается различие между виртуализацией KVM, Xen и LXC.

Почему полное шифрование диска не решает эту проблему

Полное шифрование диска на VPS полезно, но оно не затрагивает данную проблему. LUKS (Linux unified key setup) шифрует блоки при записи на диск и расшифровывает их при чтении. Для этого ключ тома должен находиться в оперативной памяти ядра всё время, пока том смонтирован. Таким образом, ключ находится в памяти, расшифрованные данные, проходящие через систему, также находятся в памяти, а память — это именно то, что хост может прочитать.

Шифрование данных в состоянии покоя (encryption at rest) действительно дает преимущество: диск, покинувший дата-центр, останется нечитаемым. Это защищает в случае возврата неисправного накопителя поставщику или если кто-то забудет об отсоединенном резервном томе. Это риски, отличные от чтения данных работающей гостевой системы работающим хостом. Оба случая продаются под одним и тем же маркетинговым термином, поэтому утверждение «все наши хранилища зашифрованы в состоянии покоя» является правдой, которая отвечает на другой вопрос.

Существует вторая ловушка, специфичная для арендованных машин. Шифрование корневой файловой системы означает, что кто-то должен вводить парольную фразу при каждой загрузке. Если хранить её на той же машине в файле ключа или в незашифрованном initramfs, хост сможет её прочитать. Если вводить её в консоль, управляемую провайдером, хост также сможет её перехватить. Если получать ключ при загрузке из другого места, вы лишь переносите доверие, а не устраняете его, так как сервис, выдающий ключ, теперь должен каким-то образом убедиться, что запрашивающая машина — именно та, за которую она себя выдает. Это последнее требование и есть та самая проблема, для решения которой была создана аттестация (attestation).

Что на самом деле делают AMD SEV-SNP и Intel TDX

Это две разные технологии, и их разделение — большая часть успеха: шифрование памяти и удаленная аттестация.

Сначала о шифровании памяти. AMD SEV-SNP (Secure Encrypted Virtualization with Secure Nested Paging) предоставляет каждой гостевой системе собственный ключ шифрования памяти. Ключ хранится в AMD Secure Processor — отдельном ядре на том же кристалле, к которому гипервизор не имеет доступа. Контроллер памяти шифрует данные при записи и расшифровывает их при чтении только для владельца — гостевой системы. Хост по-прежнему может сделать дамп этой памяти, но получит лишь зашифрованный текст.

Intel TDX (Trust Domain Extensions) достигает того же результата другим путем. Гостевая система становится доверенным доменом (trust domain), ее память помечается идентификатором закрытого ключа, а каждый переход в домен и обратно контролируется модулем TDX. Это подписанный код Intel, работающий в режиме процессора, недоступном для гипервизора. С точки зрения арендатора результат идентичен: гипервизор выделяет память и планирует выполнение на CPU, но не может прочитать содержимое памяти.

Часть SNP в названии SEV-SNP — это то, что часто упускают из виду, хотя именно она имеет решающее значение. Шифрование предотвращает чтение страниц хостом, но не мешает хосту их перемещать. Гипервизор, способный переназначать физические страницы гостя, может воспроизвести старое содержимое, сопоставить два адреса гостя с одной страницей или подменить страницу, которая была выгружена. Каждую из этих операций можно превратить в атаку, не расшифровывая данные. SNP добавляет таблицу обратного отображения (Reverse Map Table) — структуру, к которой процессор обращается при доступе, чтобы проверить, какой гость владеет страницей. Попытка переназначения, которую гость не запрашивал, приведет к ошибке вместо выполнения. У TDX есть собственный аналог. Без этого уровня целостности вы защищены от пассивного хоста, но не от активного.

Что не меняется ни в одном из случаев: хост по-прежнему запускает вашу VM, останавливает ее, решает, когда выделить ей ядро, и может ее удалить. Конфиденциальные вычисления (Confidential computing) обеспечивают конфиденциальность и целостность. Доступность и производительность остаются полностью под контролем хоста, поэтому время ожидания CPU из-за шумного соседа никак не затрагивается этими технологиями.

Что доказывает удаленная аттестация, чего не может обеспечить одно лишь шифрование

Вот пробел, который оставляет после себя шифрование в чистом виде. Вы запрашиваете у провайдера конфиденциальную виртуальную машину (VM). Вам её предоставляют. Как узнать, включено ли шифрование памяти? Вы не можете определить это, опросив гостевую систему, так как всё её представление о мире формируется гипервизором, а именно его вы и проверяете. Недобросовестный или просто неверно настроенный хост может выдать вам обычную VM, и на каждую команду внутри неё будет отвечать слой, которому вы не доверяете.

Удаленная аттестация замыкает этот цикл. Процессор самостоятельно формирует подписанный отчет. В SEV-SNP отчет подписывается ключом, уникальным для конкретного физического чипа, и заверяется цепочкой сертификатов AMD, которую вы получаете от AMD, а не от провайдера. TDX создает квоту (quote), подтвержденную ключом аттестации от Intel. Отчет содержит контрольную сумму запуска (launch measurement) — хеш содержимого памяти в момент старта VM, включающий прошивку, ядро, initrd и параметры командной строки ядра. Вы проверяете подпись вне этой машины, опираясь на корень доверия производителя кремния, и сравниваете полученное значение с тем, которое ожидали увидеть при загрузке.

Сформулируем выгоду прямо. Аттестация позволяет стороне, не находящейся на машине, решить, стоит ли доверять этой машине. Полезный паттерн здесь — выдача секретов по результатам аттестации: пароль от базы данных и ключи дешифрования вообще не хранятся в образе. Они находятся в стороннем сервисе, который передает их только после проверки свежего отчета и подтверждения ожидаемой контрольной суммы. Если хост загружает модифицированное ядро или запускает VM без SEV-SNP, контрольная сумма изменится или отчет не будет получен, и секрет не будет выдан. Шифрование без аттестации защищает данные от хоста, которому вы уже решили доверять. Аттестация позволяет вам больше не делать этот выбор.

Инструментарий открыт, и вы можете его изучить. Инструмент командной строки snpguest взаимодействует с устройством /dev/sev-guest внутри гостевой системы AMD, запрашивает отчет и проверяет его по цепочке сертификатов. Здесь важны детали платформы: в конфиденциальных VM на Azure это устройство не предоставляется гостю обычным способом, поэтому для инструмента требуется другая сборка и другой флаг. Аттестация работает, но пока не везде одинаково.

От чего confidential computing вас не защищает

Компрометация гостевой системы. SEV-SNP защищает вашу виртуальную машину извне. Технология никак не ограничивает злоумышленника, который уже находится внутри, так как для процессора этот злоумышленник — это вы. Уязвимое веб-приложение без патчей или выход из контейнера в ваше собственное ядро работают на конфиденциальной виртуальной машине точно так же, как и на обычной. Шифрование теперь работает на пользу взломщика, поскольку хост не может просмотреть память, чтобы помочь вам. Восстановление VPS после компрометации не становится проще из-за того, что оперативная память была зашифрована.

Ваше собственное приложение. Граница защиты заканчивается на краю виртуальной машины. Данные, которые ваш код записывает в лог-файл или отправляет во внешний API, покидают TEE (trusted execution environment) — так называется защищённая область. Зашифрованная память не проводит аудит вашего кода.

Кража учётных данных. Отчёт об аттестации подтверждает, какое программное обеспечение было загружено. Он ничего не говорит о том, кто вошёл в систему после этого. Утекший SSH-ключ открывает конфиденциальную виртуальную машину так же быстро, как и любую другую, поэтому усиление защиты SSH на VPS остаётся более приоритетной задачей почти для всех читателей этого текста.

Всё, что не является оперативной памятью. SEV-SNP и TDX шифруют RAM. Ваш виртуальный диск, сетевой трафик, снимки состояния (snapshots) и резервные копии не защищены, если вы не зашифруете их самостоятельно. В продуктах hyperscaler, предлагающих конфиденциальные виртуальные машины, диск с ОС обрабатывается отдельными механизмами с собственным управлением ключами именно потому, что возможности процессора на него не распространяются.

Физические атаки — самый сложный момент. Ряд опубликованных исследований показал, что шина памяти является уязвимым местом. BadRAM (CVE-2024-21944, 2024) использовал вмешательство в чип SPD на модуле памяти, чтобы заставить процессор подменять физические адреса, используя детали стоимостью около десяти долларов. Battering RAM (2025) разместил интерпозер стоимостью менее пятидесяти долларов между процессором и памятью DDR4, что позволило обойти проверки подмены при загрузке, добавленные в ответ на предыдущие атаки. TEE.fail (2025) перенёс эту идею на DDR5 и сообщил об извлечении секретных ключей, включая ключи аттестации, из полностью обновлённых серверов Intel TDX и AMD SEV-SNP. DDRop (раскрыто в сентябре 2026 года) использовал интерпозер DDR5 стоимостью менее двухсот долларов, чтобы заставить записи в память бесследно исчезать; на Intel TDX исследователи подделали отчёты аттестации, а на SEV-SNP скопировали содержимое страниц жертвы. Детерминированное шифрование памяти также вносит свой вклад: идентичный открытый текст по одному и тому же адресу создаёт идентичный шифротекст, что само по себе стало основой для атак по сторонним каналам. Каждая из этих атак требует физического доступа к машине, пусть даже кратковременного. Обратите внимание, кого это описывает. Две из них затронули саму аттестацию, поэтому отчёт с машины, к которой кто-то имел физический доступ, является менее надёжным доказательством, чем кажется. Confidential computing переводит хост от возможности прочитать вашу память одной командой к необходимости использовать аппаратное обеспечение, физический доступ и усилия. Это реальное и значительное улучшение, но это более скромное утверждение, чем то, что хост не может прочитать память вовсе.

Можно ли сегодня купить конфиденциальный VPS

Конфиденциальные виртуальные машины (Confidential VM) — это преимущественно продукт гиперскейлеров, хотя ситуация меняется. Microsoft Azure продает инстансы с поддержкой SEV-SNP и TDX. Google Cloud предлагает Confidential VM. AWS предоставляет опцию AmdSevSnp CPU для трех семейств инстансов (m6a, c6a и r6a), доступную только при совместной аренде (shared tenancy) в регионах US East (Ohio) и Europe (Ireland) или на выделенных хостах (Dedicated Host) в любом коммерческом регионе. За пределами гиперскейлеров список невелик, но реален. Компания VPSBG анонсировала поддержку SEV-SNP на своих облачных серверах 1 апреля 2025 года, и по состоянию на 12 октября 2026 года на их сайте заявлена поддержка SEV-SNP как для линейки Cloud VPS, так и для VDS, с возможностью ручной аттестации изнутри гостевой системы. IONOS Cloud продает продукт Confidential VM на базе оборудования с SEV-SNP, который в настоящее время доступен только в дата-центре во Франкфурте (de/fra/2) и тарифицируется в зависимости от конфигурации оборудования. Большинство независимых хостинг-провайдеров VPS до сих пор не предлагают такую услугу, поэтому разумнее уточнить наличие поддержки напрямую, чем делать предположения.

Причины этого носят структурный характер, и их понимание поможет правильно интерпретировать полученный ответ.

• Требуется специфическое оборудование. Для SEV-SNP нужны процессоры AMD EPYC третьего поколения или новее, для TDX — современные Intel Xeon Scalable. Парк оборудования, закупавшийся годами исходя из стоимости ядра, является неоднородным, поэтому данная функция может присутствовать на одних узлах и отсутствовать на других.
• Хостовое программное обеспечение должно быть актуальным. Ubuntu поддерживает гостевые системы SEV-SNP начиная с версии 24.04 LTS, однако поддержка на стороне хоста (включение в QEMU и прошивке OVMF) появилась позже, в 25.04. Это новее, чем стек, используемый на стабильных хостинговых платформах.
• Усложняется «живая» миграция (live migration). Перенос работающей гостевой системы между хостами требует копирования памяти, а хост не может прочитать содержимое этой памяти. Провайдеры используют «живую» миграцию для освобождения узлов при обслуживании, поэтому отказ от неё меняет принципы управления всей платформой.
• Снижается плотность размещения. Количество конфиденциальных гостевых систем, которые может одновременно запустить один хост, ограничено на аппаратном уровне и значительно ниже, чем количество обычных виртуальных машин на крупном узле. Низкие цены на VPS строятся именно на высокой плотности.
• Аттестация создает постоянную нагрузку на службу поддержки. Отчет бесполезен, если арендатор не может получить цепочку сертификатов и не знает, каких показателей ожидать, поэтому провайдер обязан публиковать и поддерживать данные, которые меняются с каждым обновлением прошивки.

Все вышесказанное не является претензией к какому-либо провайдеру. Это объясняет, почему данная функция доступна именно в таком виде.

Как узнать у хостинг-провайдера о доступности SEV-SNP или TDX

Службы поддержки отвечают на заданный вопрос, и расплывчатый вопрос получает успокаивающий ответ, который не несет смысла. Спросите, шифруются ли ваши данные, и вам ответят, что все данные шифруются в состоянии покоя — это правда, но речь идет о дисках. Задайте узкоспециализированный вопрос. Эти пять вопросов стоит отправлять именно в таком виде.

1. Предлагаете ли вы инстансы с включенными AMD SEV-SNP или Intel TDX для гостевой системы и на каких тарифных планах?
2. Выбирается ли это для каждого инстанса при создании или это свойство хоста, которое я не могу изменить?
3. Могу ли я изнутри гостевой системы получить отчет об аппаратной аттестации и присутствует ли /dev/sev-guest?
4. Предоставляете ли вы или пробрасываете цепочку сертификатов, необходимую для проверки этого отчета у производителя процессора?
5. В каких регионах и на каких поколениях хостов это доступно и ограничивает ли это изменение размера или миграцию инстансов?

Интерпретируйте ответы следующим образом. Ответ «да» на первый вопрос при ответе «нет» на вопросы 3 и 4 означает, что у вас есть шифрование памяти, которое вы не можете проверить. Это полезно против перепродажи модуля памяти, но почти бесполезно против самого хоста, так как вы полагаетесь на слова оператора о функции, цель которой — устранить необходимость доверять оператору. Ответ, в котором говорится о соответствии стандартам или о шифровании в целом, означает «нет». Отсутствие ответа на пятый вопрос обычно означает доступность только для одного семейства инстансов в одном регионе.

Что касается цены и выбора инстансов, ожидайте более ограниченный ассортимент, а не просто надбавку к стоимости. Конфиденциальные размеры инстансов обычно выделяются в отдельное семейство с меньшим количеством вариантов и регионов, и реальная цена часто заключается именно в этих ограничениях, а не в почасовой ставке. Рассчитывайте стоимость конкретного размера, который вы действительно будете использовать.

Как проверить уже имеющийся VPS

Эти команды выполняются внутри гостевой системы и занимают около минуты. Воспринимайте их вывод как важную подсказку, а не как окончательное доказательство, поскольку всё, что видит гостевая система, проходит через гипервизор.

systemd-detect-virt
systemd-detect-virt --cvm

Первая команда выводит технологию виртуализации, обнаруженную ядром. Вторая сообщает о технологии конфиденциальных виртуальных машин, используя значения, такие как sev, sev-es, sev-snp и tdx. --cvm — это более новый вариант, поэтому сначала выполните systemctl --version, если ваша система его не распознает.

sudo dmesg | grep -i -E 'sev|tdx|memory encryption'
sudo journalctl -k | grep -i -E 'sev|tdx|memory encryption'

Гостевая система с активным шифрованием памяти AMD выводит строку загрузки, начинающуюся с Memory Encryption Features active:, после которой перечисляются используемые технологии. Доверенный домен (trust domain) выводит собственные строки TDX во время ранней загрузки. Также выполните вариант journalctl, так как на сервере, работающем долгое время, кольцевой буфер dmesg мог перезаписаться и отбросить сообщения начальной загрузки.

grep -m1 ^flags /proc/cpuinfo | tr ' ' '\n' | grep -i -E 'sev|tdx'
ls -l /dev/sev-guest /dev/tdx-guest

Внимательно относитесь к флагам процессора. /proc/cpuinfo показывает модель процессора, которую решил представить гипервизор, поэтому флаг sev может означать, что кремний поддерживает эту функцию, но ваша виртуальная машина её не использует. tdx_guest — более прямой индикатор, так как этот флаг описывает саму гостевую систему. Файлы устройств — это то, что требуется инструменту аттестации: /dev/sev-guest на AMD и устройство гостя TDX на Intel. ls прямо сообщит об отсутствии файла, если его нет. На некоторых платформах устройство намеренно скрыто от гостевой системы, даже если виртуальная машина является конфиденциальной, поэтому данная проверка скорее подтверждает, чем опровергает наличие защиты.

Если ничего из этого не дало результатов, значит, ваш сервер не поддерживает данные функции. Это ожидаемый результат для обычного VPS-хостинга и не является признаком неисправности.

Что делать, если ответ отрицательный

Так и будет. Полезный ответ — не отказываться от вопроса, а уменьшить последствия утвердительного ответа. Несколько привычек дают основную часть результата, и ни одна из них не требует специального оборудования.

Шифруйте данные, покидающие сервер, непосредственно на сервере. В первую очередь это касается резервных копий. Такие инструменты, как restic и age, шифруют данные на клиенте до отправки в место назначения. Поэтому провайдер хранения получает шифротекст и никогда не получает ключ. Используйте TLS (transport layer security) и для трафика между собственными серверами, в том числе в частной сети провайдера. Частная сеть всё равно остаётся сетью, которой вы не управляете.

Не храните секреты в образах и репозиториях git. Секрет, встроенный в образ VM или отправленный в репозиторий, доступен всем, кто может прочитать соответствующий образ или репозиторий. Это гораздо более широкая группа, чем специалисты, эксплуатирующие гипервизор. Храните секреты в зашифрованном хранилище и расшифровывайте их во время развёртывания. Шифрование секретов с помощью Ansible Vault — это простой вариант без сложной инфраструктуры, которого достаточно для большинства небольших парков серверов.

Ограничивайте доверие к каждому серверу. Именно эта привычка меняет результат. Представьте, что злоумышленник прочитал всю память этой машины. Что он получит? Если среди полученного окажется ключ, расшифровывающий данные клиентов за десять лет, гипервизор — меньшая часть проблемы. Этот ключ находится на общедоступном веб-сервере. Выдавайте каждому серверу минимальные права, необходимые для его работы, устанавливайте короткий срок действия учётных данных и заранее отрабатывайте процедуру их ротации. Тогда компрометация памяти узла приведёт только к тем последствиям, которые уже возможны с этого узла.

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

Исправляйте именно то, что действительно атакует вас. Для почти каждого читателя реалистичный путь к компрометации — это сервис без установленных исправлений или украденные учётные данные, а не инженер в дата-центре, читающий RAM. Проверка сервера на известные CVE и что Ubuntu Pro добавляет к покрытию сервера исправлениями снизят риск сильнее, чем любая функция CPU. На чистой машине первые десять минут на новом VPS — самая дешёвая работа, которую вы когда-либо выполните.

Если у вас есть рабочая нагрузка, которой действительно нужна аппаратная граница доверия, изолируйте только её. Запустите эту часть на confidential VM у провайдера, который предоставляет такую возможность, или на оборудовании под вашим контролем. Остальные компоненты оставьте там, где это доступнее. Разделение системы по уровню чувствительности — обычный архитектурный подход. Он работает на любом хосте уже сейчас, чего нельзя сказать о confidential VPS.

FAQ

Может ли провайдер VPS читать память моего сервера?

На обычном VPS-хостинге — да. Гипервизор выделяет и отображает оперативную память гостевой системы, поэтому пользователь root на хосте может прочитать её, например, через процесс QEMU по пути /proc/<pid>/mem или путём создания дампа памяти гостя в файл. Внутри гостевой системы невозможно заблокировать или обнаружить такие действия. Технологии AMD SEV-SNP и Intel TDX существуют для устранения этой возможности, но они не предлагаются в большинстве тарифных планов VPS. То, что ограничивает доступ провайдера на обычном VPS, — это внутренние контроли и политика персонала провайдера, а не технологии.

Защищает ли полное шифрование диска данные на VPS от хостинг-провайдера?

Не во время работы сервера. Ключ тома должен находиться в памяти ядра, чтобы файловая система была доступна для чтения, поэтому и ключ, и проходящие через него данные находятся в памяти, которую может прочитать хост. Шифрование диска защищает данные в состоянии покоя, например, если накопитель выходит из строя и возвращается поставщику или если резервный том отключается и о нём забывают. Эти риски стоит учитывать. Они отличаются от риска чтения данных работающего гостя работающим хостом.

Как проверить, использует ли мой VPS AMD SEV-SNP или Intel TDX?

Выполните systemd-detect-virt --cvm внутри гостевой системы, затем sudo dmesg | grep -i -E 'sev|tdx' и ls -l /dev/sev-guest. Гостевая система с активным шифрованием памяти AMD выводит строку загрузки, начинающуюся с Memory Encryption Features active:, а доверенный домен Intel содержит флаг tdx_guest в /proc/cpuinfo. Каждый из этих ответов поступает к вам через гипервизор, поэтому они являются лишь индикативными. Единственным доказательством является подписанный отчет об аттестации, который вы проверяете по цепочке сертификатов производителя процессора вне этой машины.

Что дает аттестация в дополнение к шифрованию памяти?

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

Стоит ли доплачивать за конфиденциальные вычисления?

Это зависит от того, входит ли оператор инфраструктуры в вашу модель угроз. Для регулируемых данных или ключей, защищающих данные других людей, это единственный доступный технический ответ, и стоимость конфиденциального экземпляра у гиперскейлера невелика по сравнению с альтернативами. Для личного сайта или небольшого сервиса те же деньги принесут больше безопасности, если потратить их на исправление уязвимостей и гигиену учетных данных. Честно определите, что именно вы запускаете, прежде чем выбирать аппаратные функции.