SRR (Same-Region Replication) для S3 бакетов

Ещё один набор костыльных велотроллейбусов можно списать в утиль - в дополнение к CRR (Cross-Region Replication) наконец-то появилась и репликация в тот же регион.

https://aws.amazon.com/about-aws/whats-new/2019/09/amazon-s3-introduces-same-region-replication/

Кому не сразу очевидно - применений такой репликации немало. Например, вот три из документации:

• сборка логов из различных аккаунтов в один бакет
• использование синхронизируемых данных в одном бакете для различных окружений
• специфичные compliance, привязанные лишь к одному региону

#s3 #srr

Новости одной строкой:

You can use this feature in all the regions where API Gateway Private APIs is available i.e., except Europe (Bahrain).

#занимательная_география

⁠Шаблон для VPC в N.Virginia с шестью AZ-подзонами

Многие примеры #CloudFormation #templates имеют в большинстве случаев две подзоны (Availability Zones). Это удобно тем, что все регионы имеют как раз минимум эти две подзоны (см. наверняка знакомую картинку из документации).

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

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

Особенно это актуально для N.Virginia, где целых 6 подзон. Использовать в таком регионе лишь 2-3 штуки из имеющихся шести - особо неприятно.

Для создания #VPC можно использовать кучи способов - от вручную в консоли до Terrafrorm и прочих инструментов. У каждого адепта #CloudFormation есть свои "проверенные" шаблоны, в частности, вот мой для региона us-east-1 с зонами от A до F (6 шт.):

https://github.com/applerom/cloudformation-examples/blob/master/vpc/vpc4af.yml

В результате создаётся VPC с диапазоном адресов /16 и с подсетями на /24, в том числе приватными (для которых по умолчанию создаётся NAT) - стандартный набор, короче. Просто с помощью данного шаблона всё это делается просто заданием CIDR prefix типа 10.25, а все остальные подсетки создадутся автоматом, что удобно и можно использовать единый стиль архитектуры со всеми своими проектами (подредактировав шаблон под свой вкус и прочие требования).

⁠Security group vs Network ACL

Наглядная картинка из документации - на каких уровнях они работают.

Network ACL (NACL) условно могут всё то же, что и Security group, плюс позволяют фильтровать с учётом подсетей (subnets) - когда, например, нужно на сетевом уровне изолировать какую-то приватную подсетку.

Обычно фильтрацию реализуют лишь с использованием Security group, однако если достался чужой проект и там до чего-то никак не получается достучаться - есть смысл глянуть в VPC → Security → Network ACLs.

Стоит отдельно отметить, что ни #sg, ни #NACL не фильтруют трафик с 169.254.0.0/16 и что всегда можно получить мета-данные инстанса оттуда, в том числе из запущенных на инстансе докеров.

Чтобы соблюсти какую-то пропорцию сложности материалов здесь, хотелось бы учесть уровень и запросы читателей. Потому поделитесь, пожалуйста, своим опытом и пожеланиями.

1. С сервисами AWS не работал(-а), интересуюсь и изучаю.
2. Начал(-а) работать с AWS, разбираюсь с базовыми сервисами.
3. Есть некоторый (условно до года) опыт работы с AWS.
4. Есть большой опыт (не один год) работы с AWS.

Проблемы kernel 4.14.143

Если после обновления EC2-инстансы стали себя странно вести - паниковать и случайно падать, стоит учесть:

https://www.reddit.com/r/aws/comments/d98jou/heads_up_issues_with_all_ec2instances_running/

Это не проблемы #Amazon_Linux (как в названии по ссылке), т.к. проявляется и на других (неамазоновских) линуксах, потому не спешите пока обновляться. А если уже, то пересобирайте образ с kernel 4.14.138 (amazon/amzn2-ami-hvm-2.0.20190612-x86_64-gp2) и древней.

#не_спеши #тебя_ждут_дома

⁠Конвертилка существующих AWS ресурсов в CloudFormation шаблон

Стандартная ситуация условного стартапа в начальной стадии:

1. Накликали в AWS Console свой проект
2. Проект не загнулся и даже немножко поехал.
3. Запаривались эмулировать CI вручную.
4. Задумались о том, что нужно бы перести "вот это всё" в #CloudFormation #templates.

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

Таких утилит не так много, они отличаются различной степенью бесполезности. Наименее бесполезная или, наоборот, наиболее полезная и самая красивая из них:

https://former2.com

Официальная же амазоновская называется CloudFormer:

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-using-cloudformer.html

О бесполезности конвертошаблонизаторов

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

Если проект очень простой - посмотрев примерчики (в том числе мои), можно достаточно быстро накрапать нужное.

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

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

Ещё более единственным вариантом написание шаблона самостоятельно станет, когда будет осознан тот факт, что нужно также добавить в процесс создания переменные, которые могут что-то менять и отличаются для различных окружений, аккаунтов, регионов, назначений. Т.е. заложить в шаблон не только возможность автоматического разворачивания, но и организацию CI/CD-процесса с его помощью. А всё такое можно сделать лишь понимая зачем, для кого и самому.

Короче, всё печально, однако отговаривать не буду и обязательно попробуйте конвертилку в действии. Не стоит верить на слово — убедитесь лично.

#удачи

Бэкапимся сразу на S3

PostgreSQL

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

pg_dump --host=some.host.us-east-1.rds.amazonaws.com --username=some_pg_user --dbname=some_db_name --compress=9 --verbose | aws --region=us-east-1 s3 cp - s3://some-bucket/my_dump.sql.gz

Дампы читаются редко, а весят много, потому добавим сохранение на STANDARD_IA:

pg_dump --host=some.host.us-east-1.rds.amazonaws.com --username=some_pg_user --dbname=some_db_name --compress=9 --verbose | aws --region=us-east-1 s3 cp - s3://some-bucket/my_dump.sql.gz --storage-class STANDARD_IA

И шифрование:

pg_dump --host=some.host.us-east-1.rds.amazonaws.com --username=some_pg_user --dbname=some_db_name --compress=9 --verbose | aws --region=us-east-1 s3 cp - s3://some-bucket/my_dump.sql.gz --storage-class STANDARD_IA --sse aws:kms

MySQL

Аналогичный вариант для MySQL с paranoid_mode=on опцией (используется shred, чтобы врагам ничего досталось):

https://github.com/sparkcodeuk/kb/tree/master/mysql/mysqldump_to_s3

#backup #s3

⁠Выбор типа EBS

Полезная статья по выбору #EBS:

https://aws.amazon.com/blogs/storage/maximizing-microsoft-sql-server-performance-with-amazon-ebs/

#EC2

⁠Сервисы по типу в различных облаках и on-prem

Картинка начала 2019-го года, полезна для поиска аналогичных сервисов в разных облаках.

Для тех, кто работает лишь с AWS и считает его безусловным лидером (что так и есть) может быть откровением, что набор сервисов в Azure больше (что так и есть).

#AWS #Azure #GCP #Oracle #IBM #Alibaba #info

Билет 3
===
Как можно сохранить файл с его правами 755 на S3?

1. Это невозможно.
2. Можно через S3 API.
3. Можно только сохранив в архиве.
4. Можно с помощью Lifecycle в AWS Console.

#AWS_Certification #training

⁠Ответы на Билет 3 по S3

S3 - объектное хранилище, а не файловая система, потому прикрепить информацию о правах файла невозможно (ведь в #s3 хранятся объекты, а не файлы - как и следует из названия). Потому ответы 2 и 4 отпадают.

Однака аттрибуты файла можно сохранить в архиве:

tar czf my_file.tar.gz my_file

Который уже сохранить на S3 (в виде объекта). Потому правильный ответ - 3.

===

Цель вопросов по Билет 3 - запомнить, что S3 - это про объекты, а не файлы. Несмотря на то, что там хранятся файлы, все говорят про него как "файловое хранилище", используют термин "путь к файлу", а в консоли даже можно создать "папки" (create folder).

#AWS_Certification #training #answers

Специалист AWS по базам данных

Добавилась шестая специализация в сертификатах AWS - специалист по БД:

https://d1.awsstatic.com/training-and-certification/docs-database-specialty/AWS%20Certified%20Database%20-%20Specialty%20Exam%20Guide_v1.0_08-23-2019_FINAL.pdf

#AWS_Certification

Автоматизация удаления аккаунта в AWS Organization

На данный момент удалить аккаунт в организации - больная боль. Удалив ресурсы вы всего лишь закрываете аккаунт и он продолжает оставаться в вашей организации месяцами (в статусе closed).

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

А пока предлагаю почитать детектив на тему автоматизации удаления аккаунтов. Спойлер - не делайте так, это опасно. Однако всегда интересно посмотреть на извращения настоящего профессионала.

https://onecloudplease.com/blog/automating-aws-account-deletion

#Organization

⁠Просто и со вкусом или --query в aws-cli

Очередная текущая задача, где в терминале нужно было быстро найти нужный VPC ID по известному диапазону адресов для неё (CIDR block).

Выполняем очевидную команду для этого:

aws ec2 describe-vpcs

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

Для этого многие ставят jq, который сделает что угодно с json выводом. Однако не нужно забывать про флажок --query, который из коробки есть в любой #aws_cli.

Итак, смотрим верхние строчки результата работы:

{
   "Vpcs": [
       {
           "VpcId": "vpc-04bec1a347f431036",
...
           "CidrBlock": "10.11.0.0/16",
...

Нас интересуют элементы VpcId и CidrBlock, для этого перебираем все выведенные Vpcs, получается следующая конструкция:

aws ec2 describe-vpcs --query Vpcs[*].[VpcId,CidrBlock]

[
   [
       "vpc-04bec1a347f431036",
       "10.11.0.0/16"
   ],
   [
       "vpc-6b9b1111",
       "172.31.0.0/16"
   ]
]

Уже хорошо, лишь то, что нужно, можно довольствоваться. А можно сделать ещё и красиво:

aws ec2 describe-vpcs --query Vpcs[*].[VpcId,CidrBlock] --output table

#query

⁠Какие AWS сервисы используют Security groups?

Решили расчистить заброшенный аккаунт от ненужного и обнаружили сотню-другую неизвестно чьих и используемых ли security groups?

Зачистка

Самый простой способ почистить ненужные-неиспользуемые #sg - просто взять и удалить. Вот так просто выделить все и удалить.

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

Прополка

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

Либо на группу кто-то ссылается (в том числе она сама на себя - см.картинку). Либо её использует какой-то инстанс, в том числе остановленный. Или даже некоторое время (до получаса бывает) удалённый.

Сервисы

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

Часть удалилось, но часть нет. Какие же сервисы ещё используют security groups? Напрягаем логику и вспоминаем про Лямбду (умеющую ходить в VPC) и что у нас бесхозный Redis в углу завалялся из ElastiCache, который тоже имеет security group. StackOverflow подсказывает, что sg ещё есть у EMR и Redshift. Всё?

А вот и не всё. Вот полный список сервисов, использующих security groups:

AppStream
Batch
CodeBuild
DAX
DMS
DocDB
EC2 (AutoScaling, ELB, ALB, NLB)
ECS
EFS
EKS
ElastiCache
Elasticsearch
EMR
Events
FSx
Glue
Lambda
MediaLive
MSK
Neptune
OpsWorks
RDS
Redshift
Route53 (Route53Resolver)
SageMaker

Удачной борьбы с сорняками!

#security_groups

⁠Поиск по IAM политикам

Для этого есть очень хороший секретный ресурс:

https://iam.cloudonaut.io/reference

Здесь находится список всех #IAM политик на текущий момент с возможностью разнообразного поиска.

Например, для поиска tag-supported сервисов в поле Conditions задаём ResourceTag и получаем актуальный список для такой манипуляции.

#info

Расходы на прод против остальных

Интересные цифры: в AWS проектах обычно на prod-окружения уходит около 80% денег, на dev/stg/test/etc — 10-20%.

А как у вас? Сколько уходит на non-prod окружения? Примерно.

#опрос #расходы #статистика

Для внутренних адресов можно выбрать несколько регионов, описанных в RFC1918:

10.0.0.0    - 10.255.255.255  (10.0.0.0/8     prefix)
172.16.0.0  - 172.31.255.255  (172.16.0.0/12  prefix)
192.168.0.0 - 192.168.255.255 (192.168.0.0/16 prefix)

и RFC6598:

100.64.0.0 - 100.127.255.255 (100.64.0.0/10 prefix)

Из четырёх "удобными" являются лишь два - 10.0.0.0/8 и 192.168.0.0/16. Их подсети описываются очевидной схемой 10.х.х.х и 192.168.х.х, хорошо запоминаются и потому вероятность ошибиться минимальна, не путая локальные адреса с публичными.

Кроме того, Docker использует по умолчанию регион 172.17.0.0/16 - пересечение с ним обеспечит незабываемые ощущения при отладке. Равно как и дефолтная подсеть VPC в Амазоне это 172.31.0.0/16, что сделает проблемным возможный пиринг при использовании такого же региона.

Потому в общем случае не стоит мудрить и использовать для CIDR block подсети из 10.х.х.х (10.0.0.0/8) — много адресов и обычно они банально короче (меньше кнопок жать).

#VPC #CIDR

⁠Disallow Actions as a Root User

Полгода назад я добавил тэг #paranoid к посту про защиту от работы из-под рута, а теперь это в официальной документации:

https://docs.aws.amazon.com/controltower/latest/userguide/strongly-recommended-guardrails.html#disallow-root-auser-actions

S3 history

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

Нужно - понимать. А чтобы как раз понимать - нужно знать как оно было и почему стало как сейчас.

Итак, отметим лишь точку отсчёта:

https://aws.amazon.com/blogs/aws/amazon_s3/

В общем - #S3 вместе с #SQS и #EC2 ведут свой отсчёт с 2006-го года.

Это время расцвета VPS-хостингов со всей болью, помноженной на стоимость и ненадёжность при существенных нагрузках. Айфон лишь рождался, а крупным потребителям вычислительных мощностей всё приходилось делать самим. Потому с появлением первого крупного игрока, обещавшего SLA 99,99%, огромное количество будущих крупных клиентов Амазона бросились изучать возможности и стабильность его сервисов, в первую очередь S3.

Цена в 15 центов за гигабайт на то время была вполне себе конкурентной, потому основными в тестах была надёжность и стабильность доступа на протяжении длительного времени. Одними из первых крупных интересантов выступили штатовские универы, которые хотели избавиться от расходов на железо и перекинуть всё своё хозяйство в Амазон.

Через годик, убедившись в достаточной надёжности, они стали активно переходить туда.

За сим завершу литературно- и околомаркетинговое словоблудие о причинах и результатах создания S3. В следующей части перейду к суровым будням протодевопсов (их тогда ещё предательски называли сисадминами).

#s3_history #history