Upcoming free webinar: Solving AWS VPC CIDR overlaps

AWS VPC CIDR overlaps can cause routing conflicts, security gaps, and operational issues. This live session with AWS-certified expert Serhii Kaidalov provides you with practical strategies to resolve these challenges.

🔍 What You’ll Gain:
- Effective strategies to identify and resolve CIDR overlaps
- Step-by-step insights into implementing AWS-specific solutions
- Expert tips to secure your network and streamline operations

👨‍💻 Speaker: Serhii Kaidalov - 8x AWS-certified Solution Architect with over 6 years of experience in DevOps and Cloud
📅 Date and time: November 20th, 11:00 UTC-5

🎟 Secure your spot: https://bit.ly/4ewxMWZ

🚀 Join our AWS Workshop on November 21st! 🚀

We are excited to announce that on Thursday, November 21st, we are hosting an AWS Workshop "One Observability Workshop", open to everyone!

☁️ November 21, 2024
☁️ Free of charge
☁️ Online
☁️ English

This workshop provides hands-on experience with a wide variety of tools AWS offers for monitoring and observability.

The workshop will be led by Sergey Kirgizov, an AWS expert and Cloud Engineering Manager I at EPAM Systems.

We will provide a dedicated training account for each participant who registers via the Google Form (https://forms.gle/EeEPVPNCUGfc18Qq7). However, you can also use your personal AWS account to participate.

IMPORTANT: Please make sure to complete the Google Form https://forms.gle/EeEPVPNCUGfc18Qq7 registration by 22:00 UTC+2 on November 20th.

Find out more details and register for the workshop via the link below:
https://wearecommunity.io/events/one-observability-workshop

🆕 Lambda SnapStart + Python / .NET

https://aws.amazon.com/blogs/aws/aws-lambda-snapstart-for-python-and-net-functions-is-now-generally-available/

Фича SnapStart, ускоряющая ColdStart Лямбды в 10 раз, теперь и для Python, и для .NET.

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

P.S. Вадим Казулкин, который наклепал десятки полезных материалов по ColdStart для Java, теперь получит ещё в два раза больше работы. 😀

#Lambda

AWS SSO + PKCE

https://aws.amazon.com/blogs/developer/aws-cli-adds-pkce-based-authorization-for-sso/

⚠️ Требуется AWS CLI версии 2.22.0 или более новая.

#SSO

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

CloudFront VPC origins — подключаем CloudFront к приватным ALB/NLB/EC2

https://aws.amazon.com/blogs/aws/introducing-amazon-cloudfront-vpc-origins-enhanced-security-and-streamlined-operations-for-your-applications/

CloudFront — публичная сущность, поэтому просто так добраться до приватных ресурсов не может по определению. Кто хотел раздавать приватный контент, приходилось создавать внешний балансер. А для внутренних (в приватной подсети) балансеров такое сделать было нельзя.

CloudFront VPC origins решают эту проблему. Сначала вы создаёте CloudFront VPC origin в нужной VPC — по сути прокси для доступа в VPC из CloudFront. После этого можно выбрать созданный CloudFront VPC origin в качестве Origin в вашем CloudFront.

Ещё один набор костылей / лишних балансеров можно удалить.

P.S. При таком подходе (CloudFront VPC origins) могут возникнуть вопросы у безопасников. Возможность так лихо раздавать из интернета приватные ресурсы их может не порадовать. Так что попытка сэкономить таким образом наверняка закончится дополнительными расходами на WAF. 😁

#CloudFront

Aurora Serverless v2 + scaling to 0 = настоящий ServerLess

https://aws.amazon.com/blogs/database/introducing-scaling-to-0-capacity-with-amazon-aurora-serverless-v2/

Как и для первой версии, теперь честный ServerLess доступен для Aurora Serverless v2. То есть можно скейлить в 0.

Отличный повод проапгрейдиться как минимум до PostgreSQL 13 и MySQL 3, если вы ещё нет, т.к. более старые не поддерживаются.

#Aurora #Serverless

☁️ RS AWS Club ☁️

Продолжаем серию практических встреч c Anton Kovalenko (Senior Solutions Architect, AWS Munich).

В эту пятницу, 22 ноября, нас ждет официальный старт рефакторинга приложения с помощью Amazon Q Developer. Без теории, а сразу реальная работа с кодом.

📺 Встреча пройдет в 15:00 CET (GMT+1) на нашем YouTube канале:
https://www.youtube.com/watch?v=jNJeB9BSnMY

Жмите колокольчик, чтобы не пропустить начало! 🔔

ALB + управление заголовками

https://docs.aws.amazon.com/elasticloadbalancing/latest/application/header-modification.html

Теперь можно задавать CORS сотоварищи прямо на ALB. А не напрягать чувствительных разработчиков вопросами "Где у вас тут переменная для изменения CORS?"

И для прохождения Compliance теперь всё просто — вырезаем "Server" заголовки от любого, даже легаси, приложения прямо на ALB.

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

#ALB

Lambda + Node.js 22

https://aws.amazon.com/blogs/compute/node-js-22-runtime-now-available-in-aws-lambda/

#Lambda

ElastiCache + Valkey 8.0 = в 4 раза более быстрый скейлинг при 20% меньшем потреблении памяти:

https://aws.amazon.com/blogs/database/amazon-elasticache-version-8-0-for-valkey-brings-faster-scaling-and-improved-memory-efficiency/

Напомню, Valkey — это Redis здорового человека.

#ElastiCache #Valkey #Redis

Step Functions + variables + JSONata:

https://aws.amazon.com/blogs/compute/simplifying-developer-experience-with-variables-and-jsonata-in-aws-step-functions/

#StepFunctions

🆕 Amazon EVS (Elastic VMware Service)

https://aws.amazon.com/blogs/migration-and-modernization/whats-next-for-vmware-workloads-on-aws/

Хм, скажет знающий читатель, что-то слышал такое, вроде ж было уже, нет?

Всё верно, было и даже всё ещё (пока) есть — VMware Cloud on AWS:

https://aws.amazon.com/vmware/vmwarecloudonaws/

Только это уже старый VMware сервис, он сломался после покупки VMware компанией Broadcom, который коварно выбрал GCP в качестве партнёра:

https://www.broadcom.com/company/news/product-releases/broadcom-and-google-cloud-announce-expanded-partnership-to-help-accelerate-innovation-for-enterprises

Однако AWS не загрустил и решил пилить свой собственный сервис, с блэкджеком и поддержкой VCF (VMware Cloud Foundation). При этом раздавая солидные бонусы для желающих перейти на светло-рыжую сторону — вплоть до 400$ кредитов за каждую смигрированную виртуалку:

https://aws.amazon.com/vmware/migrationaccelerator/

Маркетинг не подкачал и задействовал свой секретный скрипт:

echo "$([ $RANDOM -lt 16384 ] && echo "AWS" || echo "Amazon") Elastic $1 Service"

Так появился Amazon EVS, о подробностях которого расскажут на re:Invent 2024 (регистрируемся!).

P.S. А две недели вышла интригующая новость о то, что VMware Workstation и Fusion стали бесплатными:

https://blogs.vmware.com/workstation/2024/05/vmware-workstation-pro-now-available-free-for-personal-use.html

Совпадение? Не думаю!

#EVS #VMWare

Новый The Frugal Architect — теперь с блогами и подкастами:

https://thefrugalarchitect.com/

#design

PrivateLink + cross-region 💪

Критически значимое обновление. Теперь мы можем сделать свой сервис в N.Virginia, а клиент в Ireland при создании VPC Endpoint укажет к каким регионам (кроме своeй Ирландии) он хочет присоединиться.

Сделано это путём создания приватных туннелей между AWS Regions с использованием сетевой инфраструктуры AWS (без выхода в интернет) для конкретного поставщика сервиса на уровне его региона. Это значит, что поставщик сервиса заплатит дополнительно по 0.05$ за каждый регион (кроме его родного) вне зависимости от количества его сервисов в этом регионе. То есть хоть один, хоть 10 — всё завернётся в один туннель (интересно будет услышать на счёт производительности в таком случае).

Клиент же заплатит дополнительно за трансфер данных между регионами, как обычно — и за входящие, и за исходящие. Поэтому при большом трафике это может быть больно. Однако раньше такое или было невозможно, или приходилось костылять и платить всё те же суммы и больше.

https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html

В документации пока подробностей нет, приберегли вкусное на re:Invent 2024.

В купе с другими сетевыми фичами, а также прогрессом в S3, мы можем ожидать интересных анонсов по части distributed services.

#PrivateLink

В случае AWS деплоить не стоит по пятницам и ноябрям.

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

Сравнение AWS Regions по доступным сервисам, апишкам, типам EC2-виртуалок и RDS-базами данных.

https://region-comparison.aws.com/

Полезный дополнительный инструмент при выборе региона.

Например, при выборе Frankfurt vs Stockholm можно увидеть, каких сервисов нет в одном, какие при этом есть в другом. Также и для виртуалок и баз данных. Если вам прямо сейчас требуется DocumentDB — выбираем Германию, а если интересуют квантовые вычисления (то есть нужен Amazon Braket) или супер-мощные виртуалки для HPC-вычислений — выбираем Швецию.

#AWS_Regions #info

Data perimeter on AWS + RCP:

https://aws.amazon.com/identity/data-perimeters-on-aws/

Updated whitepaper:

https://docs.aws.amazon.com/whitepapers/latest/building-a-data-perimeter-on-aws/

#security

RCP policy для защиты от переключения извне в любую IAM Role любого вашего AWS аккаунта вашей AWS Organization:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Principal": "*",
            "Action": "sts:AssumeRole",
            "Resource": "*",
            "Condition": {
                "StringNotEqualsIfExists": {
                    "aws:PrincipalOrgID": "o-012345aabb"
                },
                "BoolIfExists": {
                    "aws:PrincipalIsAWSService": "false"
                }
            }
        }
    ]
}

Данная RCP жёстко убивает любые попытки взломать любой ваш аккаунт на уровне IAM. В том числе возможности оставить себе "дырочку" ходить в свой аккаунт для уволившихся сотрудников через шаринг переключения в IAM Role из какого-то AWS аккаунта.

#RCP #IAM #security