​​Буквально три недели назад писал про SpeedTest для Amazon S3 Transfer Acceleration. Результаты которого показывали некоторое символическое ускорение от использования инфраструктуры Амазона — по сравнению с работой с бакетом напрямую, т.е. через интернет.

И вот посмотрите теперь на картинку, она стала примерно-показательной (тест из Минска).

Если раньше нужно было убеждать, объясняя про единицы проценты разницы, то теперь у многих (из Беларуси и России как минимум) такие тормоза при загрузке сайтов из Америки, а также просто AWS Console с заокеанскими (и просто далёкими) регионами, что убеждать не нужно — скорость работы через инфраструктуру Амазона быстрее в разы, а то и на порядки (с Австралией в 10-20 раз).

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

Service Control Policies Best Practices

Подробный пост с практическими рекомендациями Скотта Пайпера, посвященный тому, что такое Service Control Policies (SCP), распространенные ошибки, а также ряд примеров политик. Среди примеров - разрешение только утвержденных служб или регионов, запрет доступа root'а, отказ от возможности сделать VPC доступным из Интернета, защита security baseline.

https://summitroute.com/blog/2020/03/25/aws_scp_best_practices/

#aws

Ошибок и их причин при работе с S3 могут быть кучи. Упомяну ещё одну. Сообщение:

An error occurred (AccessDenied) when calling the GetObject operation: Access Denied

Может быть получено даже если у вас (юзера/роли) есть все нужные IAM права (вы перепровели два раза), а в бакете прописаны нужные Bucket Policy (вы перепроверили три и более раз).

Гляньте, подумайте, вспомните, посмотрите и проверьте — возможно бакет зашифрован с помощью ключа KMS, а не дефолтного AES 256 (S3-SSE). И если да, то наверняка в этом причина.

https://aws.amazon.com/premiumsupport/knowledge-center/decrypt-kms-encrypted-objects-s3/

Для получения из шифрованного бакета (шифрованного файла в нём) требуются права на kms:decrypt. А также разрешение использования ключа шифрования для вашего аккаунта.

При загрузке из шифрованного S3 бакета, в процессе выполнения s3:GetObject вы должны иметь право расшифровать полученное (kms:decrypt), иначе получате ошибку. И без намёков, что проблема не в правах на S3 (Bucket Policy), а что проблема в отсутствии прав IAM.

Так что будьте бдительны и помните сто первый тип ошибки загрузки с S3 — отсутствие прав на расшифровку kms:decrypt.

#S3 #IAM #KMS

​​Open Guide по AWS (og-aws) на русском:

https://github.com/nickpoida/og-aws/blob/master/translations/ru.md

Сам начинал переводить, а тут готовое — очень рекомендую. Местами информация старая и не актуальная, но для тех, кто почему-то пропустил и не читал оригинал — крайне рекомендуется и для начинающих, и для продолжающих.

#info

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

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

#пятничное