Репутация измеряется в оттенках от лучшей к худшей по мнению спамлистов. Высокая репутация поддерживается благодаря фильтрации контента на стороне Amazon.
Вот пруфлинк, в котором они клянутся, что почта будет доставлена.
Балансировщик нагрузки — хост принадлежащий Amazon. В нём можно указать хосты, на которые рандомно расходятся запросы. Так же через Cloud Watch можно присоединять/отрезать от группы балансировки экземляры.
Настраивается всё с помощью групп и триггеров. Вот неплохая статья по поводу автоскейлинга.
Не затронута одна маленькая, но крайне важная деталь — local instance store не сохраняет данные при выключении или перезагрузке сервера, если данные на коневом разделе ОС надо хранить (например, конфигурационные файлы, ваше приложение, любые изменения в настройке ОС и т.п.), то нужно использовать EBS-backed диск Для нового пользователя это может быть очень неприятным сюрпризом.
Некоторые tips&tricks от постоянного пользователя AWS:
Если к ссылке файла в S3 добавить .torrent — то скачается торрент-файл с (пока) единственным сидером в виде сервера амазона. Удобно для массовой раздачи.
Стоимость трафика у амазона ОЧЕНЬ высокая, например 5ТБ в месяц в амазоне будет 600$ а у хетцнера это включено в базовый тариф. Поэтому для раздачи статики не выгодно использовать EC2.
Почту напрямую с EC2 отправлять очень сложно, буквально через 5-10 отправленных писем включается жесткий шейпинг траффика по 25 порту. Надо обязательно использовать либо SES либо туннель до другого почтового сервера.
Инстанцы с пред-установленным RedHat стоят заметно дороже.
На данный момент есть ограничение на максимальное число Elastic IP = 5 и запущенных инстанцев = 20. Лимиты повышаются запросом через форму на сайте.
У CloudFront цена на траффик такая же. У российских хостеров она правда все равно еще даже выше, чем у амазона) Думаю, что CloudFront есть смысл использовать только на сайтах с совсем международной аудиторией — тогда CF автоматом будет отдавать контент с ближайшей точки.
Про почту на EC2 у них внятно написано в FAQ — хотите отправлять письма — напишите заявку.
Мы написали, ее рассмотрели за 2-3 дня и теперь отправляем почту без ограничений.
Такое ограничение на почту — вполне логичная мера т.к. учитывая дешевизну\триальную бесплатность инстансов — амазон мог бы стать крупнейшим источником мирового спама.
Да, сначала ограничение стоит серьёзное. После заявки — начальное ограничение 10к в день по 5 штук в секунду. В последствии можно атвтоматически увеличить до 1м в день.
Ок, интересно.
Вот у меня есть инет-магазин на хостинге с выделенным сервером.
Как мне подсчитать, сколько будет стоить поддерживать мой магазин на этом облачном сервисе?
Я правильно понял, что главный плюс этого облака это легкая горизонтальная масштабируемость, но её должно поддерживать приложение?
А триггер типа «Минуту CPU загружен на 100% — увеличиваем частоту облачного процессора на 100% и отправляем админу смску» не сделать?
Можно только «Минуту CPU загружен на 100% — врубаем второй инстанс, сообщаем о нём балансировщику и отправляем админу смску, надеясь что приложение разберйтся»?
Облако резиновое, но не настолько. Всё происходит в пределах типов инстансов. Обычно делается по второму плану — поднимается клон и помогает.
Я как раз сейчас вынашиваю статью о самой настройке автомасштабирования, триггеров и балансировки. В ближайшее время её опубликую, если карму не заминусуют.
1. Можно поменять тип инстанца (на более дорогой — с более мощным CPU/больше памяти)
2. Да. Этот вариант должно поддерживать приложение (и балансироващик)
Автоматически — через API вроде можно рулить. только не забывайте что это подразумевает остановку старого\запуск нового ( или запуск рядом из готового AMI). Горячей замены типа дал команду и «график нагрузки пополз вниз» — нету
Что правда-то правда. Но за «бюжетными» проектами на AWS никто и не идёт. Нужно дешёвое — Godaddy, Namecheap, RackSpace в конце концов. Я для секондари днс сервера покупал когда-то VZ за $3 в месяц. И нормально!
Micro инстанс нужен, например, если испльзуются друге сервисы и выходит что гораздо меньше платить приходится за внешний траффик, чем экономить на бюджетной VPS.
AWS прежде всего стоит рассматривать как совокупность сервисов, а не как провайдера VPS. По меньшей мере глупо покупать у них только VPS.
Спасибо за объяснение. Я просто неправильно представлял позиционирование облаков. Думал их основное «назначение» экономить деньги на хостинг за счёт тонкого управлениями доступными ресурсами. Грубо говоря, если нагрузка на сайт днём больше в 4 раза чем ночью, то вместо покупки дедика с 4 Гб мозгов и 2 ГГц камнем, рассчитанного на дневную нагрузку, мы днём даём 4 Гб и 2 ГГц, а ночью только 1 и 500 и экономим процентов 25 за счёт того, что ночью у нас простаивающих ресурсов нет.
Кто вник — прикиньте пожалуйста, во сколько выльется замена обычной VPS (Linux, 1200 МГц, 1024 МБ, 25 ГБ), исходящий трафик около 10ГБ\месяц, нужен вебсервер, место для файлов, минимальная по размеру база mysql.
Угумс. Спасибо! Примерно понял расценки.
С учётом того, что сервисы потребляют предсказуемый объём ресурсов, проще и дешевле оставаться на своём железе :)
Иногда саппорт амазона так и пишет «ваш vps работает на degraded hardware, пожалуйста перезапустите или пересоздайте его для запуска на другом hardware. К такому то числу мы выключим старый hardware.»
Мне нравится, когда в жизни происходят пободные вещи: после прочтения данной статьи и по прошествии трех часов использования поисковика и чтения пабликов, я решился заказать облачный хостинг в… Linode.
По примеру RamonZzz я срочно мигрирую хоть куда с Амазона. Зарегил аккаунт, даже проплатил сервис. Ладно не стал ничего серьезного на нем делать — один месяц «халявы»(ну как — при регистрации чек проверки оплатил), потом списали за месяц абонку и через 2 недели аккаунт прибили и вымогают какие-то фотки, адреса, пароли и явки.
Популярно об Amazon Web Services