Все сервисы AWS на одной странице-табличке вместе с ссылками на них:

https://www.awsgeek.com/AWS-Periodic-Table/

#info

Ответы на викторину по S3 + torrents — правда или ложь

Кто знает или читает историю AWS - тому ответ был известен заранее. :) А правильный ответ — да, S3 умеет торренты, соответствующий раздел в документации по ссылке с очевидным урлом:

https://docs.aws.amazon.com/AmazonS3/latest/dev/S3Torrent.html

#ответы

Disaster Tolerance vs Disaster Recovery

Длинная подробная статья о Disaster Tolerance подходе:

https://medium.com/cloudpegboard/disaster-tolerance-patterns-using-aws-serverless-services-fdfbe4163d84

Если заходит речь о бэкапах и каких-то их аспектов в частности или даже о Backup Strategy в общем, то всегда нужно помнить, что бэкап, который вы никогда не проверяли — бессмысленный бэкап, дающий лишь обманчивое ощущение защищённости.

Когда спрашивают "Что у нас с бэкапами?", всегда переводите вопрос в контекст "Что у нас с Disaster Recovery?" — бэкапы должны (периодически) проверяться путём подъёма полной версии вашего приложения/окружения в рамках DR плана.

В статье же рассматривается продолжение и развитие этого подхода — на вариант Disaster Tolerance, когда вы сразу закладываете в архитектуру устойчивость к проблемам падения региональных сервисов, так сказать, такой себе Netflix way.

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

#DR

⁠Amazon S3 Website Endpoints - ищем логику

Многие попадаются при написании своих скриптов для работы с S3 Website Endpoints:

https://docs.aws.amazon.com/general/latest/gr/s3.html#s3_website_region_endpoints

Когда выясняется, что s3-website в одних регионах является поддоменом и пишется через точку, а в других через тире вместе с идентификатором региона:

s3-website.region.amazonaws.com
s3-website-region.amazonaws.com

После тщетных попыток понять задумку разработчиков всего этого, вырывается очевидный восклик: «Где логика?!?»

Давайте поищем её в истории AWS. Возьмём даты анонсов AWS регионов и упорядочим по времени их появления. В результате получится табличка - см. картинку.

Видно, что до 2013-го года использовался вариант s3-website-region.amazonaws.com, начиная с Франкфурта - используется s3-website.region.amazonaws.com.

Всё просто и логично. Почему с 2014-го стали использовать отдельный поддомен для региона — уже совсем другая история.

#s3

⁠Полезное видео для понимания тонкостей работы S3.

AWS re:Invent 2017: Deep Dive on Amazon S3 & Amazon Glacier Infrastructure, with spe (STG301)

Ссылка на начало видео, где немного рассказывается, как работает Amazon S3 под капотом (на картинке).

#s3 #video

⁠EC2 Local Zone Settings

Для региона Oregon, где имеется Local Zone (кто пропустил - почитайте про первую локальную зону в Лос-Анжелесе - если коротко, то это подзона с задержками в единицы миллисекунд для, например, игр в виртуальной реальности и прочих вещей, требовательных к latency), теперь можно её включить в консоли.

Сделать это не так просто - нужно найти плохозаметную кнопку Enable additional Local Zones на дашборде EC2 консоли (см. картинку) и после изменить статус на Enable.

Актуально только (пока) для Oregon (где есть локальная зона). Включить можно, а выключить лишь через поддержку. Потому, в общем случае, если вы не планируете её использовать напрямую, лучше не включать, чтобы случайно не поломать какие-то ваши скрипты подзоной в виде us-west-2-lax-1.

#AWS_Console #EC2

Новые тесты AWS Graviton 2

https://www.anandtech.com/show/15578/cloud-clash-amazon-graviton2-arm-against-intel-and-amd

Если коротко, Graviton 2 рвёт AMD и Intel как тузик грелку прямо везде. Правда с поправкой на то, что все тесты синтетические (нет реальных бенчмарков), сравнивать 64 ядра Гравитона 2 с 32 ядра + 32 потока у старенького AMD первого поколения Zen — так себе практика (почему не Zen2 и что там делает Intel с 24 ядрами + 24 потоками — промолчим).

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

#Graviton

⁠EKS + Kubernetes 1.15

https://docs.aws.amazon.com/eks/latest/userguide/update-cluster.html

Грустный комментарий, но это нужно зафиксировать — спустя релиза 1.15 прошло 9 месяцев. Значит, получается, 1.16 нужно ждать в июне.

Выдержка и ещё раз выдержка. Важное свойство для успешной работы с некоторыми сервисами AWS.

#EKS

Если вам (не) нравилась CoreOS, то попробуйте амазоновский вариант операционной системы для работы с контейнерами Bottlerocket OS:

https://aws.amazon.com/blogs/aws/bottlerocket-open-source-os-for-container-hosting/

На текущий момент она подразумевает работу с EC2 инстансами на Амазоне, но являясь открытой, в будущем будет возможность поднимать Bottlerocket OS на своём железе.

https://github.com/bottlerocket-os/bottlerocket

Кроме того, в процессе реализации поддержка ECS, а после и Firecracker:

https://github.com/orgs/bottlerocket-os/projects/1

В общем, можно сказать, что Амазон реагирует на критику в свой адрес и в результате всё активней движется в сторону Open Source.

#Bottlerocket

⁠Aurora PostgreSQL глобализировалась:

https://aws.amazon.com/about-aws/whats-new/2020/03/amazon-aurora-with-postgresql-compatibility-supports-amazon-aurora-global-database/

На текущий момент поддерживается лишь версия Aurora PostgreSQL 10.11, которую нужно создать или восстановить из снэпшота версии PostgreSQL 10.7 на инстансх db.r4 или db.r5 типа, а после создания добавить регионы (до четырёх штук - на картинке), получив таким образом глобальную работу.

#Aurora

CodeBuild и ECS

Когда из CodeBuild нужно работать с другим аккаунтом, и потребуется переключаться в роль с помощью флажка --profile, учтите , что обычный вариант не сработает и будет давать ошибку:

Error when retrieving credentials from Ec2InstanceMetadata: No credentials found in credential_source referenced in profile ***

Это потому, что вместо обычного:

credential_source = Ec2InstanceMetadata

В секции профиля файла ~/.aws/config нужно использовать:

credential_source = EcsContainer

И всё заработает.

Почему? Получается, видимо, потому, что CodeBuild под капотом использует ECS.

В принципе, логично, хоть и не видел подобного в документации (что тоже логично).

#CodeBuild

AWS Loft Moscow 2020 отменён (переносится)

«В связи с ухудшением ситуации с короновирусом (COVID-19) в России, компания Amazon Web Services приняла решение отложить проведение AWS Pop-up Loft Moscow, запланированного на 13-17 апреля 2020 года в Москве. Мы приняли это решение после тщательного анализа ситуации, так как здоровье и безопасность наших сотрудников, клиентов и партнеров являются нашим главным приоритетом. Мы планируем провести это мероприятие позднее в этом году.»

Allow + NotPrincipal

Стоит быть внимательным и не допускать использования связки Allow + NotPrincipal при написании S3 Bucket Policy, например, типа такого варианта:

{
 "Version": "2012-10-17",
 "Statement": [{
   "Effect": "Allow",
   "NotPrincipal": {"AWS": [
     "arn:aws:iam::111111111111:user/SomeUser1",
     "arn:aws:iam::222222222222:user/SomeUser2"
   ]},
   "Action": "s3:*",
   "Resource": [
     "arn:aws:s3:::my-bucket",
     "arn:aws:s3:::my-bucket/*"
   ]
 }]
}

Где вы как бы хотите запретить доступ в бакет каким-то юзерам из каких-то аккаунтов.

В результате они (эти два юзера из примера выше) туда, действительно, не получат доступа. Однако кроме этого, незаметно, в бакет my-bucket получат доступ не просто другие ваши пользователи, но и вообще все, включая гостей (anonymous users) из интернета!

https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_notprincipal.html#specifying-notprincipal-allow

Потому в общем случае всегда нужно использовать связку запретить+кроме (Deny+NotPrincipal).

#s3 #bucket_policy

⁠Когда вы желаете сэкономить на хранении данных в S3 с помощью перевода данных на S3 IA (Infrequent Access), который в два раза дешевле обычного (S3 Standard), обязательно учитывайте, что за получение данных из S3 IA взимается плата (1 цент каждый гигабайт в отличие от бесплатного трафика для S3 Standard).

Иначе может получиться как здесь:

https://fudless.xyz/aws/boom/

Для подсчёта выгодности - можно использовать специальный калькулятор S3 Standard vs S3 Infrequent Access:

http://www.gulamshakir.com/apps/s3calc/index.html

Аналогично в случае использования S3 Intelligent-Tiering — там сам Амазон автоматически переведёт данные из S3 IA в S3 Standard при первом же доступе к ним (и не получится так плачевно, как по первой ссылке), однако как раз и нужно учитывать, что транзит из одного типа в другой (Lifecycle Transition) также стоит денег:

https://aws.amazon.com/s3/pricing/

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

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

#s3 #cost_optimization

⁠Тестов много не бывает - комплексное сравнение производительности различных подсистем AWS, Azure и GCP
у @tech_b0lt_Genona.

Если коротко, то AWS хорош, Azure неплох, а GCP растёт над собой.

#info #comparison

⁠Простое понятно всем, а известное известно всем. Спойлер — нет, это не так.

Когда разбираешься с какой-то совсем новой для тебя темой, стараешься максимально подробно записывать, что делаешь, что непонятно и неочевидно. По опыту знаешь, что когда разберёшься — не сможешь и близко вспомнить, что же тут непонятного и неочевидного — вот же, так, здесь, смотри сюда, читай туда, делай так. Но ведь до этого, даже имея большой опыт подобных начинаний — было непонятно!

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

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

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

Со второй частью сложней. Постоянно рассказывая про "известное всем" можно, с одной стороны, быстро вызвать раздражение у тех, кто это знает и тоже считает, что это "известно всем", "гуглится в один клик" и "есть на главной странице".

С другой стороны, когда кто-то впервые здесь прочитает, что такое есть, заинтересуется и узнает, поймёт, прокачается или успешно сдаст экзамен — как бы хорошо. Получается, что и этот вариант правильный.

К чему это я? Пытался найти баланс между технической детализацией, интересной самому по части AWS и "общеизвестными вещами", полезными тем, кто хочет узнать и разобраться или даже просто узнать, стоит ли разбираться.

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

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

#пятничное

⁠Есть места, где люди делятся своими страшными ошибками. И почти всегда это ужасно смешно.

---

eric gisse 12:48 AM
what i'm doing here is hugely dangerous
needs to be done so w/e
oh. i have the best mistake for this channel
DO. NOT. DELETE. AN. RDS. NETWORK. INTERFACE.
you will put your RDS instance in an unrecoverable state
it is unknown if support can fix that

ajeffree 1:17 AM
wait the network interface?
you mean the subnet group?

eric gisse 1:18 AM
no, network interface
i stopped the db and got the galaxy brain idea to go on a resource purge because we have stuff that builds up but doesn't throw away

===

Итого - не переусердствуйте в стремлении максимально вычистить ресурсы. Не нужно (пожалуйста) удалять сетевой интерфейс остановленной RDS базы данных.

#субботничное

Изменение стоимости вычислительных ресурсов AWS во времени

Работая с Амазоном важно понимать особенности формирования цены на виртуалки.

На другие ресурсы (хранение, стоимость чего-то в месяц и т.п.) стоимость может меняться (падать) в, так сказать, обычном порядке — огласили снижение цена на xx%% и в конце месяца в счёт попадёт новая цена.

Стоимость же виртуалок, будучи купленными, уже не меняется (скидочные планы не в счёт). Как бы логично предполагать, что, как же так, выходят новые, более крутые процессоры, а цена не падает. А вот как раз и падает, об этом и нужно знать.

В общем случае снижение цены проходит следующим способом. Выходит новое поколение процессоров - более крутых с большими возможностями. И виртуалки аналогичного количества процессоров+памяти, только более нового поколения, стоят ч̶у̶т̶ь̶ ̶д̶о̶р̶о̶ж̶е̶ дешевле!

Возьмём конкретный пример. У вас крутится база данных PostgreSQL, логично предположить, что она может крутиться многими годам. Например, возьмём, что вы её сделали лет пять назад и тогда это был простой вариант 4 ядра + 16ГБ памяти + MultiAZ, а соответственно (тогда) это был тип db.m3.xlarge.

https://aws.amazon.com/rds/previous-generation/

Посмотрим стоимость такой конфигурации (db.m3.xlarge), как она изменялась со временем и чему равна сейчас (без скидок и в N.Virginia):

https://aws.amazon.com/rds/postgresql/pricing/

db.m3.xlarge = $0.78
db.m4.xlarge = $0.73
db.m5.xlarge = $0.712

Как и было сказано ранее — цена падает. Новые виртуалки работают быстрей, эффективней и при этом дешевле!

Конечно, для того, чтобы получить такую выгоду, придётся обновить виртуалку, а рабочий прод никто трогать не хочет (плюс купленные ранее скидки не хочется терять).

Итого, факт — новое обычно дешевле и быстрей.

Или просто быстрей и стоит столько же, как, например, EC2 типы T2 и T3, которые стоят одинаково, в то время, как T3 на более новых и быстрых процессорах (а на самых мелких виртуалках у T3 два vCPU против одного у T2).

#cost_optimization

⁠SpeedTest для Amazon S3 Transfer Acceleration

http://s3-accelerate-speedtest.s3-accelerate.amazonaws.com/en/accelerate-speed-comparsion.html

Показывает отличие обычной загрузки в бакет от ускоренной:

https://docs.aws.amazon.com/AmazonS3/latest/dev/transfer-acceleration.html

Особой ценности не представляет, т.к. чаще бакет накрыт с помощью CloudFront. Однако кому нужно - позволяет быстро понять, для каких регионов и сколько может добавить в скорости.

На картинке результаты для Минска, видно, что с большинством регионов разницы нет (единицы процентов). Однако для далёких регионов (Австралия и особенно Бразилия) - результаты хорошо показывают, что значит, когда работа идёт по инфраструктуре Амазона, а не через "весь интернет".

#s3 #info

Главное за три года на AWS

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

Работая в таком ритме годами, с одной стороны, вы как бы приобретаете опыт и растёте, как профессионал в своей области. С другой, если совсем не следить за изменениями — деградируете в профессиональном аспекте. На выходе такой ситуации часто рождается конфликт между "old school подходом" (когда вы на базе своего опыта реализуете всё на "проверенных временем" схемах) и "хипстерскими" стильно-модно-молодёжными технологиями, которые пытаются продвигать новички в области вашей деятельности.

Не пытаясь холиварить на эту тему (old school против хипстеров — хотя сам на стороне последних), правильней лучше выбрать и рассказать про самое важное, что произошло за последние три года на Амазоне. Из тысячи апдейтов разной степени важности, выделить обязательные к ознакомлению, которые принципиально меняют подходы, работу AWS и работу с AWS.

---
Главное на AWS за 2017-2018-2019 — деньги (скидки)
---

Начнём с денег. Чтобы экономить на оплате постоянно работающих виртуалок, вот уже больше десяти лет использовались Reserved Instances. Это когда вы покупаете скидки на 1 или 3 года на какой-то тип виртуалок в каком-то регионе, взамен на гарантию, что будете пользоваться ими (верней - оплачивать) всё это время.

Так вот, Reserved Instances (RI) — всё, они в прошлом, их заменили Savings Plans:

https://aws.amazon.com/blogs/aws/new-savings-plans-for-aws-compute-services/

RI продолжают действовать, но смысла покупать новые нет, так как справедлива следующая формула перехода:

Standard RI = EC2 Instance Savings Plans (та же максимальная скидка 72%)

Convertible RI = Compute Savings Plans (та же максимальная скидка 66%)

Для тех, кто не имел опыта с RI — теперь незачем его получать. Смело берите (ориентируйтесь на) Compute Savings Plans и читайте уже про него. Кто захочет разобраться — вот подробное видео по Savings Plans:

https://www.youtube.com/watch?v=uQ9ry-9uUvo

В этом видео ещё нет того факта, что в этом году в Compute Savings Plans добавлены и Лямбды, что делает его (Compute Savings Plans) ещё более крутым.

Итого, главное по деньгам (скидкам) на AWS за последние 3 года — Reserved Instances умерли, да здравствует Savings Plans!

#главное #cost_optimization

RDS RI

В дополнение по RI нужно упомянуть про RDS Reserved Instances (RDS RI) — это как RI для EC2, только для RDS (спасибо, Кэп). Главное, что они разные (покупать-резервировать нужно отдельно и в разных местах, цены немножко отличаются) и по внедрению фич RDS RI отстают от EC2 RI. В частности потому RDS RI (как минимум пока) всё ещё актуальны (в отличие от EC2 RI, которые заменены на Savings Plans).

В 2017-м году RDS RI получили важное свойство (вслед за "обычными" RI) — Instance Size Flexibility:

https://aws.amazon.com/rds/reserved-instances/#Reserved_Instance_Size_Flexibility

Это если вы сейчас купите трёхлетнюю скидку на базу db.m5.xlarge, а через годик набегут клиенты и потребуется её мощность увеличить, например, до db.m5.2xlarge, то у вас будут следующие варианты:

1. Докупить ещё одну скидку на 1 или 3 года на такую же db.m5.xlarge и они вдвоём будут давать скидку на db.m5.2xlarge. То есть скидки db.m5.xlarge+db.m5.xlarge=db.m5.2xlarge

2. Ничего не делать и тогда к счёту вашей будущей db.m5.2xlarge применится скидка лишь на её половину (но применится, а не пропадёт).

Также стоит отметить важное свойство RI (справедливо и для EC2 RI, и для RDS RI, и для Savings Plans), что скидки применяются на все аккаунты вашей организации. То есть будучи купленными в мастер-аккаунте, все доступные скидки применятся и для всех подаккаунтов.

Итого по RDS RI — отдельный тип RI, скидка "самомасштабируется" по всей линейке одного семейства (одного региона) и применяется ко всем аккаунтам организации.

#главное #cost_optimization #RDS #RI