en
Feedback
AWS Notes

AWS Notes

Open in Telegram

AWS Notes — Amazon Web Services Educational and Information Channel Chat: https://t.me/aws_notes_chat Contacts: @apple_rom, https://www.linkedin.com/in/roman-siewko/ No ads.

Show more
5 801
Subscribers
+124 hours
-27 days
+330 days
Posts Archive
Как было раньше? (с момента создания 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

S3 Object Ownership — решение проблемы длиной в 15 лет: https://docs.aws.amazon.com/AmazonS3/latest/dev/enable-object-ownersh
S3 Object Ownership — решение проблемы длиной в 15 лет: https://docs.aws.amazon.com/AmazonS3/latest/dev/enable-object-ownership.html В чём проблема вообще? При копировании файла из аккаунта А в бакет аккаунта В (в котором есть права для работы с ним из аккаунта А) — владельцем файла (объекта) является/остаётся аккаунт А. То есть админ аккаунта В видит, что у него в бакете есть файл, но ни скачать, ни получить какие-то данные он нём не может. »»» Вариант с переключением в роль аккаунта В исправляет проблему, однако это уже другой сценарий, решающий проблему с помощью IAM.

Terraform → CDKtf конвертер: https://github.com/iann0036/hcl2cdktf #CDK #Terraform
Terraform → CDKtf конвертер: https://github.com/iann0036/hcl2cdktf #CDK #Terraform

Рекомендации по удалённой сдаче AWS сертификации от производителя: https://aws.amazon.com/blogs/training-and-certification/5-tips-for-a-successful-online-proctored-aws-certification-exam/ Если коротко: • Во время сдачи есть/перекусить будет нельзя • Прерывать сдачу (выходить или впускать кого-то в комнату) нельзя • Общение с экзаменатором лишь на английском или японском • Стоит протестировать соединение с интернетом • Бронировать дату-время сдачи заранее • Не пропустить письмо с подтверждением даты забронированного экзамена • Присоединиться можно за полчаса до начала экзамена, чтобы решить все вопросы заранее #AWS_Certification

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

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

CDK day в прямом эфире: https://www.youtube.com/watch?v=qJutZqXMdgM
CDK day в прямом эфире: https://www.youtube.com/watch?v=qJutZqXMdgM

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

​​Теперь можно задать диапазон IP-адресов для EKS кластера: https://docs.aws.amazon.com/eks/latest/userguide/create-cluster.html #EKS

​​SCP и мастер (root) AWS-аккаунт Стоит помнить, что "всемогущие" политики SCP, которые так удобно можно применять ко всей организации — не применяются к юзерам и ролям мастер аккаунта (root-аккаунта): https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html Потому, если, например, думаете, включать или не включать CloudTrail в регионах, что планируете запретить через SCP — однозначно стоит включать. Уже лишь как раз по причине того, что в мастере SCP не сработает, а две защиты лучше, чем одна (в подаккаунтах). #SCP #Organizations

🔸Security Architecture Review Of A Cloud Native Environment Walkthrough of a cloud security assessment performed on an organ
🔸Security Architecture Review Of A Cloud Native Environment Walkthrough of a cloud security assessment performed on an organisation which had recently moved their infrastructure from an on-prem to a cloud native solution (AWS). https://notsosecure.com/security-architecture-review-of-a-cloud-native-environment/ #aws

​​Продолжение отличной серии по стратегии тэгирования AWS: https://www.cloudforecast.io/blog/maintain-aws-tags-when-you-fall-behind-part-3/ #tags #best_practices

Солидному человеку — солидная ссылка: AWS Ambassadors - Epam

Продолжаем тему PHP + Serverless, новый пост опубликован: https://aws.amazon.com/ru/blogs/rus/introducing-the-serverless-lamp-stack-part-2-relational-databases/

S5Cmd - S3 на стеройдах Сегодня расскажу про проект S5Cmd - отличный open source инструмент (изначально написанный ребятами из Peak Games) для ускорения и кастомизации процессов между S3 и локальной файловой системой. Три ключевых момента: - скорость - S5Cmd написан на Go, максимально использует возможности параллельной обработки и transfer acceleration; собственно perfomance тесты есть на странице проекта (и ниже напишу свои результаты) - привычная работа по маске (wildcard support); без всех этих exclude и include, которыми оперирует aws-cli - работа в пакетном режиме на основе текстового командного файла либо pipe конвеера, что открывает произвольные варианты интеграции с unix shell Чтобы не быть голословным, приведу результаты локального теста. Исходные установки: есть бакет, в котором хранятся разбитые по датам данные нескольких проектов. То есть s3://bucket-name/YYYY/MM/DD/prj1..., prj2..., и т.д. Каждый проект состоит из нескольких файлов. Копирую себе данные за один день по одному проекту: 1. В aws-cli это выглядит так:
 s3 cp s3://bucket-name/2020/09/27/ ./ --exclude "*" --include "prj1*" --recursive
- минута и 43 секунды. Замечу, что несмотря на плоскую структуру внутри дня, без recursive не обойтись 2. В s5cmd это выглядит лаконичнее:
 cp 's3://bucket-name/2020/09/27/prj1*' ./
- 37 секунд - в три раза быстрее Дополнительно попробовал batch-режим, собрав предварительно с помощью ls и awk файл, где каждая строка - это копирование одного объекта. Здесь получилось 54 секунды за счёт какой-то задержки на старте (видимо файл парсится во внутреннюю структуру для исключения конфликтов, например сочетания команд копирования и удаления). Однако это всё равно довольно хорошо, если использовать командный файл по назначению - как сценарий разнородных действий. Рекомендую присмотреться, если у вас есть соответствующие задачи (например, работа с данными s3 на серверной стороне за рамками AWS-инфраструктуры). Авторы из Amazon инструмент также хвалят.

​​Наконец-то вышло обновление AWS Extend Switch Roles для переключения между аккаунтами с исправлением для работы в преобразившейся недавно AWS консоли. Обратите внимание, что теперь список аккаунтов для переключения располагается не как раньше в менюшке самой AWS консоли, а при нажатии на сам ключик расширения (см. картинку).

С сегодняшнего для при покупке Savings Plan можно указывать дату в будущем, что удобно чтобы не держать эту дату в голове, когда у вас заканчивается предыдущий Savings Plan - https://aws.amazon.com/about-aws/whats-new/2020/09/queuing-purchases-of-savings-plans/

​​Darko Meszaros: "Infrastructure IS Code on AWS": https://www.youtube.com/watch?v=b7h2G6YidKs&t=567 Видео с DevSecOps конференции, прошедшей 24 сентября 2020-го года. #video

🔸Awesome AWS S3 - Security, Tools and Intel Collection of tools, techniques and useful links concerning security and exposed AWS S3 Buckets https://github.com/mxm0z/awesome-sec-s3#awesome-aws-s3---security-tools-and-intel #aws

​​T3 инстансы для Amazon Elasticsearch Service: https://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/aes-supported-instance-types.html В дополнение к дешёвым t2.micro/small/medium.elasticsearch доступны t3.small.elasticsearch и t3.medium.elasticsearch, которые стоят столько же, но быстрей и позволяют использовать до 100ГБ и 200ГБ места соответственно (в отличие от 35ГБ для всех T2). #ES