New Twitch show from AWS Training and Certification: AWS Power Hour: Machine Learning
 
AWS Training and Certification is launching a new Twitch show, AWS Power Hour: Machine Learning, featuring content for developers to learn about Machine Learning (ML) and Artificial Intelligence (AI) in a fun, live, and interactive environment. Starting Thursday, July 23, this show will run as a limited, seven-week program on the AWS Twitch channel.
 
About the Show
Designed for developers without any machine learning experience, the show will focus on how to build ML and AI applications with AWS AI services. Each week learners will gain in-depth technical training, including how to build apps with capabilities such as natural language, speech recognition, and personalized recommendations. Jon Dion, senior technical evangelist, and Kirsten Dupart, machine learning curriculum developer, will host, and be joined weekly by an expert guest. Learners do not need to have viewed a previous episode in order to understand and benefit from an individual episode.
 
How to View
Starting this Thursday, July 23, AWS Power Hour: Machine Learning will live stream for seven consecutive weeks, on Thursdays at 7:00 p.m. EST on the AWS Twitch channel at twitch.tv/aws. Episodes will also be available on-demand on Twitch, on aws.training, and YouTube after the live stream. The series is available in English.

​​ALB + Static IP

Получить статический айпишник для ALB можно в пару кликов, включив поддержку Global Accelerator во вкладке Integrated services (на картинке).

https://docs.aws.amazon.com/global-accelerator/latest/dg/about-accelerators.alb-accelerator.html

Конечно, этот айпишник будет у Global Accelerator, который добавит некоторые расходы ко всей конструкции, но также и даст ускорение при работе с клиентами по всему миру за счёт того, что запросы будут ходить на ALB через ближайшие к клиенту Edge точки Амазона (далее внутри по инфраструктуре AWS, а не через интернет).

#ALB #Global_Accelerator

AWS Copilot v.0.2.0 — теперь с поддержкой S3 и Dynamo DB для ECS/Fargate:

https://github.com/aws/copilot-cli/releases/tag/v0.2.0

Подцепить бакет или динаму к таске можно одной простой командой:

copilot storage init

CodeBuild + SSM

Чтобы отладить что-то в CodeBuild можно использовать SSM Session Manager:

https://docs.aws.amazon.com/codebuild/latest/userguide/session-manager.html

То есть можно тормознуть процесс сборки CodeBuild с помощью вставки codebuild-breakpoint, после приконнектиться через SSM, посмотреть на местности, что не так и после продолжить билд с помощью команды codebuild-resume.

#CodeBuild #SSM

Лучшие практики использования OU (Organizational Units) в мульти-аккаунтах:

https://aws.amazon.com/blogs/mt/best-practices-for-organizational-units-with-aws-organizations/

#best_practices #multi_account_strategy #Organizations

​​Размеры AWS-регионов на одной картинке.

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

Как видно, самые толстые регионы — Виржиния, Орегон, Ирландия, Япония и Огайо. Они есть две трети всего AWS.

Далее идут Германия, Сингапур и Австралия, с которыми это уже 80% процентов Амазона.

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

#info #AWS_Regions

​​Выражение «Не трогай то, что работает» для условного девопса:

1. Всегда актуально!
2. Как правило справедливо.
3. Сильно зависит от контекста.
4. Раньше было актуально, теперь нет.
5. Дурацкое выражение, никогда не актуальное.

#опрос #devops

​​Ошибка «Status Code: 400; Error Code: CertificateNotFound» при обновлении CloudFormation стэка обычно возникает по причине, что в нужном AWS регионе нет указанного в шаблоне сертификата.

Однако бывают и исключения. Например, сертификат в нужном регионе есть, его ARN указан верно, статус сертификата зелёненький Issued, но ошибка не исчезает. Как же так — вот же он, сертификат, в консоли, а Амазон его не видит!

Разгадка кроется в DNS домена, на который выдан сертификат, где наверняка отсутствуют записи DNS подтверждения для ACM-сертификата. В результате чего статус Issued вводит в заблуждение, ведь он изменится лишь когда нужно будет перевыпускать сертификат.

Проверить такое поведение (с "протухшим" ACM-сертификатом) можно создав новый балансер в AWS консоли и попытавшись прикрепить к нему сертификат. Если не обнаружите оного в списке доступных — значит как раз такой случай.

Решение проблемы — пересоздать сертификат, создав нужные DNS записи для подтверждения.

#CloudFormation #ACM

​​С чего начать изучать AWS?

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

Решение изучать AWS, не важно по каким причинам, но уже принято. Итак, вы идёте на сайт документации Амазона, а там такое:

https://docs.aws.amazon.com/index.html

Устанешь скроллить, а ведь это лишь глобальное оглавление глобальных оглавлений! С чего же начать? Какие самые главные сервисы изучить, ведь на все и жизни не хватит!

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


Древние кубики

Старый логотип Амазона — узнаваемые кубики, которые непрозрачно намекают, что из них можно собрать любое нужное. Чтобы максимально объективно выделить самые важные кубики — обратимся к истории Амазона. Логично, что сначала и были сделаны самые важные.

Итак, держите топ10 прото-кубиков, знать которые нужно уже просто потому что из них состоят многие другие, более новые кубики.

1. S3 — главное хранилище
2. EC2 — виртуалки + EBS диски
3. VPC — сеть
4. ELB — балансеры
5. RDS — базы данных
6. CloudFront — CDN
7. CloudWatch — логи/метрики
8. SQS/SNS — сообщения
9. IAM — главные права доступа ко всему
10. Route53 — DNS

Это не в порядке важности, это, так сказать, минимальный набор, который появился на AWS в первые 3-5 лет его жизни.


Современные кубики

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

И это справедливо. Однако тут есть одно НО.

Вы знаете Ассемблер? Ведь процессоры, на которых исполняются ваши программы "так работают". Но почему-то большинство хотят писать на JS или любимом Питончике.

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

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

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

1. Lambda
2. DynamoDB
3. API Gateway
4. S3
5. CloudFront
6. IAM
7. SNS
8. SQS
9. Step Functions
10. EventBridge

Вот набор самых важных кубиков из Serverless-направления. Т.к. в реальности Serverless-сервисов в Амазоне много больше и этот список постоянно увеличивается. Уже просто потому, что сам Амазон у себя использует именно эти — современные кубики.


Другие кубики

Огромные темы Machine Learning, IoT, Analytics и т.д. не были подняты, предполагая, что они, всё же, являются производными или зависимыми от обсуждаемых выше. Если у вас узкая специфика, то всё просто — переходите прямо к нужным.


Стильно-модно-молодёжные кубики

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

Amplify

Сервис Amplify под капотом крутит столько всего и сам по себе реализует CI/CD и среду разработки с огромнейшими возможностями. Если вам не чужд фронт — сразу начинайте изучать Амазон с Amplify!

AWS CDK

Продолжая аналогию, раньше для деплоя инфраструктуры использовался CloudFormation, он был обязательным кубиком для развёртывания приложений в Амазоне. Так сказать, CloudFormation — это Ассемблер IaC. Теперь же есть CDK — это Питон инфраструктуры, причём как в переносном, так и прямом смысле слова!


Итого

Если придерживаетесь классического подхода — начните с изучения S3 + EC2 + VPC + IAM.

Если современный — попробуйте сначала
Lambda + DynamoDB + API GW + S3 + IAM.


p.s. Как видите, в оба набора входят S3 и IAM. 😉

Поздравления по поводу своего Дня Рождения.

#опрос

​​Базы данных на AWS

https://aws.amazon.com/ru/products/databases/

#info #design

Интрересная вакансия DevOps (Москва/Санкт-Петербург)в Game Tech компании:
https://job.socialquantum.ru/spb/devops_engineer

Для желающих начать работу с Amplify:

https://www.travis.codes/blog/getting-started-with-amplify-part-one/

#Amplify

я квизы собрал с линукс академии в своем боте по этой тематике, чтобы в свободное время готовится @awstskbot

Простенький пример перехода хелловордного веб-приложения, работающего на EC2-виртуалках (Nginx) к его Serverless варианту:

https://aws.amazon.com/blogs/compute/replacing-web-server-functionality-with-serverless-services/

#Serverless

https://awsnews.info/

было уже?

Отмечу, что первоисточник находится здесь:

https://aws.amazon.com/new/

Где есть фильтрация по сервисам, но нет возможности удалять действительно малополезные апдейты.

Кроме того нужно добавить, что есть CloudPegboard, где кроме фильтрации по сервисам, есть много чего другого полезного, в том числе для подготовки к сертификации.

​​Если есть строгие правила at-rest шифрования всего используемого, то для Amazon ECR можно использовать свои KMS-ключи (customer master keys):

https://docs.aws.amazon.com/AmazonECR/latest/userguide/encryption-at-rest.html

Если не включать KMS (см. картинку) — шифрование всё равно будет, но лишь серверное (как SSE-S3).

Если включить KMS, но не поставить вторую галку, то будут использоваться дефолтные ключи Амазона (AWS-managed).

Если все галки — нужно будет указать свой ключ для KMS CMK.

Последний вариант добавит пару копеек к стоимости за использование KMS запросов, однако позволит пользоваться ECR из других аккаунтов.

Иначе, если при этом нужно шарить докер-образы из ECR в разные аккаунты — не включайте KMS encryption. Т.е. "средний вариант" (первая галка без второй) — лучше не использовать совсем.

#ECR #KMS