⁠Три часа, положенные на экзамен вышли — разбор ответов.

---

EBS optimized instances (2 шт.) выбрали меньше всех — действительно, неправильный и просто бессмысленный, путающий ответ.

---

H1 Instances configured in RAID 10 mode (6 шт.) — второй по популярности, неправильный ответ.

Кто загуглил или знает, что H1 относятся к типа Storage Optimized - могли повестись. Однако засада скрывается в RAID, который предназначен для увеличения пропускной способности, т.е. это последовательное, а не случайное чтение (random I/O, как обозначено в задании).

---

Остаются два, выглядящих подходящими, ответа, которые в процессе голосования менялись местами, но после с большим отрывом вырвался вперёд EBS provisioned IOPS (32 шт.) - и это неправильный ответ.

Требуется более глубокие знания в этом вопросе, то есть фактология. Можно и логикой, в принципе, т.к. цифра в 250 000 иопсов должна вызвать подозрение (своей величиной). Это ОЧЕНЬ много, текущий максимум, что даёт Provisioned IOPS - это 64 000.

===

Потому методом исключения остаётся SSD instance store (14 шт.) - и это правильный ответ.

#AWS_Certification #training #answers

Вопрос по IAM

Спонсор выпуска - заслуженный медиум, полный кавалер подписки на #IAM в четырёх томах, Karen Tovmasyan. Прочитавшему всю его тетралогию (том 1, том 2, том 3, том 4) данный билет покажется смешным. А остальным стандартно три часа на решение, гугление и звонок другу.

===
Билет 2
===

Прилетела задача из дружественного отдела, которые пилят что-то своё финансовое под винду, а потому сидят на Ажуре. Они используют Azure Devops и для интеграции с вашей амазоновской частью их сервис должен ходить в вашу RDS PostgreSQL. У базы данных настроена авторизация по IAM.

Что правильно сделать?

1. Создать юзера с нужными правами, пусть используют его credentials и больше не пристают.

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

3. Создать юзера с нужными правами, сгенерировать ему Security Token, пусть себе пропишут и успокоятся.

4. Создать роль с нужными правами и раз это финансовое приложение, включить в ней condition требование на наличие правильного External ID.

===

#AWS_Certification #training

User vs Role для 3d Party сервисов

Билет 2 про взаимодествие с Амазоном других, внешних по отношению к нему, вещей. В данном конкретном случае шла речь про Azure, однако это точно также справедливао и для GCP, и для локального компьютера - короче, всего, кроме Амазона.

Чтобы найти ответ нужно понимать следующую вещь. Роль - это чисто амазоновская сущность, её можно "прикрепить" только к чему-то, что крутится на Амазоне и только на Амазоне. Например, к юзеру - он будет ею обладать, когда залогинится на Амазон (в консоль или программно) и получит права, в ней указанные. Но её никак нельзя "прикрепить" к чему-то "неамазоновскому", например, вашему коду локально на компьютере или on-prem. Как? Амазон же не сможет через интернет как-то связать вашу ОС или ваш внешний айпишник с IAM-политиками роли у себя внутри, верно? Для этого (чтобы соотнести) нужно авторизоваться как юзер - дальше юзер уже сущность амазоновская и с ней можно делать что угодно.

Получается, если вы хотите интегрировать неамазоновские вещи (локальные или Ажуровский сервис из вопроса) с Амазоном - они могут "заходить" в Амазон только как юзер. Точка. Роли отпадают, они правильный выбор, но ВНУТРИ Амазона. Всё внешнее (читай - "через интернет") — только с помощью юзера.

Так что второй и четвёртый ответы отпадают не вчитываясь.

Дальше уже просто логика. Использовать для юзера Security Token это звучит "по-безопасному", однако если вспомнить, что он ВРЕМЕННЫЙ - живёт максимум 36 часов, а значит не получится его "прописать и забыть" для какого-то сервиса (это же постоянные значения) - тоже отпадает.

Остаётся первый вариант.

===

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

Итого, целью Билет 2 было донести отличие работы внешних сервисов (3d Party) с Амазоном и что для этого потребуется именно юзер.

п.с. Упоминание #IAM авторизации базы данных было лишь для отвлечения внимания и к сути проблемы вопроса не относится.

#AWS_Certification #training #answers

Глобальные сервисы AWS

Подавляющее большинство сервисов Амазона для каждого региона свои. Однако есть глобальные сервисы, типа IAM, Route53 или CloudFront - про них знают (должны знать) все.

Полный же список (на текущий момент) глобальных сервисов следующий:

Alexa for Business
AWS Budgets
AWS Cost Explorer
Amazon Chime
Amazon CloudFront
AWS Cost & Usage Report
AWS Global Accelerator
AWS Health (Personal Health Dashboard)
AWS Identity & Access Management
AWS Import/Export Disk
Amazon Mobile Analytics
AWS Organizations
Amazon Route 53
Amazon Route53 Domains
AWS Shield
AWS Support
AWS Trusted Advisor
AWS WAF (Web Application Firewall)
AWS Well-Architected

В плане прав доступа к ним получится следующая заготовка для IAM:

a4b:*
budgets:*
ce:*
chime:*
cloudfront:*
cur:*
globalaccelerator:*
health:*
iam:*
importexport:*
mobileanalytics:*
organizations:*
route53:*
route53domains:*
shield:*
support:*
trustedadvisor:*
waf:*
wellarchitected:*

#IAM

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

Допустим, что на вашем проекте используются лишь регионы N.Virginia, Oregon и Ireland, а остальные вы хотите запретить вообще. Если используется #Organizations, то это реализуется с помощью #SCP.

https://docs.aws.amazon.com/en_us/organizations/latest/userguide/orgs_manage_policies_example-scps.html#example-scp-deny-region

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

Воспользуемся заготовкой из предыдущего поста и в результате получим "безошибочный" вариант:

{
 "Version": "2012-10-17",
 "Statement": [
   {
     "Sid": "OnlyOurRegions",
     "Effect": "Deny",
     "NotAction": [
       "a4b:*",
       "budgets:*",
       "ce:*",
       "chime:*",
       "cloudfront:*",
       "cur:*",
       "globalaccelerator:*",
       "health:*",
       "iam:*",
       "importexport:*",
       "mobileanalytics:*",
       "organizations:*",
       "route53:*",
       "route53domains:*",
       "shield:*",
       "support:*",
       "trustedadvisor:*",
       "waf:*",
       "wellarchitected:*"
     ],
     "Resource": "*",
     "Condition": {
       "StringNotEquals": {
         "aws:RequestedRegion": [
           "us-east-1",
           "us-west-2",
           "eu-west-1"
         ]
       }
     }
   }
 ]
}

#IAM #AWS_Region

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