⁠Доступ к бакету для всех аккаунтов организации

Бывает нужно быстро и просто расшарить какой-то бакет или его часть для всех, но не "для всех вообще", т.е. в интернете, а только "для своих всех".

В случае #multi_account_strategy данная задача преобразуется в "расшарить для всех аккаунтов организации". Для этого существует специальная опция PrincipalOrgID, которую и можно использовать:

{
 "Sid": "Full access to path /some-path for all of organization accounts",
 "Effect": "Allow",
 "Principal": {
   "AWS": "*"
 },
 "Action": "s3:*",
 "Resource": [
   "arn:aws:s3:::my-shared-bucket",
   "arn:aws:s3:::my-shared-bucket/some-path/*"
 ],
 "Condition": {
   "StringEquals": {
     "aws:PrincipalOrgID": "o-dtj1bor777"
   }
 }
}

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

#s3 #organization

⁠AWS vs Multi-cloud

В недавно объявленном пособии AWS Co-Branding Guide присутствуют прекрасные строчки:

Multi-cloud: AWS does not allow or approve use of the terms “multi-cloud,” “cross cloud,” “any cloud,” “every cloud,” or any other language that implies designing or supporting more than one cloud provider.

Дипломатичным комментарием к этому может быть только, что неправильно бороться с глобальными трэндами, один из которых — это использования multi-cloud стратегии, которая формируется благодаря уже сформированному трэнду под названием #kubernetes.

А недипломатичным — не надо ссать против ветра, товарищи.

#multi_cloud

⁠Подбор паролей с помощью AWS API Gateway

Граждане из Rhino Security Lab продолжают пугать амазоновский огород своими страшилками. На этот раз они показали, как из API и палок можно построить себе на free tier подбиралку ваших паролей:

https://rhinosecuritylabs.com/aws/bypassing-ip-based-blocking-aws/

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

#security

Паникуем кернел через aws-cli

Для любителей блюскринов (Windows) и kernel panic (Linux) есть возможность сделать это вручную, то есть через #aws_cli:

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/diagnostic-interrupt.html

Ищем подходящую жертву:

aws ec2 describe-instances --query "Reservations[*].Instances[*].[InstanceId,Tags[*]]"

Обновляем aws-cli до версии 1.16.218 или новей и запускаем команду send-diagnostic-interrupt:

aws ec2 send-diagnostic-interrupt --instance-id i-0ba0c34123549d451

В результате на пострадавшем инстансе получаем что-то типа (если Linux):

Message from syslogd@ip-10-11-13-136 at Aug 15 13:06:15 ...
 kernel:Uhhuh. NMI received for unknown reason 21 on CPU 0.
Message from syslogd@ip-10-11-13-136 at Aug 15 13:06:15 ...
 kernel:Do you have a strange power saving mode enabled?
Message from syslogd@ip-10-11-13-136 at Aug 15 13:06:15 ...
 kernel:Dazed and confused, but trying to continue

Хакеры в помощь

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

Тогда вспоминаем, что у хакеров, в отличие от вас, все ходы записаны. Идём на совершенно бесплатный сайтик:

https://dnsdumpster.com/

Вбиваем свой домен и смотрим, что они там о нас знают.

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

База построена на данных сервиса https://scans.io/ - да, это те, которые постоянно гадят в лог любого сервиса любой вашей виртуалки.

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

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

#пятничное #security

===

Добавлено (из комментариев в личку):
Если вы не курите, ходите в качалку и на английский, то значит без шансов — в понедельник.

Как добавить свою фичу в CloudFormation

Предпочитающим #CloudFormation кроме спокойствия и выдержки в ожидании добавления уже имеющегося в консоли, также посоветую следующий способ поделиться с амазонозаводчиками собственными чаяниями.

Помните (или знайте), в Амазоне несколько есть глобальных долгоиграющих трендов.

1. "Тэгизация" всего — к любому ресурсу должна быть возможность добавить тэги. Это нужно для детального учёта стоимости, а также для tag-based схемы работы с #IAM.

2. "Параметризация" всего - максимальная интеграция сервисов Secrets Manager и SSM Parameter Store для возможности использования своих переменных оттуда.

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

https://github.com/aws-cloudformation/aws-cloudformation-coverage-roadmap/issues/126

Запрос попадает в п.2 трендов, потому, думаю, не пройдёт и полгода, как такая фича появится. Засекаем время и ждём. А ждать, как много раз говорилось, все, кто использует CloudFormation — умеют и должны.

#время_пошло

AWS и доброта

Если вы случайно запустили какую-то вещь на Амазоне, которая сожрала *censored* сколько денег, то перед тем как пойти напиться и гуглить прайс на продажу органов, знайте про следующий лайфхак.

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

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

#доброта_спасёт_мир

Сustom CNAME для CloudFront со своим сертификатом

Сказка. В тридевятом проекте, в тридесятом аккаунте жил-был environment. Порождённый богом CloudFormation он рос здоровым, занимался спортом, не курил, пользовался секретами и регулярно бэкапился. И всё у него было хорошо.

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

com.amazonaws.services.cloudfront.model.InvalidViewerCertificateException: The certificate that is attached to your distribution was not issued by a trusted Certificate Authority. For more details, see: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/CNAMEs.html#alternate-domain-names-requirements (Service: AmazonCloudFront; Status Code: 400; Error Code: InvalidViewerCertificate; Request ID: 336e6167-b7a6-11e9-b5c2-3166fadb8c22)

Чешет темя дед — как же ж так, то ж зимой ещё работало, а теперича уже нет.
Полез дед в интернет, а там Амазон ему и говорит человеческим голосом:

Amazon CloudFront enhances the security for adding alternate domain names to a distribution

Для твоего добра, мол, стараюсь, тебя, глупого, от Змея от Горыныча боронить что б. Спасибо б лучше сказал и нечего тут в меня гуглом тыкать.

Загрустил дед, что ж ему с сертификатом-то своим самоподписанным делать, как теперь его в CloudFront запихать?

В общем пошёл дед по форумам, по закоулкам. Ходил день, ходил ночь, по серверам заморским и на кухню в холодильник. Но нашёл таки управу на Амазона хитрого.

Взял дед правильный сертификат, сервисом ACM выпущенный да запихал его в CloudFront. И не подавился тот, съел да не поморщился. А опосля, хитрый дед, уже вторым заходом, сменил его на свой собственный, с гербом и печатью. И получилось как раньше было.

И пошёл к царю, рассказать про битву страшную и показать зелье сваренное супротив Амазона хитрого. И сказал ему царь - ну, спасибо, тебе, дед, заколебались тебя ждать, где так долго шлялся-то?

===

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

===

п.с. Итого. Создать Custom CNAME для #CloudFront со своим сертификатом нельзя (теперь). Однако проверка "трастовости" сертификата происходит лишь при создании CNAME. А значит можно сначала создать с "нормальным", а потом поменять на свой.


Ссылки по теме:

• https://aws.amazon.com/blogs/networking-and-content-delivery/continually-enhancing-domain-security-on-amazon-cloudfront/
• https://aws.amazon.com/premiumsupport/knowledge-center/cloudfront-invalid-viewer-certificate/
• https://aws.amazon.com/premiumsupport/knowledge-center/custom-ssl-certificate-cloudfront/
• https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/troubleshooting-distributions.html

#сказка

⁠SSM Session Manager + Port Forwarding

Очередной последний гвоздь в крышку Bastion схемы работы - теперь можно через SSM прокидывать на локальный комп нужный порт.

Потестируем. Как обычно, для всех новых фич обычно требуется последние версии всего. Смотрим версию #aws_cli:

aws --version
aws-cli/1.16.218 Python/2.7.14 Linux/4.14.97-90.72.amzn2.x86_64 botocore/1.12.208

Для порт-форвардинга требуется 1.16.220 и новей, так что обновляем.

aws --version
aws-cli/1.16.228 Python/2.7.14 Linux/4.14.97-90.72.amzn2.x86_64 botocore/1.12.218

Теперь 1.16.228 - можно двигать дальше. Проверяем и ставим, если ещё не ставился session-manager-plugin.

Проверяем версию агента (на картинке снизу) - не самая свежая, но можно и древней (2.3.672.0 и новей).

Значит можно запускать. В моём случае запуск в другом аккаунте, потому используется флажок --profile:

aws --region=us-east-1 --profile=openfs ssm start-session \
--target i-08a829418da3d9b15 \
--document-name AWS-StartPortForwardingSession \
--parameters '{"portNumber":["80"],"localPortNumber":["8080"]}'

Starting session with SessionId: botocore-session-1567069474-007a8050d8e22a3ed
Port 8080 opened for sessionId botocore-session-1567069474-007a8050d8e22a3ed

portNumber - это порт на инстансе, который будет форвардиться на наш локальный порт на компе localPortNumber.

Открываем в браузере 127.0.0.1:8080 и видим локально у себя локальное на удалённом инстансе. Либо доступ к базе, какому-то сервису - в общем, любому порту.

Поигравшись жмём CTRL-C и (с некоторым лагом) сессия оборовётся.
^CTerminate signal received, exiting.

Итого - отличная штука, бесплатная (только за трафик) - точно стоит освоить и пользоваться.

#ssm #session_manager

Амазоновский прайс на домены (одним файлом, по прямой ссылке, без смс и регистрации):

https://d32ze2gidvkk54.cloudfront.net/Amazon_Route_53_Domain_Registration_Pricing_20140731.pdf

#info

AWS Certification

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

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

Популярная пятёрка сертификатов следующая:

Certified Solutions Architect – Associate
Certified Developer – Associate
Certified SysOps Admin – Associate
Certified DevOps – Professional
Certified Solutions Architect – Professional

Подробности по официальной ссылке:

https://aws.amazon.com/certification/certification-prep/

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

#AWS_Certification

CloudFront и формат написания S3 бакета

1. В уже совсем древние времена все бакеты адресовались как:

s3.amazonaws.com/my-bucket

2. Потом формат мигрировал в "поддоменный" вариант:

my-bucket.s3.amazonaws.com

3. После активного размножения регионов добавился "региональный" формат:

my-bucket.s3.some-region.amazonaws.com

===

1.
Первый вариант уже давно depricated и если у вас старый код, который достался в наследство и его нужно завести - смотрите связанные с этим проблемы. Для нового его использовать нельзя.

2.
Второй вариант вполне работоспособен на сегодня. Если бакет не в регионе us-east-1 (N.Virgina - дефолтный регион), то амазон сам определит где он и средиректит запрос в нужный регион, т.е. переделает его в формат третьего варианта.

Кстати, такое поведение (редирект) "под капотом" может давать хитрые ошибки для свежесозданных бакетов. Это когда вы всё делаете через CloudFormation. В таком случае из-за того, что информация о редиректе созданного в другом регионе бакета обновляется не сразу (а окружение через CloudFormation может подняться/обновиться быстро), то вы получаете ошибку 307 — т.к. редирект уже есть, а записи куда редиректится ещё нет. Через некоторое время (до получаса) всё отработает как надо, но паника может наступить раньше очистки кэша.

3.
Третий вариант ранее работал наравне со вторым. Однако теперь это уже не так. В случае работы с новым регионом me-south-1 (Bahrain) работает только третий вариант.

my-dubai-bucket.s3.me-south-1.amazonaws.com

Аналогично будет с Италией и всеми последующими новыми регионами.

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

Первоисточник:

Another option might be to use the following more general format, but be aware that this format doesn't work for Regions launched in 2019 or later


#CloudFront #S3 #AWS_Region

⁠Хорошая картинка по всем базам данным и не только. Можно наглядно и быстро соотнести сервисы Амазона с другими решениями с классификацией по типу.

Первоисточник.

#info

⁠Девопс здорового человека

Популярность вариантов сертификации AWS (по версии читалей этого канала):

1. DevOps Engineer - Professional (52 голоса)
2. Solutions Architect - Associate (22 голоса)
3. Solutions Architect - Professional (13 голосов)
4. SysOps Administrator - Associate (4 голоса)
5. Developer - Associate (1 голос)

Итого по результатам. Девелоперами и админами быть не модно. Модно быть архитектом, а ещё популярней девопсы, которые обогнали обоих архитектов даже по сумме.

Что я имею сказать по этому поводу. Повинуясь воле большинства, загуглил я вопросы на девопс-профи. И вот теперь буду молвить.

DevOps Engineer - Professional

В далёком и страшном прошлом, когда CloudFormation ещё не поддерживал Yaml, я много и славно шаблонил ElasticBenstalk-и. Это было прикольно, удобно и быстро. Правда, когда мало и ненадолго. А если вдлинную, серьёзно и с использованием только кошерных сервисов, то всё обрастало OpsWorks. Строго по рекомендациям лучших амазонозаводчиков, по мере усложнения: EB → OpsWorks → CloudFormation.

С приходом всеобщего докера, два-три года назад этот способ работы был захоронен и всё благополучно переехало в ECS. А нонче (не)благополучно мигрирует в EKS, т.к. куберы на текущий момент суть самый что ни на есть тру девопс-вэй.

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

Вы это серьёзно, да? Это по версии AWS экзаменаторов есть современный профи-девопс? То есть вот совсем без AWS Code-сервисов, без ECS, EKS и Лямбд???

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

Предположу, жавшие «DevOps Engineer - Professional» не знали (как и я до этого), что в результате им придётся здесь читать про Chef и что в ElasticBeanstalk спустя два года так и не завезли Amazon Linux 2 (в качестве основного образа используется только первый - фу два раза, Амазон). Что ж, теперь знаете (и можно пойти переголосовать).

Solutions Architect - Associate

Короче, я обожду, когда в Амазоне завяжут с курением, а пока перехожу к девопсу здорового человека, второму пункту: «Solutions Architect - Associate». Краем глаза глянул - вроде вопросы вменяемые и темы адекватные. Значит будем готовиться.


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

https://habr.com/ru/post/329840/

#AWS_Certification

Как разбить монолит на микросервисы - рекомендация от Амазона с картинками и описанием:

https://aws.amazon.com/getting-started/projects/break-monolith-app-microservices-ecs-docker-ec2/

#design

Вам достался монолит, который нужно развернуть на AWS EC2. Монолит имеет встроенную MongoDB, которой по документации на чтение требуется random I/O более 250 000 4КБ IOPS.

Какой из вариантов вы выберете?

#AWS_Certification #training

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

---

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