Сервисы #AWS по их наличию в регионах.

#aws_region

Пинги между регионами #AWS - https://www.cloudping.co/

#info #aws_region

⁠Стэк для VPC peering должен быть в том же регионе (cross-region появился в конце 2017), где находится VpcId:

peerManagementVpc4:
Type: 'AWS::EC2::VPCPeeringConnection'
Properties:
VpcId: !Ref VpcManagement
PeerVpcId: !Ref Vpc4
PeerOwnerId: !Ref AwsAccountVpc4
PeerRoleArn: !Ref RoleInVpc4

т.к. #CloudFormation ищет VpcId именно в этом регионе (аккаунте), а в шаблоне (т.е. в самом CloudFormation #templates) нет возможности задать регион (как минимум - пока).

В результате при попытке это сделать через шаблон будет #error:
VpcPeeringConnection failed to stabilize

А потому #cross_region #vpc_peering пока можно сделать лишь вручную через консоль (где есть возможность задать #aws_region).

⁠Выбор AWS региона

Пинг (latency)

При выборе региона для окружения обычно чаще всего ориентируются на пинг:
• от вас до региона
• от заказчика до региона
• от региона до большинства клиентов

Идеально, когда они все совмещены и тогда можно просто проверить это прямо из браузера:

https://www.cloudping.info/

Иначе выбор уже определяется другими факторами.

Стоимость

Ресурсы в разных регионах стоят по-разному, иногда отличие существенное, потому это как минимум стоит учесть:

https://www.concurrencylabs.com/blog/choose-your-aws-region-wisely/

Сервисы

Не все сервисы представлены (появляются) сразу во всех регионах, если это важно, то сверяемся здесь:

https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/

===

Если же у вас нет особых предпочтений и требований, то совет:

В любой непонятной ситуации выбирай N.Virginia.

#aws_region #info

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

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

Допустим, что на вашем проекте используются лишь регионы 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

EC2 виртуалки — выбираем регион в Европе

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

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

https://www.cloudping.info/

Вот характерная картинка, сделана прямо сейчас при написании поста, отражает обычный расклад (из Минска):

Ireland   67 ms
London   49 ms
Frankfurt 46 ms
Paris    57 ms
Stockholm 34 ms

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

Стоимость EC2

Однако есть ещё и стоимостной момент. Разброс цен на EC2 виртуалки есть и в купе с пингом вполне может заставить по-другому смотреть на выбор региона. Если взять Ирландию как 100% цены, то на текущий момент получается следующая картина:

Stockholm  94.7%
Ireland   100.0%
London   103.5%
Paris    103.5%
Milan    105.0%
Frankfurt 105.3%

Самый дорогой Франкфурт! Не знали, да? Я вот помнил, что он дорогой, однако уже подзабыл и считал самым дорогим недавно появившийся Милан. А вот и нет.

Однако интересно отметить относительно дешёвый Стокгольм. В случае Минска получается и дешевле и быстрей — хороший повод подумать. Особенно, если сидите во Фракфурте, то получаете при переезде в Стокгольм -10% в ценнике и при этом быстрей!

https://aws.amazon.com/ec2/pricing/on-demand/

Короче, всё течёт, всё меняется. И появляется повод сэкономить и ускориться!

#AWS_Region #cost_optimization #EC2

​​Красивый тест для выбора ближайшего AWS региона:

▪️ https://cloudharmony.com/speedtest-for-aws

Отличное (лучшее?) дополнение к выбору AWS региона с помощью CloudPing:

▪️ https://www.cloudping.info/
▪️ https://www.cloudping.co/grid

И тесту эффективности использования S3 Transfer Acceleration от самого Амазона:

▪️ http://s3-accelerate-speedtest.s3-accelerate.amazonaws.com/en/accelerate-speed-comparsion.html

Добавлено — ещё один красивый тест (ещё более красивый? 😄) выбора AWS региона:

▫️ https://www.awsspeedtest.com/

Если знаете/используете другие тесты для этого – добавляйте в комментариях.

#AWS_region

​​New AWS Local Zones

Europe has received 12 new AWS Local Zones, South America - 5, India - 4, North America - 3, Africa - 2, Australia - 2, Canada - 2:

https://aws.amazon.com/about-aws/global-infrastructure/localzones/locations/

And we have three AWS Local Zones without an AWS Region, so we can expect a new AWS Region to appear in Vietnam, as it was in my prediction about the new CloudFront Edges.

AWS Region related to the new AWS Local Zone
🔸 City, Country

Canada Central
🔸 Toronto, Canada
🔸 Vancouver, Canada

Cape Town
🔸 Johannesburg, South Africa
🔸 Nairobi, Kenya

Frankfurt
🔸 Amsterdam, Netherlands
🔸 Berlin, Germany
🔸 Munich, Germany
🔸 Prague, Czech Republic
🔸 Vienna, Austria
🔸 Warsaw, Poland

Hyderabad
🔸 Bengaluru, India
🔸 Chennai, India
🔸 Kolkata, India

Milan
🔸 Athens, Greece

Mumbai
🔸 Delhi, India

N. Virginia
🔸 Bogotá, Colombia
🔸 Buenos Aires, Argentina
🔸 Lima, Peru
🔸 Santiago, Chile

Paris
🔸 Brussels, Belgium

Stockholm
🔸 Copenhagen, Denmark
🔸 Helsinki, Finland
🔸 Oslo, Norway

Sydney
🔸 Auckland, New Zealand
🔸 Brisbane, Australia

Spain
🔸 Lisbon, Portugal

Melbourne
🔸 Perth, Australia

Ohio
🔸 Querétaro, Mexico

Sao Paulo
🔸 Rio de Janeiro, Brazil

Without AWS Region
🔸 Bangkok, Thailand
🔸 Hanoi, Vietnam
🔸 Manila, Philippines

Interestingly that 4 out of 5 new Local Zones in South America belong to the N.Virginia AWS Region.

#AWS_Region