Fargate (сильно) обновился: поддержка EFS + 20GB диск + Сontainerd + Fargate-agent + изменённый Task ENI.

https://aws.amazon.com/blogs/containers/aws-fargate-launches-platform-version-1-4/

Одно из важнейших (и как видно - далеко не единственное) изменений — поддержка EFS. Теперь, наконец, в нём есть Persistent Storage и можно строить stateful приложения без костылей.

p.s. Прошло три месяца с момента прикручивания IAM авторизации к EFS (просто для статистики скорости внедрения фич).

#Fargate

Новый Fargate — что под капотом:

https://aws.amazon.com/blogs/containers/under-the-hood-fargate-data-plane/

Почему Docker сменили на Containerd, а также другие подробности работы и архитектуры Fargate. Крайне рекомендуется для глубокого понимания и последующей борьбы с проблемами.

#Fargate

​​Количество Reddit пользователей, участвующих в форумах по AWS, Azure и Google по годам.

#Reddit

Кому интересно, как EBS устроен изнутри - доклад свежачек https://www.youtube.com/watch?v=C9G775ITl1o

AWS Global Accelerator в подробностях:

https://www.sentiatechblog.com/aws-global-accelerator-terrible-name-awesome-service

Весьма детальная статья для тех, кто хочет разобраться как, зачем, кому и где используется AWS Global Accelerator. Очень рекомендуется и просто для знакомства, и для того, чтобы понимать глобальные возможности глобального Амазона.

#Global_Accelerator

Что у VPC под капотом — Mapping Service, Virtual Router и Blackfoot.

https://www.sentiatechblog.com/amazon-vpc-the-picasso-of-software-defined-networking

Детальная и при этом просто красивая статья о том, как работает VPC под капотом. Очень рекомендуется для глубокого понимания.

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

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

У автора такой же подробный (длинный — и это правильно) список ссылок по теме VPC (в конце статьи). Отлично и уже сделанная работа — сам буду использовать и вам рекомендую. :)

#VPC

​​Кто собирается сдавать на AWS certification удалённо, стоит учесть, что ежели у вас плохо с английским и вы выбираете себе +30 минут к экзамену как не native speaker, то виртуальный экзамен сдать не получится (как минимум пока).

Т.е. если у вас как на картинке (с добавленным временем), то сдавать получится лишь оффлайн — в каком-то из официальных центров. Убираете добавку 30 минут — и можно сдавать удалённо через Pearson VUE.

#AWS_Certification

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

→ Linux
→ Нечестным путем активированная Windows 8 или Windows 10
→ Честная/нет Windows ХР или Windows 7

Также не получится сдать, если у вас интернет через телефон (mobile hotspot).

Подробный tutorial с картинками можно посмотреть здесь:

https://tutorialsdojo.com/how-to-book-and-take-your-aws-certification-exam-online-saa-c02/

#AWS_Certification

​​Как-то был тут материал про автоматизацию удаления AWS аккаунтов. И вот теперь можно использовать не какой-то там хитрый-сложный-опасный туториал, а целую готовую (хитрую-сложную-опасную) систему:

https://github.com/iann0036/aws-account-controller

Вряд ли можно посоветовать использовать это даже просто для тестов. Однако зайдите и гляньте — картинка показательна, как можно из условного набора CloudFormation + Lambda запилить себе любую фичу, в том числе ту, что AWS Organizations нам уже обещает который год.

Кстати, а «который» — это уже третий. Даже если обещанного — три года ждут, то уже как бы пора.

#Organizations

Понятно и привычно (и приятно) видеть чётко работающиий, отполированный AWS. Но также и интересно отмечать, как торчат костыли в разных местах, которые обнаруживаются безопасниками, бесконечно тыкающими различными палками в Амазон и находящими в нём очередные странности и даже дырки:

https://blog.3coresec.com/2020/04/the-undetectable-way-of-exporting-aws.html

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

Хотя при этом для пользователей в регионах Oregon и Ohio таки есть возможность запросить логи через обращение в поддержку. (wat?!?)

#security

Вторая редакция алгоритма шифрования "пост-квантового" периода:

https://aws.amazon.com/blogs/security/round-2-hybrid-post-quantum-tls-benchmarks/

Кому ничего не ясно, но интересно, расскажу немножко про эту тему, которая часто обозначается термином long-term data security.

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

Очевидный прогресс TLS 1.2 → TLS 1.3 и далее (с отказом от старых версий), переход с Sha1 на Sha256/Sha384 и т.п. — всё это не давало успокоения особо параноидально настроенным господам, т.к. всё это не даёт ответа на вопрос — а что будет через 10-15 лет при такой скорости прогресса? Что если товарищи майоры всех мастей сидят и слушают, а главное — записывают всё передаваемое по шнуркам и вайфаям? Чтобы после, когда придёт недалёкое светлое и быстрое будущее, крякнуть за полчаса и узнать все тайны десятилетней давности?

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

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

В результате уже с пяток лет назад NSA в сообществе с заинтересованными сторонами стали разрабатывать способы подготовиться к этому, чтобы когда все смогут расшифровать условный TLS 1.4 или даже SuperTLS 2.8 за полчаса, то были способы не допустить всеобщего хаоса незащищённости.

В частности, в том числе AWS подключился и не стал изобретать ничего, а просто запилил расширение для TLS — алгоритмы SIKE и BIKE в статье выше.Их не получится поломать даже квантопутерами.

Первая редакция оказалась шибко медленной, однако это если не учитывать переиспользование шифрованной сессии — очень долгий получается TLS handshake. Вторая, улучшенная, уже "всего" в два раза медленней обычного TLS 1.2.

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

Если интересно, можно попробовать самому, как это было в первой статье:

https://aws.amazon.com/blogs/security/post-quantum-tls-now-supported-in-aws-kms/

Итого, квантовые компьютеры кроме плюсов, могут дать и минусы. Как обычно, что бы ни придумал человек — получается оружие. А потому к этому времени нужно готовиться заранее.

п.с. кто пропустил и вдруг не знает — можно самостоятельно воспользоваться квантовыми вычислениями с помощью сервиса Amazon Braket:

https://aws.amazon.com/braket/

#security #TLS

​​Стоимость AWS ресурсов в разных регионах разная, потому стоит учитывать этот момент, т.к. отличие в 15-20% практически норма, а можно попасть и на половину, ежели ваши заказчики из Бразилии.

Хорошая статья по разнице стоимости ресурсов в зависимости от регионов (со свежим перерасчётом цен) здесь:

https://www.concurrencylabs.com/blog/choose-your-aws-region-wisely/

Однако есть другой вопрос — а почему? Почему такая существенная разница?

Причин много. Давайте пофантазируем и построим будущий AWS регион в наших широтах, отталкиваясь от общих вещей.

Железо и технологии у нас свои или долгосрочные контракты с глобальными вендорами. Но что ещё?

Персонал — стоимость рабочей силы. В Украине, РФ, РБ, Казахстане они отличаются и достаточно сильно.

Налоги — отличие не столь принципиально, но если брать различные специальные условия (например, режим ПВТ в Беларуси), то это кратная разница.

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

Стоимость подключения к провайдерам — где-то государственная монополия с одним уровнем цен, а где-то большое количество операторов.

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

Спрос на облачные услуги и размер экономики региона — опять существенные отличия.

Ну, и, наконец — конкуренция. Если у кого-то есть условное (и безусловное) Яндекс.Облако, то с ним придётся жёстко и долгосрочно бодаться, в том числе и по части ценовой политики.

Весь этот набор (и не только) даёт на выходе винегрет формирования цены по миру (ведь везде аналогичные отличия), потому 15-20% вполне адекватный разброс.


п.с. Вопрос "почему" был задан в личку — было интересно разобрать подробней и рассказать здесь. Уважаю и люблю такие вопросы, поэтому если у вас тоже есть свои вопросы "почему" — смело пишите в личку или в чате.

#AWS_Regions #pricing

Snowball стал поддерживать IAM:

https://aws.amazon.com/about-aws/whats-new/2020/04/aws-snowball-now-supports-local-aws-iam/

В этой новости интересны две вещи.

Во-первых, теперь у нас IAM на вынос — «local AWS Identity and Access Management». То бишь локальный IAM — типа Outpost в миниатюре. Получается, что движок IAM экспортируем.

Во-вторых, у нас новый AWS регион snow — you must specify the region in these commands as "snow".

#Snowball #IAM

​​Давайте поднимем простенький сайтик на Wordpress — сказали они и зачем-то полезли в документацию AWS.

#design #пятничное

Бесплатный набор вопросов по Developer Associate:

https://digitalcloud.training/aws-developer-associate-free-practice-exam-questions/

#AWS_Certification

Control Tower поддерживает существующие (!!!) AWS Organizations:

https://docs.aws.amazon.com/controltower/latest/userguide/existing-orgs.html

Мы ждали, мы верили и, наконец, дождались!

#Control_Tower

​​Формула успеха.

#пятничное

Во время демо у заказчика Error 500. Нужен краткий ответ, что вы выберете?

Дешёвая (бесплатная) база данных на AWS для собственных проектов (обучения/попробовать)

#начинающим #интересующимся

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

Вы почитали, что здесь пишут про AWS и загорелись попробовать на него переехать или сразу поднять тут свой, чтобы познакомиться поближе и получить опыт. Расценки на хранение файлов (S3) совершенно комфортны, но вот проблема — у вас есть (реляционная) база данных. Вы смотрите прайс на RDS, а там самая простая начинается от 12 долларов в месяц и желание пробовать AWS резко пропадает.

Разберём варианты, что можно сделать с БД, чтобы она была дешёвой, а лучше бесплатной.

RDS

Обязательно прочтите про бесплатный AWS — открыв себе новый аккаунт, вы получите возможность целый год крутить базу на виртуалке db.t2.micro.

EC2

Можно поднять БД на дешёвой виртуалке, например, на t3a.nano это выйдет 3.4$/мес (плюс стоимость диска и некоторые другие расходы). Примитивный и самый очевидный способ. БД нужно будет поднимать и поддерживать самому, потому вряд ли рекомендуемый.

DynamoDB

Отличная и даже близкая к идеальной БД, по сути бесплатная (и постоянно/бессрочно/всегда) для собственных проектов, т.к. имеет суперовскую ценовую модель. Но есть одно но — не реляционная.

Очень выгодно, если ваш проект/фреймворк умеет с ней работать. Или если можете допилить его до работы с DynamoDB. На выходе получаете крутизну serverless подхода при минимальной цене (обычно совсем бесплатно).

Гляньте видео с последнего реинвента, возможно оно подскажет, как можно переделать свой проектик под DynamoDB:

https://www.youtube.com/watch?v=DIQVJqiSUkE

Aurora Serverless

Вдруг вы пропустили и не знаете, что есть реляционная база данных с ценовой моделью а-ля DynamoDB, где вы платите лишь за реально используемые ресурсы.

https://aws.amazon.com/rds/aurora/serverless/

Её использование подпадает под Free Tier, так что также можно попробовать годик бесплатно.

Задеплоить Django на Aurora Serverless можно так:

https://www.agiliq.com/blog/2019/01/complete-serverless-django/

Cassandra

Не реляционная, но с аналогичной DynamoDB ценовой моделью.

https://aws.amazon.com/ru/mcs/

S3

Речь про файловую БД. Если прикрутить прослойку в виде условной Лямбды, что будет хранить данные не в БД, а на S3, то можно вообще избавиться от БД. Однако, понятно, это обычно требует серьёзной переделки проекта.

Athena

Не БД, но можно делать SQL запросы к S3. Под Django есть djathena.


Итого. Есть разные недорогие варианты прикрутить БД в свой проект на AWS. Реляционные и нет, с переделкой и без. Выбирайте, что подходит сейчас и что будет круто в дальнейшем. Главное — пробуйте!

Удачное видео в дополнение к предыдущему посту:

https://www.youtube.com/watch?v=0G_mk42nVcE

(полный список видео тут)

Добавлю вариант для простых случаев, что можно складывать в DynamoDB или S3 дамп базы и подгружать его в память при старте вашего приложения.

А для любителей поизвращаться — можно устроить себе очень дешёвую и быструю базу данных на базе сервиса Route53, сохраняя нужное в TXT записях DNS вашего домена (возможен как публичный — отлично подойдёт для распределённых систем, так и приватный вариант).