Главное на Амазоне за 2017-2018-2019 — AWS Organizations

От денег перейдём к организационной структуре. За это время с "верхнеуровневой" частью управления компанией на Амазоне поменялось ПОЛНОСТЬЮ ВСЁ — три года назад появился сервис AWS Organizations.

https://aws.amazon.com/organizations/

И если про AWS Organizations вы не слышали или если и слышали, то не особо вникали и не пользовались, то знайте — вы совсем не понимаете, как (теперь) работает AWS.

AWS Organizations — базовый элемент для обеспечения безопасности, современный проект вряд ли пройдёт аудит без использования Organizations, а при наличии каких-то Compliance требований вообще просто без шансов. Это опуская все моменты, которые AWS Organizations даёт по работе в увеличению эффективности работы - как на уровне управления командами и проектами, так и по части эффективного использования ресурсов и их оплаты.

Тут часто упоминались и будет упоминаться термин #Multi_Account_Strategy или просто "мульти-аккаунты", который есть немного жаргонное обозначение использования AWS Organizations. Кто не видел — можно посмотреть это видео по мультиаккаунтам.

Если всё равно не ясно, для чего AWS Organizations, то приведу следующую аналогию (для кого-то грубую и спорную). Относиться к использованию мультиаккаунтов (AWS Organizations) — это примерно как многие до сих пор относятся к докерам (правильней — контейнеризации вообще). Называя это "лишним уровнем абстракции", "потерей производительности" и "прочей ленью разработчиков, неспособных разобраться с зависимостями".

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

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

Переход на мульти-аккаунт схему требует времени, ресурсов, знаний. Равно как и, в своё время, требовал затрат переход на Docker, CI/CD, IaC, Kubernetes и другие современные подходы, которые на выходе дают большую гибкость, скорость, эффективность.

Итого по организации. Три года назад завезли совсем другой Амазон. Если вы этого не заметили — разберитесь и используйте AWS Organizations. Без него сейчас никак. Он теперь такой же базовый, как S3.

#главное #Organizations

Amazon ElastiCache for Redis глобализировался

Теперь можно создать две дополнительные Read-реплики в других регионах:

https://aws.amazon.com/blogs/aws/now-available-amazon-elasticache-global-datastore-for-redis/

В случае проблем с регионом, где живёт Primary-кластер, любой из дополнительных кластеров Read-реплик, может стать полноценным Read-Write Primary cluster.

#ElastiCache #Redis

⁠Если вы обнаружили в консоли новую фичу Amazon EBS Fast Snapshot Restore:

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-fast-snapshot-restore.html

Решили потестировать и спокойно закрыли, предполагая, что раз больше не будете пользоваться, значит и денег она не ест, то нет. Ест и неслабо — 540$ в месяц!

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

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

Итого — выключайте свет и незнакомые фичи, когда покидаете помещение.

Как выполнить команду на ECS или Fargate?

Если нужен аналог docker exec, только для ECS/Fargate, то можно использовать Ecs-Cmd:

https://github.com/dschaaff/ecs-cmd

COMMANDS
   exec    - Execute a Command Within a Service's Container
   get     - Get Info on Clusters and Services
   help    - Shows a list of commands or help for one command
   logs    - Tail Logs From a Service's Container
   run-task - Run a One Off Task On an ECS Cluster
   shell   - Open a Shell Inside a Service's Container
   ssh     - SSH into Host Task is Running On

#ECS #Fargate

Главное на Амазоне за 2017-2018-2019 — Networking

От организации к сетевой составляющей. За это время в плане подходов к проектированию и обслуживанию сети организации на Амазоне поменялось ПОЛНОСТЬЮ ВСЁ — в 2018-м году появились сервис AWS Transit Gateway и фича Shared VPC:

https://aws.amazon.com/transit-gateway/

https://aws.amazon.com/blogs/networking-and-content-delivery/vpc-sharing-a-new-approach-to-multiple-accounts-and-vpc-management/

Сервис Transit Gateway позволяет глобально упорядочить сетевую инфраструктуру самой высокой сложности, а для работы с On-Prem без него теперь теперь Амазон просто не рассматривается.

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

Если у вас используется VPN или Direct Connect доступ в Амазон, если у вас есть филиалы по миру или вы лишь планируете это сделать — обязательно разберитесь с возможностями, которые даёт Transit Gateway, это принципиально новый набор возможностей, это новый, совсем другой — глобальный Амазон. Вот хорошее видео по его работе и возможностям с последнего реинвента:

https://www.youtube.com/watch?v=9Nikqn_02Oc

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

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

И Transit Gateway, и Shared VPC плотно увязаны с мульти-аккаунт подходом, который, как говорилось ранее, теперь есть базовая сущность Амазона и потому неотрывно подразумевается и интегрирован в них.

Итого по планированию и работе с сетевой инфраструктурой компании — Shared VPC упрощает, а Transit Gateway упорядочивает и глобализирует. Это важно понять — Амазон давно стал глобальным, но теперь с помощью Transit Gateway он позволяет стать глобальным и вам, напрямую используя возможности AWS по глобализации своей сетевой инфраструктуры.

#главное #Transit_Gateway #Shared_VPC #networking

⁠Увеличение EBS диска на ходу

Если когда внезапно кончается место, вы по привычке останавливаете виртуалку, чтобы докинуть ей пространства, то наверняка вы пропустили, что для всех современных виртуалок есть фича Amazon EBS Elastic Volumes:

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-modify-volume.html

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

Официальная ссылка на решение такой проблемы:

https://aws.amazon.com/premiumsupport/knowledge-center/expand-root-ebs-linux/

#EBS

⁠AWS Security Monitoring, Logging, and Alerting

Если нужно серьёзно разобраться с безопасностью всей вашей разнообразной AWS инфраструктуры, то есть немало Security & Compliance сервисов:

GuardDuty
Inspector
Amazon Macie
Security Hub
Detective

А также тех, что работают с логами, конфигурациями, событиями:

CloudWatch
CloudTrail
Config

Возникает справедливый вопрос — как разобраться в этом зоопарке сервисов, какие связки, для чего и какие использовать?

Очень рекомендую начать разбираться в теме AWS security с этой статьи:

https://disruptops.com/what-you-need-to-know-about-aws-security-monitoring-logging-and-alerting/

Расписаны различные пути получения security данных, разбитых по типу на slow path и fast path мониторинг и почему это важно. Также все сервисы и источники данных разбиты по полезности с рекомендациями по применению для прод-непрод окружений.

В общем, детальная и глубокая статья, без воды от известного профи в безопасности.

p.s. Замечу, что статья лета прошлого года и в ней ещё нет свежедобавленного сервиса по безопасности Amazon Detective (что не меняет сути).

#security

Если вы раздумывали — не завести ли себе AWS аккаунт, то самое время это сделать сейчас:

https://aws.amazon.com/blogs/desktop-and-application-streaming/new-offers-to-enable-work-from-home-from-amazon-workspaces-and-amazon-workdocs/

Можно получить на несколько месяцев бесплатные Amazon WorkSpaces и WorkDocs, которые реализуют работу в виде удалённого рабочего стола для ваших сотрудников — на этот период можно работать (бесплатно) для аж до 50 человек.

Актуально лишь для новых аккаунтов и это отличный способ посмотреть — как работать вам и вашей фирме в удалённом формате.

#WFH #халява

⁠Скажи нет дискриминации по IP!
Каждой Лямбде по своей VPC!

#пятничное

⁠Amazon S3 Benchmark

Когда нужно увидеть скорость работы с S3:

https://github.com/dvassallo/s3-benchmark

Присутствует полезная табличка, вот некоторые результаты оттуда:

Instance Type Max - S3 Throughput MB/s

c5n.18xlarge 8,003
p3dn.24xlarge 6,269
m5.metal     2,713
m5.24xlarge  2,709
m5.2xlarge   1,133
m5.large     873
t3.xlarge    568
t3.medium    558
t3.small     395
t3.micro     349
t2.micro     46

#info #benchmark

⁠Кто любил задачки со звёздочкой (повышенной сложности) и серьёзно интересуется темой AWS security - вот вам многоуровневый квест по взлому Амазона:

https://flaws.cloud/

Без каких-то хакерских приёмов, всё лишь с учётом тонкостей работы инфраструктуры AWS, с подсказками по ходу прохождения.

От известного безопасника Scott Piper — бывшего сотрудника АНБ и разработчика многих утилит по безопасности (некоторые перечислены в этом списке).

#security

⁠Тестируем скорость сети EC2 ←→­ EC2

Для проверки пропускной способности сети между EC2 виртуалками есть официальные рекомендации по тестированию — для Linux:

https://aws.amazon.com/premiumsupport/knowledge-center/network-throughput-benchmark-linux-ec2/

И для Windows:

https://aws.amazon.com/premiumsupport/knowledge-center/network-throughput-benchmark-windows-ec2/

#EC2 #benchmark

⁠Как работает aws s3 sync?

https://docs.aws.amazon.com/cli/latest/reference/s3/sync.html

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

Сам попался недавно, обнаружив баг, который оказался фичей, точней и правильней — дефолтной работой сервиса S3 и с сервисом S3.

Объектное хранилище

S3 — это хранилище объектов, а не файлов. Обычно эти понятия считаются тождественными, но это не так и сие суть частая засада в различных вопросах на экзаменах по сертификации. И вот жизненный пример — данный "баг" в работе синхронизации (который не баг, а "так задумано").

Синхронизация локальной папки с бакетом

Посмотрим процесс синхронизации, отбросив тонкости, оставив важную логику.

1. Возьмём локальную папку и пустой бакет (первая синхронизация).

Процесс aws s3 sync смотрит очередной (каждый в папке) файл, его нет в бакете, потому делает ему (всем) upload — тут всё понятно.

Но отметим важную вещь — загружается не файл, а объект. В чём отличие?

У объекта на S3 нет ни прав файла (chmod), ни его владельца (chown), ни времени создания (Modify time). Точнее время создания равно времени загрузки (объекта, а не файла) на S3.

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

Назад в будущее

2. Обновим локально какой-то файл и повторим синхронизацию локальной папки и бакета. Как aws s3 sync узнает, какой файл изменился?

а) По размеру. Отличается — значит точно синхронизируем. Верно, тут понятно и проблем быть не может (их и нет).

б) По времени создания файла. Эээ... Но мы же выше как раз заострили внимание, что у S3 есть лишь время (последней) загрузки файла на сервис.

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

В общем, получаем следующее — если размеры файла не отличаются, а время загрузки объекта на S3 "свежее" (по любой причине), то файл не будет синхронизирован! И это — правильно (рыдания за кадром и глухие звуки ударов о стену).

Ключик --exact-timestamps

Когда нужно синхронизировать содержимое бакета и локальную папку (в обратную сторону, т.е. S3 → Local), то ключик --exact-timestamps станет спасительным. Ведь в данном случае временем создания файла будет каждый раз становиться время его загрузки (до этого) на S3, что снимает проблему разночтения даты создания и даты загрузки.

Итого. В случае использования синхронизации aws s3 sync нужно избегать ситуаций типа такой:

11:00 - Собрался билд 24
12:00 - Собрался билд 25
12:30 - Синхронизация билда 24
12:40 - Синхронизация билда 25

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

Дуболомным (по-умному workaround) способом решения данной проблемы является использования копирования (а не синхронизации):

aws s3 cp ./local s3://my-bucket --recursive

Не эстетично, конечно. Зато дёшево, надёжно и практично! ©

#S3

⁠Кому понравился квест со взломом Амазона, то можно посмотреть и второй сезон:

https://flaws2.cloud/

Там сюжет круче, т.к. можно играть и за тех, и за других (за хакеров или безопасников). Пробуйте, у вас получится!

#security

⁠Сидите дома и не знаете чем себя занять? Готовьтесь к AWS сертификации!

https://aws.amazon.com/certification/faqs/

Теперь экзамены можно сдавать удалённо: AWS Certification Exams Now Available Virtually

Так что не мешкайте и пусть временные проблемы станут шансом. Удачи!

#AWS_Certification

Три бесплатных месяца на сервисы удалённой работы и обучения:

https://aws.amazon.com/blogs/publicsector/research-sharing-collaborative-communications-addressing-needs-public-sector/

Amazon Chime, Amazon WorkSpaces и Amazon WorkDocs будут бесплатными до июня включительно.

https://aws.amazon.com/remote-work-learning/#Amazon_Chime

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

#Chime #халява

⁠Классовая дифференциация слабых/дешёвых EC2 виртуалок

EC2 виртуалки, которых стоит избегать:

• t3.nano
• t2.nano
• t1.micro
• m1.small

Если последние два варианта очевидны своей древностью, то первые две имеют память менее гигабайта. По рекомендациям к пен-тестированию (т.е. на попытку взлома) эти инстансы сам Амазон требует исключить из тестирования (см. картинку).

https://aws.amazon.com/security/penetration-testing/

Потому рекомендуется использовать t2.micro/t3.micro и выше.


Слабые T2/T3 и прод

Инстансы типов t2/t3 вполне можно использовать в том числе и на проде — когда нет требований к нагрузкам и возможным сетевым лагам. Однако за многие годы моя личная практика научила, что меньше, чем t2.small/t3.small лучше не ставить даже для временных тестов.


Самые дешёвые (рекомендуемые) - T3a

С появлением AMD самые дешёвые рекомендуемые инстансы теперь это t3a.small — 13.5$/мес против 15$/мес у интеловского t3.small).


Самые дешёвые и ходовые - T3.medium/T3a.medium

Для большинства современных задач "оптимальный минимум" — это 2 vCPU+4GB RAM, то есть t3a.medium/t3.medium (27$ и 30$ в месяц соответственно).

Как вы много где заметите, различные ресурсы амазона стоят обычно в районе 30 долларов с копейками в месяц — ибо под капотом как раз наверняка такая (типа t3.medium) виртуалка, за которую и берут схожую сумму.

В общем, если нужно дёшево и при этом надёжно — берём пример с Амазона и ставим t3a.medium/t3.medium.

#EC2

⁠Смотрим на Землю через сервис AWS Ground Station

Пошаговая инструкция, как такое сделать:

https://aws.amazon.com/blogs/publicsector/earth-observation-using-aws-ground-station/

С помощью сервиса Ground Station можно получать собственные снимки из космоса без покупки (сборки/запуска/эксплуатации) собственного спутника.

#Ground_Station

Интересные подвижки в AWS Organizations:

https://docs.aws.amazon.com/organizations/latest/APIReference/API_RegisterDelegatedAdministrator.html

Теперь можно будет давать подаккаунтам админские права на работу с сервисами, глобально работающих в пределах всей организации (CloudTrail, Config etc — полный список таких сервисов здесь).

Это значит, что команда Organizations трудится не покладая рук и вскоре должны быть серьёзные изменения.

#Organizations

⁠Обычно все знают, что у Китая свой отдельный изолированный AWS. А что у Индии тоже есть свой AWS, только не изолированный, знаете?

Так вот — да, у Индии свои отдельные AWS аккаунты через отдельную компанию AISPL:

https://aws.amazon.com/premiumsupport/knowledge-center/what-is-aispl/

Свой маркетплейс, биллинг и расчёты в рупиях:

https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/manage-account-payment-aispl.html

Индийский AWS появился перед открытием в 2016-м региона в Мумбае.

Внимание!
Если вы столкнётесь с "индийскими" аккаунтами — имейте в виду, что их не получится "проапгрейдить" до "обычных" (AWS). Также такой AISPL аккаунт нельзя принять в "обычную" (AWS) Organizations. Всё такое работает только в рамках AISPL.