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

Chat: https://t.iss.one/aws_notes_chat

Contacts: @apple_rom, https://www.linkedin.com/in/roman-siewko/
Download Telegram
Как работает 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.small13.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
EKS Networking

Хорошая статья с описанием работы сетевой части EKS в VPC:

https://aws.amazon.com/blogs/containers/de-mystifying-cluster-networking-for-amazon-eks-worker-nodes/

Рассмотрены различные варианты организации кластера и подсетей VPC — от публичных до полностью приватных, как настраивается и best practices.

#EKS
​​Amazon FSx - в 10 раз дешевле! Теперь с поддержкой HDD:

https://docs.aws.amazon.com/fsx/latest/WindowsGuide/optimize-fsx-costs.html

До этого сервис FSx поддерживал лишь SSD, что давало отличную скорость, но стоило денег. Теперь же, когда нет больших требований к скорости, за каждый гигабайт места можно платить в десять раз меньше:

https://aws.amazon.com/fsx/windows/pricing/

В результате теперь для простенькой FSx конфигурации на 10 ТБ вполне можно рассчитывать на 100$/мес (см. пример расчёта на картинке).

#FSx
​​aws --debug

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

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

Например, казалось бы, простая команда просмотра имеющихся бакетов aws s3 ls даёт на выходе огромнейший лог (см. картинку и это лишь часть).

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

Например, непонятно почему, команда отрабатывает не так, как вы планировали и пишет, что нет credentials или не хватает прав. Запустив с ключиком --debug, можно пронаблюдать, как команда aws перебирает источники credentials, на картинке это строчки с:

Looking for credentials via: env
Looking for credentials via: assume-role
Looking for credentials via: shared-credentials-file
Looking for credentials via: custom-process
Looking for credentials via: config-file
Looking for credentials via: ec2-credentials-file
Looking for credentials via: boto-config
Looking for credentials via: container-role
Looking for credentials via: iam-role

В результате наглядно видны приоритеты получения aws-cli credentials, что вполне может навести на мысль, почему не работает как нужно.

Итого — не забываем про ключик --debug, в проблематичных ситуациях попробовать с ним может решить проблему. А если и нет, то запостить куда-то с логами будет много показательней, чем на словах объяснять, что "не хочет работать".

#aws_cli
​​Официальный блог по удалённой AWS сертификации:

https://aws.amazon.com/blogs/training-and-certification/aws-certification-exams-now-available-virtually-for-added-convenience-and-flexibility/

Из плюсов — принимают экзамены в режиме 24/7, так что можно запланировать любое удобное время. Требования к железу/ПО/сети очень скромные и вполне выполнимые (см. картинку).

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

Заказать удалённую сдачу можно лишь через Pearson VUE, выбрав вариант «At my home or office».

#AWS_Certification
​​Delegated Administrator в AWS Organizations

Сначала новость - IAM Access Analyzer теперь работает на уровне организации:

https://aws.amazon.com/blogs/aws/new-use-aws-iam-access-analyzer-in-aws-organizations/

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

Писал раньше про изменения в AWS Organizations и вот первые результаты — IAM Access Analyzer можно запустить для работы с организацией из подаккаунта (например, какой-то security аккаунт), а не (только) из мастера.

Для этого сначала нужно дать права какому-то подаккаунту (на картинке кнопка Add delegated administrator). А после работать из подаккаунта в обычном режиме, при этом имея данные для IAM Access Analyzer-а со всей организации (в т.ч. из главного мастер-аккаунта).

Очень правильный, давно перезревший функционал — делегация админства организации в подаккаунт. Постепенно так, можно надеяться, удастся максимально вынести весь такой security функционал из мастера в security подаккант, что соответствует best practices работы в мульти-аккаунт схеме.

#IAM #Organizations
​​AWS СLI v.2 в Docker

Теперь не обязательно ставить aws-cli локально и всегда можно быстро попробовать с последней версией. В общем, удобная и важная возможность — запустить aws-cli в докере:

https://aws.amazon.com/blogs/developer/aws-cli-v2-docker-image/

Легко и просто работает через роль виртуалки, а чтобы прокинуть внутрь credentials или скачать/закачать какие-то файлы, то используем стандартный ключик монтирования -v:

docker run -it -v $(pwd):/aws amazon/aws-cli s3 cp 1.txt s3://my-bucket

#aws_cli
​​Стал доступен анонсированный 4 месяца назад сервис Amazon Detective, пополнивший набор security сервисов Амазона:

https://onecloudplease.com/blog/amazon-detective-following-the-breadcrumbs

Функционал Detective, связанный с поиском и визуализацией возможных проблем с безопасностью (собственно - потому "Детектив") наверняка сделает его стандартным по части безопасности в дополнение к GuardDuty, Security Hub сотоварищи.

#Detective #security
​​Если кто пропустил — у Телеграм есть отличная возможность собрать в кучу AWS каналочаты (на картинке).

В принципе, равно как и все другие темы. Каналы можно объединять друг в друга, исключать и другие удобные вещи. В общем, можно всё упорядочить.

На картинке десктопный вариант, но для мобильной версии папки также доступны:

https://telegram.org/blog/folders