Как выполнить команду на 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.

⁠CloudFormation или Terraform? Terraform через CloudFormation!

https://github.com/iann0036/cfn-tf-custom-types

Четыре месяца назад появилась фича CloudFormation Registry, которая прокачала CloudFormation до возможностей Terraform. И вот теперь через привычный формат CloudFormation посредством Terraform можно деплоить любые им поддерживаемые ресурсы.

То есть использовать CloudFormation не только для AWS, но и, к примеру, для GCP или Azure (на картинке).

#CloudFormation #Terraform

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

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

Совершенно не обязательно ставить FreeBSD, ощущения (и опыт — сын ошибок) придут и с любой Убунтой, главное заставить такой ноут петь, показывать и всё другое, что используется в обычной жизни (игры не в счёт).

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

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

Главное в процессе — пройти уровень настройки бесплатного ПО в версии линукса, заменяющего привычное пиратское виндовое, освоить терминал и базовые настройки/команды линукса.

Далее можно советовать освоить принципы работы с git, чтобы можно было пытаться ходить на собеседования по девопсу. Но самое базовое — это сеть и линукс.

===

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

#переквалификация #linux

Народ рапортует, что успешно сдаёт AWS сертификацию, которую недавно стало можно сдавать удалённо.

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

Из требований — нужно иметь надёжную связь и последнюю ОС (например, для маков это MacOS 13.x). В общем, процесс пошёл — можно (нужно) учить.

#AWS_Certification