Теперь можно вешать целую подсетку (/28 для IPv4 и /80 для IPv6) на каждый сетевой интерфейс:

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-prefix-eni.html

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

#VPC

Как объединить сеть проектов в Azure и AWS с помощью managed решения:

https://techcommunity.microsoft.com/t5/fasttrack-for-azure/how-to-create-a-vpn-between-azure-and-aws-using-only-managed/ba-p/2281900

Отличная штука, чтобы не плодить свои костыли для соединения в общую сеть — полностью managed решение на базе сервисов Azure VPN Gateway и AWS Virtual Private Gateway. Особенно круто, что аналогично можно подключить и к AWS Transit Gateway.

#Azure #VPC

Advanced Amazon VPC design and new capabilities:

https://www.youtube.com/watch?v=fi3vcenH6UY

🔸 VPC networking overview
🔸 IPv6 only subnets
🔸 DNS64
🔸 NAT64
🔸 Resource-based instance naming
🔸 IPv6 targets for ALB/NLB
🔸 IPAM (IP Address Manager)
🔸 VPC enhanced routing
🔸 Private NATGW
🔸 S3 Interface Endpoint
🔸 PrivateLink: ALB + NLB integration
🔸 TGW Connect
🔸 TGW intra-region peering
🔸 Direct Connect overview
🔸 Direct Connect MACsec
🔸 Direct Connect + Local Zones
🔸 Direct Connect SiteLink
🔸 AWS Cloud WAN
🔸 Network Access Analyzer
🔸 VPC Reachability Analyzer

#VPC #TGW #IPv6 #reInvent #video

Плохие практики — VPC с двумя AZ подзонами или сколько правильно иметь AZ в VPC

Как показал опрос, 20% читателей используют фиксированные 2 AZ для разворота VPC. И действительно, для простоты и экономии, казалось бы, логично, использовать две AZ подзоны. Кучи примеров с такими настройками, презентаций, видео. Также многие просто руководствуются требованиями в документации, например, это минимальная рекомендация для ALB:

You must select at least two Availability Zone subnets.

Другие считают, что всё равно некоторые AWS регионы имеют лишь две AZ подзоны, потому логично ориентироваться на минимум для своих deployment скриптов, который подойдёт для всех.

Две (минимум) AZ

Попробуем разобраться в деталях, почему использовать лишь 2 AZ — плохая практика.

1️⃣ Во-первых, на текущий момент (начало 2022-го года) все AWS Regions имеют 3 AZ и больше.

2️⃣ Во-вторых, сами по себе AZ подзоны (как подсети для VPC) не стоят денег, потому в качестве экономического фактора не валидны.

3️⃣ В-третьих, это минимальное значение может стать крайне проблематичным в случае реального падения одной из AZ подзон.

Показательный случай был совсем недавно, 22 декабря 21-го года, когда упала USE1-AZ4 в N.Virginia после отключения электричества в её датацентре. По результатам падения, один из обладателей конфигурации с 2 AZ написал пост на Reddit, где пытался разобраться, почему 2 AZ не спасли от ошибок по таймауту.

Главные вывод следующий. Наблюдая проблемы в процессе их развития, он не мог быстро отреагировать на них, например, просто временно отключив одну из подсетей ALB (упавшей AZ4). А не смог он этого сделать как раз потому что минимальное значение подсетей для ALB, как было указано выше — 2 AZ! И потому ALB не дал возможности выбросить упавшую подзону.

Три AZ

Итого, если в VPC всего лишь 2 AZ, то нет возможности быстро/временно переконфигурировать сервисы, удалив из них проблемную AZ. Потому нормальным значением правильно считать 3 AZ или больше.

Максимум AZ

Про максимальное количество также стоит сказать. Кроме достаточно логичного, что в зависимости от используемого IaC, это может быть просто не шибко удобно по количеству кода, есть проблема другого характера. Некоторые AZ очень старые и уже давно не обновляются, в результате чего не имеют современных инстансов и можно получить ошибку "Your requested instance type is not supported in your requested Availability Zone":

https://aws.amazon.com/premiumsupport/knowledge-center/ec2-instance-type-not-supported-az-error/

Такая точно есть в N.Virginia и если нет возможности обрабатывать данную ошибку, то можно использовать лишь 5 AZ.

Сколько нужно AZ

А если добавить Local Zones, которые можно/нужно подключать, то управление и выбор подзон нонче правильно выносить в отдельный процесс, который нужно иметь возможность гибко конфигурировать.

#VPC #design

​​🆕 Transfer Elastic IP addresses from one AWS account to another:

https://docs.aws.amazon.com/vpc/latest/userguide/vpc-eips.html#transfer-EIPs-intro

✅ You can transfer Elastic IP addresses to accounts within the same AWS Organization.
✅ You can transfer Elastic IP addresses to standalone AWS accounts outside of AWS Organization.
✅ You can transfer Elastic IP addresses only within the same AWS Region.
❌ You cannot transfer Elastic IP addresses between AWS Organizations.

When you transfer an Elastic IP address, there is a two-step handshake between AWS accounts:
▪️ the source account (either a standard AWS account or an AWS Organizations account) and the transfer accounts.
▪️ when the source account starts the transfer, the transfer accounts have seven hours to accept the Elastic IP address transfer, or the Elastic IP address will return to its original owner.

#VPC

​​⛅ AWS re:Invent 2022 - Advanced VPC design and new Amazon VPC capabilities:

https://www.youtube.com/watch?v=cbUNbK8ZdA0

The main video from each re:Invent — and so every year. 😀

1:26 From the beginning
4:33 IPv6 (2021 releases)
7:20 ENA Express 💥 New
9:54 Network Address Usage
13:08 VPC Peering
14:07 Transit Gateway
19:22 Cloud WAN (2021)
25:15 Application networking
27:27 VPC Lattice 💥 New
37:00 Network Operations
37:39 Network Manager
38:29 Infrastructure Performance
40:23 CloudWatch Internet Monitor 💥 New
44:03 AWS Verified Access (AVA) 💥 New

#VPC #Lattice #CloudWatchInternetMonitor #AVA #reInvent

​​Теперь можно ссылаться на Security Groups из другой VPC, которая присоединена через Transit Gateway:

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-rules-reference.html#tgw-vpc-rules

Раньше можно было ссылаться на SG из других VPC только через VPC peering, теперь можно из через TGW. Правда для этого потребуется обновить TGW или VPC attachment:

https://docs.aws.amazon.com/vpc/latest/tgw/tgw-sg-updates.html

Особенности:

▪️ Ссылаться через TGW peering нельзя (VPC -> TGW -> TGW peering -> TGW -> VPC, только VPC -> TGW -> VPC).
▪️ Ссылаться можно лишь в правиле для входящего трафика.
▪️ Не работает на древних виртуалках (только Nitro-based EC2 instances).
▪️ Не работает на любых виртуалках, расположенных в древних датацентрах, конкретно подзона use1-az3 (которую всегда рекомендовал исключать).
▪️ Не работает, как минимум пока, с PrivateLink и Reachability Analyzer.

Кому-то мелкая вещь и бессмысленная вещь, а кому-то упрощение управление зоопарком Security Groups в сложной сети.

#VPC #TransitGateway #SecurityGroup

Лучший AWS VPC Terraform модуль для SRE

https://www.youtube.com/watch?v=DFeItULOeHc

Обсудили с Виктором его AWS VPC Terraform модуль:

https://github.com/ViktorUJ/terraform-aws-vpc

Хотите узнать, почему (не) надо писать собственный AWS VPC Terraform модуль — смотрите видео.

Комментарии, критика, а также подписка на канал и пулреквесты в репозитории Виктора — категорически приветствуются.

#Terraform #VPC #video

Теперь можно ссылаться на Security Group из другой VPC не только подключённую через VPC Peering, но и через Transit Gateway:

https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-security-group-referencing-for-aws-transit-gateway/

Для этого потребуется указать опцию. Security Group Referencing support при создании TGW или модифицировать имеющийся.

https://docs.aws.amazon.com/vpc/latest/tgw/tgw-vpc-attachments.html#vpc-attachment-security

⚠️ Также, как и для VPC Peering — работает лишь в том же AWS Region.

⚠️ Не сработает, если между VPC будет подключен AWS Network Firewall.

P.S. Закрыт ещё один гештальт длиной в шесть лет.

#SecurityGroup #VPC #TransitGateway

🆕 Shared Security Group 🎉

https://docs.aws.amazon.com/vpc/latest/userguide/security-group-sharing.html

Что ж, свершилось. С момента появления Shared VPC 6 лет назад, это первое, чего хотелось бы иметь в комплекте.

Как круто было пошарить VPC сразу на многие аккаунты! Но каждый раз нужно было решать проблему с Security Groups, которые при этом не шарились. Приходилось писать костыли, создающие Security Groups в каждом аккаунте вручную.

Топил за #Shared_VPC все эти годы, теперь же вместе с Shared Security Group это вообще круто. Шаринг VPC уже давно стал best practices, а вместе с шарингом Transit Gateway это вообще ключевые элементы для построения современной сетевой архитектуры в AWS.

#SecurityGroup #VPC #RAM

VPC Block Public Access или Security Groups для ваших Security Groups

https://aws.amazon.com/blogs/networking-and-content-delivery/vpc-block-public-access/

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

Желание адекватное — а сделайте нам выключатель, чтобы можно было оптом запретить внешний доступ сразу везде, а не бороздить просторы аккаунта в поисках ресурсов с Security Groups, разрешающих внешний доступ (равно как и запрет врагам и наивным разработчикам такое себе создать).

Теперь можно включить VPC Block Public Access и наличие открытого доступа в интернет, равно как и публичный айпишник, не помогут.

С другой стороны, это дополнительное усложнение сетевой части, ещё уровень абстракции, теперь нужно будет помнить не только про когда-то тобою же предательски настроенные NACL, но ещё и что из-за требований Security Hub был включен VPC Block Public Access. А тебе тут по-быстрому нужно что-то проверить-отладить.

В общем, безопасность продолжает наступать, поднимая сложность на новый уровень.

P.S. Опять обновлять примерно все базовые курсы по AWS. 😁

#VPC

Использование Shared VPC подхода на примере Swisscom

https://aws.amazon.com/blogs/industries/automated-networking-with-shared-vpcs-at-swisscom/

#VPC #SharedVPC

VPC + BGP = VPC Route Server with dynamic routing inside VPC

https://docs.aws.amazon.com/vpc/latest/userguide/dynamic-routing-route-server.html

You can now dynamically update VPC and internet gateway route tables with your IPv4 or IPv6 routes.

Features include:
- Automatically update route tables with routes learned from BGP peers
- Propagation of the best available routes based on BGP attributes
- Dynamically update routes when network conditions change
- Failure endpoints using BFD

There are still some gaps like the support for route tables associated with virtual private gateways or propagation of routes into a transit gateway route table.

#VPC

Resource Groups + PrivateLink

You can use PrivateLink to create a private connection between your VPC and Resource Groups.

https://docs.aws.amazon.com/ARG/latest/userguide/vpc-interface-endpoints.html

You can access Resource Groups as if it were in your VPC, without the use of an internet gateway, NAT device, VPN connection, or Direct Connect.

Instances in your VPC don't need public IP addresses to access Resource Groups.

#ResourceGroup #VPC #PrivateLink