AWS Notes
5.6K subscribers
444 photos
42 videos
10 files
2.8K links
AWS Notes — Amazon Web Services Educational and Information Channel

Chat: https://xn--r1a.website/aws_notes_chat

Contacts: @apple_rom, https://www.linkedin.com/in/roman-siewko/
Download Telegram
⚙️ Не спите ещё? Тут кажется ещё одна рассылка намечается интересная. На этот раз по теме AWS. Предлагаю последить, вдруг что-то хорошее их этого выйдет - AWS Security Digest. AWS Security Digest Weekly Newsletter. #aws #security #напочитать
В документе AWS Service Terms в пункте 50.3 есть такая строчка:

...we may store such AI Content in an AWS region outside of the AWS region where you are using such AI Service...

То бишь, ежели вы используете AI сервисы, то их данные могут быть сохранены вне региона, где вы работаете, что может нарушить compliance требования и про что хотя бы нужно знать.

На текущий момент AI сервисы это следующий список:

🔹 Amazon CodeGuru Profiler
🔹 Amazon CodeGuru Reviewer
🔹 Amazon Comprehend
🔹 Amazon Comprehend Medical
🔹 Amazon DevOps Guru
🔹 Amazon Forecast
🔹 Amazon HealthLake
🔹 Amazon Kendra
🔹 Amazon Lex
🔹 Amazon Lookout for Metrics
🔹 Amazon Personalize
🔹 Amazon Polly
🔹 Amazon Rekognition
🔹 Amazon Textract
🔹 Amazon Transcribe
🔹 Amazon Transcribe Medical
🔹 Amazon Translate

Амазону можно запретить использовать данные AI сервисов для улучшения их качества:

https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_ai-opt-out.html

Для этого нужно выполнить в management (главном) аккаунте специальные команды, которые добавят политики запрета к организации.

Про всё это и как такое сделать — в блоге крутейшего безопасника по AWS, Scott Piper:

https://summitroute.com/blog/2021/01/06/opting_out_of_aws_ai_data_usage/

В общем, всё как обычно — стоит читать мелкий шрифт в лицензионных соглашениях. 😀

#security
EC2 виртуалки — выбираем регион в Европе

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

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

https://www.cloudping.info/

Вот характерная картинка, сделана прямо сейчас при написании поста, отражает обычный расклад (из Минска):

Ireland   67 ms
London   49 ms
Frankfurt 46 ms
Paris    57 ms
Stockholm 34 ms

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

Стоимость EC2

Однако есть ещё и стоимостной момент. Разброс цен на EC2 виртуалки есть и в купе с пингом вполне может заставить по-другому смотреть на выбор региона. Если взять Ирландию как 100% цены, то на текущий момент получается следующая картина:

Stockholm  94.7%
Ireland   100.0%
London   103.5%
Paris    103.5%
Milan    105.0%
Frankfurt 105.3%

Самый дорогой Франкфурт! Не знали, да? Я вот помнил, что он дорогой, однако уже подзабыл и считал самым дорогим недавно появившийся Милан. А вот и нет.

Однако интересно отметить относительно дешёвый Стокгольм. В случае Минска получается и дешевле и быстрей — хороший повод подумать. Особенно, если сидите во Фракфурте, то получаете при переезде в Стокгольм -10% в ценнике и при этом быстрей!

https://aws.amazon.com/ec2/pricing/on-demand/

Короче, всё течёт, всё меняется. И появляется повод сэкономить и ускориться!

#AWS_Region #cost_optimization #EC2
​​CloudFormation vs Terraform

Впервые за время с появления Terraform, команда CloudFormation обогнала по количеству поддерживаемых ресурсов (664 ресурса) команду Terraform (654 ресурса).

Сверху — за последнее время, снизу — за всё время.

И вновь продолжается бой!

Первоисточник:

https://twitter.com/iann0036/status/1347381025723203585

#CloudFormation #Terraform
Forwarded from CloudTechRU
Забирайте бесплатный курс "Terraform - From Zero to Certified Professional. HashiCorp Certified: Terraform Associate and much more" от Дениса Астахова.
На русском у Дениса лучше выходит. Это как сериалы в переводе Кураж Бомбей смотреть, когда перевод лучше оригинала )
Ссылка доступна 3 дня.
https://www.udemy.com/course/terraformcertified/?couponCode=TERRAFORM-ON-ENGLISH
#машины_aws

Ваше выходное чтиво - третья глава по DynamoDB.

В этой части: что такое консистентность, почему ее так тяжело достичь и как воспроизвести в DynamoDB, как отлавливать изменения данных, а также особенности кеширования с использованием DAX и построение гео-распределенных таблиц.
Хорошее место для знакомства, проверки и углубления своих знаний по CloudFormation:

https://scaleyourcloudformation.com/

Фичи, популярные заблуждения и ошибки, проблемы и места скопления бесплатных шаблонов. Советую.

#CloudFormation
Супер история о том, как Амазон чуть не умер и переехал с серверов Sun на Linux. Это — история зарождения Amazon Web Services — облака, на котором сегодня работает добрая половина интернета.

Рассказывает один из непосредственных участников.

Самые впечатляющие моменты:

❧ в 2000 лопнул пузырь доткомов — технические компании обесценились в сотни раз, на фондовом рынке кончились деньги и Amazon начал жечь собственные средства — 1 миллиард долларов в год; самой крупной статьей расходов были серверы — их делал Sun, они стоили дорого;

❧ можно было перекупить серверы Sun у компаний, обанкротившихся на пузыре доткомов, но техдир Амазона пошел ва-банк — решил переехать с Sun на обычное железо Hewlett Packard на Линуксе; ядру лунукса тогда было всего 6 лет;

❧ на время переезда они остановили ВСЮ продуктовую разработку! ВСЕ занимались только переездом. В бэклоге лежали сотни функций для увеличения продаж, но все ждали, пока закончится переезд;

❧ заморозка развития сервиса привела к падению продаж → пришлось повышать цены на товары → продажи упали ещё сильнее, запустилась «спираль смерти»;

❧ у Амазона оставалось буквально несколько кварталов до смерти, когда деньги на счету кончатся, но они успели и запустили всё нормально, стоимость масштабирования инфраструктуры упала на 80%;

❧ продажи — сезонный бизнес и Безос придумал, почему бы не сдавать простаивающие серверы в низкий сезон другим компаниям? На презентации он привел аналогию с электрической сетью — в 1900 годы каждый завод строил свою собственную электростанцию, почему бы не сделать «электрическую сеть» для IT? Плюс это круто сочеталось с его идеей разделить команды внутри компании, чтобы команды могли развиваться самостоятельно — каждая команда стала независимым API.

Ну а дальше вы знаете. Сегодня Амазон — это не только интернет-магазин, но и одна из крупнейших IT компаний планеты.

https://twitter.com/DanRose999/status/1347677573900242944
Forwarded from Devops Talks (Alex 🎲 Green)
the IAM and RBAC terminology resource - понятное объяснение таких вещей как AWS Identity and Access Management (IAM) и Kubernetes Role-based Access Control (RBAC) с примерами.

https://mhausenblas.info/rbIAM/terminology/
​​Утилитка с удобным интерфейсом для работы с Athena:

https://github.com/OElesin/querypal

#Athena
​​Сложный выбор.

#субботничное
​​Проект для отладки Лямбд и API Gateway локально:

https://github.com/dherault/serverless-offline

#Lamda #API_Gateway
​​Federated EKS cluster:

https://aws.amazon.com/solutions/implementations/federated-amazon-eks-clusters-on-aws/

Данное решение позволяет развернуть федеративный EKS кластер в разных регионах для VPC, объединённых через VPC Peering.

#EKS