AWS: тонкости и хитрости

Amazon
Amazon Web Services - тонкости и хитрости
AWS — одна из популярнейших облачных платформ. Она предоставляет все инструменты для построения облачного сервиса, которые вам могут понадобиться — хранилище объектов (S3), серверы (EC2), базы данных (RDS), инструменты обработки платежей (DevPay), виртуализованные сетевые инструменты (VPC и AWS Direct Connect), протоколы размещения контента (CDN), мониторинга (CloudWatch), очередизации (SQS), и много чего еще. В этом материале будут рассматриваться советы, рекомендации и тонкости, которые могут помочь в создании собственной инфраструктуры на базе AWS.

Биллинг


AWS начисляет выплаты на конец месяца, и как правило услуги сервисов предоставляются «по требованию», то есть вы платите только за те мощности, которые используете. Например, плата за использование использование серверов EC2 начисляется по фиксированной ставке за количество часов работы. То есть если серверы работали 6 часов, то только за них и придется платить.

Увы, AWS не позволяет ограничить расходы на месяц какой-то фиксированной суммой, по достижении которой работа сервисов блокировалась бы. Нужно следить за количеством запущенных серверов и адекватности их текущим нагрузкам, иначе счет в конце месяца может неприятно удивить. Аналогичным образом тарифицируется потребление полосы пропускания — одного заметного пика нагрузки достаточно чтобы заметно опустошить кошелек. AWS позволяет устанавливать предупреждения о перерасходе средств — например, CloudWatch прогнозирует ваши будущие расходы не основании текущих и поднимает тревогу, если они заметно превышают этот предел. В качестве альтернативы, можно просто установить определенную сумму расходов в долларах, по достижении которой вам отправляется сообщение.

Обязательно установите такие предупреждения

Еще лучше — установите несколько таких предупреждений на разных порогах, например: $1/мес, $10/мес, $50/мес, $100/мес, $250/мес, $500/мес, и $1,000/мес. Шкала может быть разной в зависимости от ресурсоемкости задач. Так вы сможете отслеживать перерасход и вовремя вычислить, что это — нормальное явление чуть большей чем обычно нагрузки на ресурсы или сбой (выделить 10 серверов вместо одного на удивление легко — достаточно одной ошибки в скрипте автоматизированного развертывания).

Если ваш сервис потребляет ресурсы относительно равномерно на протяжении месяца то можно установить другие типы предупреждений. Когда расходы стабилизируются и будет выработано более-менее точное среднее значение месячных расходов, то можно установить предупреждение на этой сумме, а также на 1/3 и 2/3 от этой суммы. Отслеживая когда эти предупреждения поступят можно судить о том, на сколько стабильно потребление ресурсов. Если все как обычно, то они должны прийти приблизительно в 10-х и 20-х числах месяца, если предупреждения приходят заметно раньше или позже, значит привычный паттерн загрузки сбился и стоит выяснить почему.

Безопасность


Не будем «растекаться мыслью по древу», а сразу перечислим наиболее важные элементы безопасности любого облачного сервиса. Это:

Мультифакторная авторизация

Также известная как двухфакторная авторизация, потому что большинство современных систем базируются на двух. Это система авторизации, которая совмещает несколько разных факторов, то есть подходов. Как правило, это факторы «что-то, что пользователь знает» (пароль) и «что-то, чем пользователь владеет» (то есть аппаратный токен, либо генератор одноразовых тайм-кодов на смартфоне либо телефон, на который приходят эти коды). Даже если один из факторов будет скомпрометирован (телефон/токен украдут, пароль или хэш будут похищены при хакерской атаке), его будет недостаточно, чтобы получить доступ.

AWS поддерживает мультифакторную авторизацию, используются пин-коды стандарта TOTP. Поддерживается авторизация как с помощью бесплатных программных генераторов кодов (например, Google Authenticator, который устанавливается в виде приложения на смартфоны), так и аппаратные токены (стоимость от $12.99). Мультифакторной авторизацией стоит пользоваться везде, где она только есть, так что включите ее немедленно как только зарегистрируетесь в Amazon.

SSH

В качестве меры предосторожности лучше использовать уникальные ключи SSH для не связанных друг с другом проектов. Впоследствии их будет гораздо проще удалить когда они станут не нужны. Для каждого нового сервера есть смысл создавать новую пару ключей (а источником ключа должен служить достаточно длинный пароль). Если несколько человек подключаются к одним и тем же серверам, то у каждого пользователя должна быть своя пара SSH-ключей.

Не стоит указывать файлы ключей в командной строке лучше добавить их в файл конфигурации ~/.ssh/config — так они будут использоваться автоматически. Вот пример:

Host ec2-10-20-30-40.compute-1.amazonaws.com
User ubuntu
IdentityFile "~/.ssh/my-ec2-private-key" 

По умолчанию SSH будет отсылать все доступные в связке или указанные в файле конфигурации ключи на удаленный сервер. Если ключей слишком много, то возможно, что сервер выдаст ошибку при подключении:

Too many authentication failures for username 

С точки зрения удаленного сервера каждый ключ рассматривается как попытка подключения. Если в связке слишком много ключей, то в тех запросах, которые пройдут, нужного ключа может и не оказаться. Чтобы принудительно отсылать только ключи, которые относятся к конкретному серверу, к ~/.ssh/config нужно добавить следующую строку:

Host *
IdentitiesOnly yes 

Такая команда подразумевает, что SSH-ключ, который используется со всеми серверами должен указываться отдельно (а не наоборот, как по умолчанию). Если нужно ограничить действие правила до какого-то определённого множества серверов, то в строке Host символ «*» нужно заменить на требуемую область адресов, например *.example.com.

VPC

Virtual Private Coud (Виртуальное частное облако, VPC) — одна из возможностей EC2, которая позволяет объединить группу серверов в виртуальную сеть. Таким образом можно просто отделить некоторые компоненты вашей инфраструктуры от основного пула — например для создания внешней инфраструктуры, которая будет публично доступна из сети. Это основное предназначение — разделить инфраструктуру на две части, публичную и частную. В публичной части находятся все компоненты сервиса, который вы создаете, все что будет доступно всем. Для веб-клиента, например, это веб-сервер и балансировщик нагрузки. Сервисы которые предназначены только для внутреннего использования (базы данных, кэширующие серверы) — размещаются в частной зоне, которая недоступна из публичного интернета напрямую.

Это одно из воплощений принципа наименьших привилегий, и если ваш сервис соответственно структурирован, стоит воспользоваться услугами VPC. В частности, если ваш сервис включает больше двух серверов, то скорее всего вам стоит им воспользоваться — в будущем такая компоновка облегчит вашу жизнь.

Хост-бастион

Чтобы получить доступ к компонентам частного сектора вашей VPC необходим хост-бастион. Это выделенный сервер, который будет работать как SSH-прокси, обеспечивая доступ к другим внутренним компонентам. Сам этот хост располагается в публичном секторе, он виден снаружи.

Почему стоит его использовать? В первую очередь потому что таким образом упрощается настройка сетевой безопасности при работе с AWS, и сильно уменьшается количество правил, которые нужно задать при настройке внешнего брандмауэра.

Хост-бастион настраивается так:

  1. Запускается новый сервер, он должен относиться к публичному сектору вашей VPC
  2. Создается группа безопасности Bastion SG и назначается новому серверу
  3. Настройки групп безопасности частного сектора вашего сервиса должна позволять входящий трафик с порта 22 (SSH) от группы Bastion SG
  4. В список контроля доступа группы Bastion SG добавляются «белые» IP-адреса, с которых вы будете соединяться с сервером.
SSH прокси-сервер не использует много ресурсов CPU и почти не занимает дискового пространства. Инстанс m1.micro (самый дешевый, предлагаемый Amazon отлично подойдет для таких целей, по нынешним расценкам он обойдется в ~$15/месяц, и это если заказывать использование «по требованию», с резервированием цену можно снизить до $7/месяц. Это сущие копейки по сравнению с сэкономленными на настройку систем безопасности деньгами.

Настройка фильтрации по «белым спискам»

Любой сервер с открытым в интернет портом 22 — магнит для хакеров, его будут атаковать все кому не лень. В основном это боты, которые пробуют логин брутфорсом, что естественно никогда не сработает если установить авторизацию только по SSH-ключам. Все же, это раздражает, да и лишние помехи и нагрузка на сеть.

Этого можно избежать, создав «белый список» IP-адресов, которые могут соединяться с сервером. Если у вашего интернет-подключения статический или «более-менее статический» (большинство адресов выделяемых кабельным модемам и DSL-линиям меняются не так уж часто), то можно настроить брандмауэры серверов так, чтобы они принимали SSH-соединение только с этих адресов. С любого другого адреса сервер будет невозможно даже обнаружить — даже сканирование портов ничего не даст так как первоначальное соединение с TCP-сокетом не будет установлено.

Настройка списков на большом количестве серверов — дело довольно-таки муторное, но так как внутренний сектор контактирует с интернетом только через хост-бастон, все проще — списки нужно настроить только на нем. Впоследствии, если понадобится связаться с сервером с нового адреса (например, вы работаете на ходу) можно внести в список новый адрес, но как только сеанс связи будет закончен — лучше снова убрать его.

Email


Amazon Simple Email Service (SES) — e-mail сервис Amazon, предназначенный только для отправки писем. С его помощью можно встроить e-mail функциональность в ваше приложение или сервис, можно также задействовать его через командную строку.

SES включается как стандартный STMP-интерфейс так и специфический программный API, разработанный Amazon. Из соображений портативности кода можно рекомендовать использовать SMTP. За каждую активацию сервиса начисляется плата, причем SMTP и API стоят одинаково. И все же лучше писать код под SMTP — меньше изменений придется вносить если вы решите сменить провайдера. Сервис не предназначен для массовых рассылок так что в умеренных масштабах (до 2000 сообщений в день) пользование им бесплатно, больше — $.10 за 1,000 сообщений плюс затраты на полосу пропускания.

Верификация

При настройке с нуля нужно будет сначала верифицировать e-mail с которого будет происходить рассылка. Например, если необходимо рассылать e-mail с адреса hello@example.com, то сначала нужно как-то подтвердить, что вы контролируете домен example.com. Для этого нужно подтвердить, что вы можете принимать письма на этот адрес. Также можно верифицировать весь домен сразу настроив TXT-записи чтобы верифицировать то, что вы хозяин этого домена.

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

DKIM and SPF

Чтобы увеличить вероятность того что отправляемые письма достигнут адресатов, а не осядут в спам-фильтрах необходимо развернуть и настроить протоколы DKIM и SPF на вашем домене. Каждый из них — дополнительная мера идентификации, применяемая для защиты от спамеров. Почитать о настройке этих протоколов можно в документации к AWS (SPF — docs.aws.amazon.com/ses/latest/DeveloperGuide/spf.html DKIM — docs.aws.amazon.com/ses/latest/DeveloperGuide/easy-dkim.html). Также (если вы этого еще не сделали) необходимо настроить DKIM и SPF для доменных e-mail серверов, если ваш сервер на Google Apps, то детали можно получить в документации Google (http://support.google.com/a/answer/174124).

Тестирование с помощью Port 25

Как только настройка будет закончена, стоит проверить что все работает как надо. Это просто сделать воспользовавшись услугами сервиса Port 25. Просто пошлите e-mail на адрес сервиса (инструкции здесь — www.port25.com/support/authentication-center/email-verification/) и через некоторое время сервис оповестит вас, правильно ли настроены SPF и DKIM, и как отображаются ваши сообщения — не помечены ли они как спам. Услугами Port 25 также можно воспользоваться чтобы верифицировать и свой личный e-mail. Достаточно вручную отослать сообщение на адрес Port 25 и подождать ответа.

EC2 (и как на нем сэкономить)


EC2 позволяет задействовать облачные мощности только тогда, когда они нужны, оплачивая использование почасовой основе. Такой паттерн использования более всего удобен для нагрузок, которые могут быстро и непредсказуемо варьироваться, но в то же время не постоянны. Пики и провалы. Вы платите только за то что используется.

Оборотная сторона медали — тарифы EC2 в целом выше чем у конкурентов. Но есть несколько тонкостей с помощью которых их можно сделать более демократичными.

Резервирование инстансов

Если тип вычислительной нагрузки подразумевает постоянную загрузку сервера, стоит обратить внимание на резервируемые инстансы. Тарифы на резервируемые инстансы могут быть гораздо ниже, но придется платить вперед.

Amazon предлагает три уровня загрузки: Light (самый дешевый), Medium, и Heavy (самый дорогой), каждый из уровней предлагается в резервирование на сроки от года (дешевле) до 3-х лет (дороже).

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

Например, стандартный инстанс m1.small стоит $.06/час («по требованию»). А вот если заказать трехгодичное резервирование по уровню «Light» (небольшие нагрузки) то стоимость за час упадает до $.027. Предполагая что сервер будет работать 24 часа в сутки (а зачем в противном случае резервировать?), экономия окупится уже за 4 месяца. Резервирование по плану использования «Heavy» немного отличается от «Light» или «Medium», так как вам придется платить за использование резервируемых инстансов вне зависимости от того, выполняют ли они в данный момент полезную работу или нет. То есть приобретая резервирование на 3 года по плану использования «Heavy», вы соглашаетесь оплачивать непрерывную работу этого инстанса в течении следующих 3-х лет.

Экономия может составлять от 25 до 65% по сравнению с ценами без скидок, точка окупаемости находится от трехмесячной отметки до года. Так что как только паттерны использования вычислительной мощности вашим сервисом более-менее определятся, стоит подумать о замещении инстансов, которые находятся в постоянном использовании на резервированные. Если нет желания связывать себя контрактом на длительное время, лучше придерживаться планов резервирования «Light» и «Medium». Скидки по ним не так заметны — 10-15%, но они оставляют больше пространства для маневра в будущем (переход на другие инстансы, смена провайдера etc).

Рынок резервируемых инстансов

Это место, где можно купить резервируемые другими инстансы или продать те которые вам уже не нужны. Так как резервирование не влияет ни на что кроме цены, то никакой разницы между купленными у Amazon и у третьих лиц инстансами нет. Главная (и в общем-то, единственная) разница в том, что длительность резервирования может быть практически любой, что очень удобно если паттерн использования не подразумевает традиционные рамки 1/2/3 года, которые предлагаются самим Amazon. Только внимательнее с ценами, иногда они бывают совершенно неадекватно завышенными относительно того что предлагает Amazon. Как правило, это кто-то пытается спекулировать.

Спот-инстансы

Спот-инстансы позволяют играть с ценой на излишки вычислительной мощности EC2. Пока установленная вами ставка выше чем текущая спотовая цена, спот-инстансы продолжают работать, а вы платите по меньшей ставке (то есть по спотовой цене). Как только цена увеличивается и перекрывает вашу ставку, ваши спот-инстансы могут быть отключены — что может произойти не сразу, но в любой момент.

Учитывая эти особенности, лучше всего для таких инстансов подходят задачи которые не хранят важную информацию о состоянии работающего приложения (и вообще какие-либо данные, которые могут быть утеряны) и хорошо масштабируются «на лету». Пример такой задачи — серверы непрерывного интегрирования, если один из серверов «упадет» и запустится снова часом позже — это не такая уж и большая трагедия. Главное, чтобы финальный билд был в порядке.

Есть и более интересные применения для спотов. Если полностью автоматизировать процесс их распределения и утилизации (то есть автоматизировать создание и работу групп безопасности, обработку пользовательских данных, написать скрипты автозапуска), то можно даже автоматически регистрировать эти спот-инстансы через Route53 DNS после чего они могут присоединиться к основному балансировщику нагрузки.

S3


S3 — хранилище объектов, предоставляемое Amazon. В нем можно хранить любые файлы размером до 5 Тб, файлы доступны по протоколам HTTP или HTTPS. Amazon утверждают, что сохранность данных в S3 гарантируется с вероятностью в 99.999999999% при доступности 99.99% рабочего времени. Для таких показателей услуги S3 стоят совсем недорого, к тому же Amazon периодически снижает цены.

API S3 позволяет тонко настраивать разграничение прав доступа к хранящимся данным. Например, есть объект который хранится в S3, но недоступен для публичного доступа. К нему можно временно получить доступ через подписанный URL. Таким образом можно создавать временные ссылки доступа к файлам пользователей, которые находятся в частных бакетах S3. Такое хорошо подходит для работы с веб-приложениями, например веб-клиентами облачных сервисов.

GPG

Если вы собираетесь хранить и работать с конфиденциальной информацией (например резервные копии баз данных, пароли и так далее), то их стоит шифровать еще перед загрузкой в S3. Проще всего это сделать воспользовавшись программным комплексом GPG.

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

# Указываем бакет/путь к нему на S3, где будет храниться резервная копия:
$ S3_PATH="s3://my-s3-bucket/path/to/backup/backup-$(date +%Y%M%d)"

# Создаем временный файл для шифрования:
$ GPG_TEMP_FILE=$(mktemp)

# Шифруем его GPG:
$ gpg --recipient aws.backup@example.com --output "$GPG_TEMP_FILE" --encrypt mydata.foo

# Загружаем через s3cmd:
$ s3cmd put "$GPG_TEMP_FILE" "$S3_PATH"

# Стираем временный файл:
$ rm "$GPG_TEMP_FILE" 

Единственный минус такого подхода — его будет невозможно прочитать на самом сервере S3. Ссылку на интересующие данные дать невозможно так как данные будут зашифрованы и нечитаемы без наличия специфического ПО. Прочитать их можно будет только загрузив эту резервную копию на локальный компьютер и расшифровав ее там. Как правило такое доступно только кому-то с соответствующим ключом и ПО для дешифровки. Как правило это ограничивает доступ к данным до тех, кому это действительно нужно (т.е. технический персонал сервисов).

Еще один вариант — указать конкретный ключ GPG через командную строку S3. В этом случае S3 будет автоматически шифровать все объекты, которые загружаются в хранилище этим ключом. Это удобно, так в этом случае нужно только указать ключ единожды, а все остальные операции шифровки будут происходить автоматически. Тем не менее, предварительное шифрование надежней хотя бы потому что в этом случае данные передаются по сети уже в шифрованном виде.

Статическое шифрование

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

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

Время хранения объектов

Использовать S3 в качестве хранилища для резервного копирования очень удобно, но рост расходов вас не порадует. По умолчанию S3 не удаляет никакие объекты из хранения так что «уборкой мусора» придется заняться самостоятельно.

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

Есть и более простое, хотя и более грубое, решение — указать в скрипте резервного копирования максимальное время хранения данных. Все данные старше определенного срока будут удаляться автоматически. Но! Система копирования не включает в себя механизмы верификации бэкапов как рабочих, так что об этом стоит позаботиться самостоятельно.

Также время хранения можно использовать для того чтобы быстро очистить бакет. Установить время хранения всех данных на 1 день из консоли и на следующий день вся информация будет удалена. Удаление происходит асинхронно так что некоторое время после очистки возможно в бакете будут еще видны старые объекты, но плата за их хранение взиматься уже не будет.

Glacier

Glacier — персистентное хранилище, доступное в рамках AWS. Хранение данных в нем намного (приблизительно в 10 раз) дешевле чем в S3, но время доступа к ним намного больше (несколько часов). Кроме того Glacier берет деньги в основном не за хранение данных, а за операции записи и доступа к ним.

Один из вариантов использования этого хранилища — складирование старых резервных копий (точнее, сохранение их из S3 с последующим удалением оттуда). Это будет «страховочным вариантом» на случай, если с основным хранилищем произойдет какой-то необратимый сбой — данные можно будет пусть медленно, но восстановить.

Напоследок


Это далеко не весь список тонкостей работы с сервисами Amazon, но тем не менее, надеюсь, этот список будет вам полезен. AWS — один из лидеров облачной экспансии и упускать возможности которые он предоставляет — просто непростительно. Так что вперед, строить «облачные замки».

Комментарии (0)


Добавление комментариев доступно только зарегистрированным пользователям. Используйте свою существующую учетную запись для авторизации. Если у Вас еще нет учетной записи на сайте ее можно создать пройдя несложную процедуру регистрации. Кстати, для входа на сайт, наравне с учетной записью на cloudzone.ru, можно использовать аккаунт из следующих популярных сервисов: Яндекс, Facebook, Google и LinkedIn