​​Теперь можно задать диапазон IP-адресов для EKS кластера:

https://docs.aws.amazon.com/eks/latest/userguide/create-cluster.html

#EKS

Напомню, что сегодня CDK day. Начало в 17:00 по Киеву/Минску/Москве.

Кто не в курсе, CDK — возможность описывать инфраструктуру для AWS, Kubernetes или Terraform с помощью привычного языка программирования. Стоит посетить, чтобы просто ознакомиться с возможностями.

CDK day в прямом эфире:

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

Helm + ECR

Для стандартизации процессов в Kubernetes окружениях, использующих Helm для деплоя сервисов удобно иметь и чарты в виде докер-образов. Такая возможность на текущий момент в Helm доступна лишь в экспериментальном режиме:

export HELM_EXPERIMENTAL_OCI=1

В докер-реестрах других провайдеров такая поддержка уже была раньше, наконец, с сентября 2020-го года она есть и в ECR:

https://docs.aws.amazon.com/AmazonECR/latest/userguide/push-oci-artifact.html

Настроим переменные:

ECR_AWS_ID=123456789012
ECR_REGION=eu-central-1
CHART_DIR=my-chart
REPO_NAME=helm-repo
IMAGE_TAG=build-1

HELM_REGISTRY=${ECR_AWS_ID}.dkr.ecr.${ECR_REGION}.amazonaws.com
HELM_ECR_ADDRESS=${HELM_REGISTRY}/${REPO_NAME}:${IMAGE_TAG}

Сохраняем чарт:

helm chart save ${CHART_DIR} ${HELM_ECR_ADDRESS}

Логинимся Хелмом в реестр (aws-cli version 2):

aws ecr get-login-password --region ${ECR_REGION} | helm registry login --username AWS --password-stdin ${HELM_REGISTRY}

Пушим чарт в ECR:

helm chart push ${HELM_ECR_ADDRESS}

Спулить чарт из ECR:

helm chart pull ${HELM_ECR_ADDRESS}

Распаковать чарт в текущую папку:

helm chart export ${HELM_ECR_ADDRESS}

Распаковать чарт в нужную папку (останется изначально имеющаяся вложенность):

helm chart export ${HELM_ECR_ADDRESS} --destination some-dir

#ECR #Helm

Amazon Timestream:

https://aws.amazon.com/blogs/aws/store-and-access-time-series-data-at-any-scale-with-amazon-timestream-now-generally-available/

Timestream — serverless база данных для IoT и других систем с Time Series данными.

#Timestream

Рекомендации по удалённой сдаче AWS сертификации от производителя:

https://aws.amazon.com/blogs/training-and-certification/5-tips-for-a-successful-online-proctored-aws-certification-exam/

Если коротко:

• Во время сдачи есть/перекусить будет нельзя
• Прерывать сдачу (выходить или впускать кого-то в комнату) нельзя
• Общение с экзаменатором лишь на английском или японском
• Стоит протестировать соединение с интернетом
• Бронировать дату-время сдачи заранее
• Не пропустить письмо с подтверждением даты забронированного экзамена
• Присоединиться можно за полчаса до начала экзамена, чтобы решить все вопросы заранее

#AWS_Certification

Terraform → CDKtf конвертер:

https://github.com/iann0036/hcl2cdktf

#CDK #Terraform

S3 Object Ownership — решение проблемы длиной в 15 лет:

https://docs.aws.amazon.com/AmazonS3/latest/dev/enable-object-ownership.html

В чём проблема вообще?

При копировании файла из аккаунта А в бакет аккаунта В (в котором есть права для работы с ним из аккаунта А) — владельцем файла (объекта) является/остаётся аккаунт А. То есть админ аккаунта В видит, что у него в бакете есть файл, но ни скачать, ни получить какие-то данные он нём не может.

»»» Вариант с переключением в роль аккаунта В исправляет проблему, однако это уже другой сценарий, решающий проблему с помощью IAM.

Как было раньше? (с момента создания S3 в 2004-м году)

Для решения этой проблемы использовался ключик bucket-owner-full-control, который добавлял на копируемый объект "Permission": "FULL_CONTROL" для владельца аккаунта бакета.

Скопируем файл из аккаунта А в бакет аккаунта В:

aws --profile=account-A s3 cp file.txt s3://my-bucket-account-B/

Смотрим права сохранённого объекта:

aws --profile=account-A s3api get-object-acl --bucket my-bucket-account-B --key file.txt
{
"Owner": {
"DisplayName": "account-A",
"ID": "c0123f42b8a1bed065b8a1b2fdbf76c1b6acda99e0778822e3cece21a8c71058"
},
"Grants": [
{
"Grantee": {
"Type": "CanonicalUser",
"DisplayName": "account-A",
"ID": "c0123f42b8a1bed065b8a1b2fdbf76c1b6acda99e0778822e3cece21a8c71058"
},
"Permission": "FULL_CONTROL"
}
]
}

Файл лежит в бакете аккаунта В, но полный владелец (Owner) лишь у аккаунта А. Владелец В ничего не сможет сделать с файлом (но будет платить за него).

Теперь скопируем файл с ключиком bucket-owner-full-control:

aws --profile=account-A s3 cp file.txt s3://my-bucket-account-B/ --acl bucket-owner-full-control

Теперь права изменились:

{
"Owner": {
"DisplayName": "account-A",
"ID": "c0123f42b8a1bed065b8a1b2fdbf76c1b6acda99e0778822e3cece21a8c71058"
},
"Grants": [
{
"Grantee": {
"Type": "CanonicalUser",
"DisplayName": "account-A",
"ID": "c0123f42b8a1bed065b8a1b2fdbf76c1b6acda99e0778822e3cece21a8c71058"
},
"Permission": "FULL_CONTROL"
},
{
"Grantee": {
"Type": "CanonicalUser",
"DisplayName": "account-B",
"ID": "8933ecf5e61d2b67a525edee13f7667ab45d2be85b1fdb82a9338a60609ee5f9"
},
"Permission": "FULL_CONTROL"
}
]
}

В список Grantee имеющий полный доступ FULL_CONTROL добавился и аккаунт В.

Но владелец Owner по-прежнему аккаунт А!

Чем это плохо? Какая разница — владелец или полные права?

Для аккаунта В без разницы. Но как только вы попытаетесь скачать этот файл из аккаунта С (который также имеет все права на работу с бакетом В) — получите отлуп! И понятно почему — ведь ему владелец файла из аккаунта А не разрешал доступ к объекту, его нет в списке Grantee.

На этом неочевидном, сложном и крайне неприятном косяке сильно валились и валятся многие мульти-аккаунтные проекты. Тонкие вещи с добавлением прав аккаунту С с помощью флажка --grant-full-control это весьма специфичный и редко возможный вариант.

И как теперь?

Теперь, если включить для бакета S3 Object Ownership = bucket owner preferred, то при копировании файла без флажка bucket-owner-full-control ничего не изменится. А вот с ним - произойдёт чудо:

{
"Owner": {
"DisplayName": "account-B",
"ID": "8933ecf5e61d2b67a525edee13f7667ab45d2be85b1fdb82a9338a60609ee5f9"
},
"Grants": [
{
"Grantee": {
"Type": "CanonicalUser",


    "DisplayName": "account-B",
    "ID": "8933ecf5e61d2b67a525edee13f7667ab45d2be85b1fdb82a9338a60609ee5f9"
   },
   "Permission": "FULL_CONTROL"
  }
 ]
}

Полноправным (и единственным) владельцем (Owner) файла из аккаунта А стал акаунт В! Больше никаких проблем, характерных ранее для #shared_bucket!

Итого

Потому отныне можно рекомендовать всегда включать S3 Object Ownership = bucket owner preferred — логику работы оно не меняет (точней — исправляет), при этом бесплатно и проблем будет меньше.

#S3

🔸iam-policies-cli

A CLI tool for building simple to complex IAM policies based on CloudFormation templates.

https://github.com/mhlabs/iam-policies-cli

#aws

Бесплатные имена доменов для опытов с Route53, и load balancers можно зарегать в https://my.freenom.com/
Не благодарите, Ваш капитан )

​​Tagger — инструмент для работы с тэгами:

https://github.com/IT-EXPERTS-AT/tagger

#tags

​​У Slack серьёзные проблемы со вчерашнего дня:

https://www.dailymail.co.uk/sciencetech/article-8807179/Slack-users-unable-send-receive-messages-chat-service.html

Страница статуса:

https://status.slack.com/

Если не работает десктоп-клиент — не забывайте про браузерный вариант, он может работать:

https://app.slack.com/ssb/add

#Slack

Советы по работе с AWS Organizations от производителя:

https://docs.aws.amazon.com/organizations/latest/userguide/orgs_best-practices.html

Рекомендации для мастер-аккаунта и для подаккаунтов.
Основные:
▪️ не используйте публичные почтовые сервисы (бо̀льшая вероятность взлома)
▪️ обязательно включайте MFA
▪️ блокируйте root-юзеров в подаккаунтах с помощью SCP
▪️ периодически проверяйте процесс восстановления доступа к аккаунту (чтобы проверить, что всё нужное для этого есть у нужных людей)
▪️ создайте/обновляйте документацию по процессу восстановления доступа

#best_practices #Organizations

CloudFormation умер, да здравствует CDK!

https://aws.amazon.com/blogs/developer/migrating-cloudformation-templates-to-the-aws-cloud-development-kit/

Как было раньше?

Чтобы подцепить в CDK какой-то имеющийся свой CloudFormation шаблон, который невозможно, сложно или просто лень было переписывать на CDK, то можно было использовать CfnInclude:

https://docs.aws.amazon.com/cdk/api/latest/docs/@aws-cdk_core.CfnInclude.html

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

Как теперь?

Начиная с версии CDK 1.63 (т.е. с сентября 2020-го) можно существующий шаблон подцепить к CDK и рулить им уже полностью через него!

То есть, к примеру, имеем работающий (задеплоенный) CloudFormation стэк, который создаёт VPC. Идём в консольку, копируем его шаблон в my-vpc-template.json, и прописываем это имя templateFile (ниже пример для TypeScript):

const cfnInclude = new cfn_inc.CfnInclude(this, 'Template', {templateFile: 'my-vpc-template.json' });

И теперь полностью рулим стэком из CDK и можно работать с подцеплёнными ресурсами отдельно. То есть, например, нужно поменять какую-то подсетку в VPC. Цепляем её по имени ресурса, используемого в шаблоне (в моём случае это имя subnetVpc4DmzA):

const subnetA = cfnInclude.getResource('subnetVpc4DmzA') as ec2.CfnSubnet;

И меняем её параметры:

subnetA.mapPublicIpOnLaunch = false;

Делаем cdk deploy и CloudFormation стэк изменён! В него добавились CDKMetadata параметры и дальше уже нужен только CDK, никакого CloudFormation!

#CDK

классная библиотека для тех у кого много лямбд https://awslabs.github.io/aws-lambda-powertools-python/
есть java версия https://github.com/awslabs/aws-lambda-powertools-java

Полезное видео архитектуры на Лямбдах и результата почти двукратной оптимизации расходов на неё:

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

#Lambda

Как использовать AWS CDK Pipelines или деплоим CDK в мультирегионы/мультиаккаунты:

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

#CDK #video

Ваше воскресное чтиво - первая ступень в нашем глубоком погружении в Amazon DynamoDB.

Что есть DynamoDB, в чем ее отличие от других NoSQL СУБД, как создать таблицу и что-то в нее записать - в этом обзорном материале.

Для смелых духом и опытных амазонщиков этот пост покажется излишне легким, но вам остается лишь чуть-чуть подождать.

Дальше будет гораздо сложнее и больше.