Пример реализации #bucket_policy для нескольких #OriginAccessIdentity в одном #s3 бакете.

policyBucketFiles:
Type: AWS::S3::BucketPolicy
Properties:
Bucket: !Ref bucketFiles
PolicyDocument:
Statement:
- Sid: Access for Cloudfront-files
Effect: Allow
Principal:
CanonicalUser: !GetAtt [originAccessIdentityBucketFiles, 'S3CanonicalUserId']
Action:
- 's3:GetObject'
Resource:
- !Join ['',['arn:aws:s3:::', !Ref bucketFiles, '/files/*']]
- !Join ['',['arn:aws:s3:::', !Ref bucketFiles, '/files_public/*']]
- Sid: Access for SwitchOver Cloudfront-files
Effect: Allow
Principal:
CanonicalUser: !Ref CanonicalUserFilesSwitchOver
Action:
- 's3:GetObject'
Resource:
- !Join ['',['arn:aws:s3:::', !Ref bucketFiles, '/files/*']]
- !Join ['',['arn:aws:s3:::', !Ref bucketFiles, '/files_public/*']]
- Sid: Access for replication account
Effect: Allow
Principal:
AWS: !Join ['',['arn:aws:iam::', !Ref AccountReplication, ':root']]
Action:
- 's3:*'
Resource:
- !Join ['',['arn:aws:s3:::', !Ref bucketFiles ]]
- !Join ['',['arn:aws:s3:::', !Ref bucketFiles, '/*']]

#CloudFormation #templates #examples

Бывает, что, казалось бы, банальное копирование файлов в #s3 бакет:

aws s3 cp ./ s3://some-bucket/files --recursive

Когда это происходит из другого аккаунта, когда бакет расположен в другом регионе или с локального компьютера (между бакетами и т.п. не самые ординарные случаи), даёт странный эффект (#issue) — всё благополучно копируется, но после сам владелец бакета с админскими правами не может получить скопированное, получая #error:

An error occurred (AccessDenied) when calling the GetObject operation: Access Denied

И даже через консоль получаем ошибку доступа к файлам:

This XML file does not appear to have any style information associated with it. The document tree is shown below.
<Error> <Code>AccessDenied</Code> <Message>Access Denied</Message>...

Причина - у Owner-а бакета нет никаких прав на записанное (картинка ниже).
Чтобы исправить — повторяем копирование на источнике с добавлением нужных #ACL #permissions с помощью ключика --acl bucket-owner-full-control, который сразу обеспечит каждому объекту нужные права.

aws s3 cp ./ s3://some-bucket/files --recursive --acl bucket-owner-full-control

Картинка к посту выше.

Бывает нужно узнать, когда была добавлена фича в #CloudFormation - для этого есть #history (или просто можно подписаться на обновления).

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/ReleaseHistory.html

Я на какое-то время пропал, но вот вернулся)
На прошлой неделе отгремел AWS re:Invent, так что новости про Амазон сыпались со всех сторон. Я постарался собрать всё интересное (субъективно) в виде дайджеста.

Computing:
- AWS Outposts
- Arm-based Amazon EC2 A1 Instances
- Firecracker - легковесная виртуализация на Rust с открытым кодом
- Предиктивный скейлинг EC2 с ML под капотом
- Гибернейт для EC2

Данные:
- Amazon Aurora Global Database - одна реляционка на несколько(!) регионов
- DynamoDB Support for Transactions
- AWS DataSync - автоматизация передачи данных между хранилищами внутри AWS (S3, EFS)
- AWS Transfer for SFTP - SFTP для S3
- Amazon EFS now Supports Access Across Accounts and VPCs
- Amazon Timestream - новая time-series DB от AWS
- S3 Object Lock - запрет на удаление данных в S3 на заданный период
- S3 Intelligent-Tiering - новый сторейдж-класс для S3
- AWS Lake Formation - сервис для создания безопасных data lakes
- Amazon Quantum Ledger Database (QLDB) - треккинг датафлоу между приложениями
- Amazon Managed Blockchain - ну вы поняли 😉

Приложения:
- AWS App Mesh - Service Mesh от AWS
- Application Load Balancer can now Invoke Lambda Functions to Serve HTTP(S) Requests
- AWS License Manager - для упрощения управлением сторонних лицензий
- AWS Lambda Supports Ruby
- Custom Runtimes для AWS Lambda
- Managed Streaming for Kafka - Kafka без Кафки
- Amazon Forecast - прогнозы от AWS по любым(?) вашим данным

#aws
Продолжение >>

Mindmap по #AWS Certified Solution Architect (Associate) - #design.

#Linter для #CloudFormation

https://github.com/awslabs/cfn-python-lint

Тоже #Linter для #CloudFormation, но с прицелом на #security.

https://github.com/stelligent/cfn_nag

Для решения такой проблемы можно использовать специально обученную #Lambda, которая триггерится перед удалением инстанс в #ECS cluster, когда обновляется #AMI инстанса:

https://aws.amazon.com/blogs/compute/how-to-automate-container-instance-draining-in-amazon-ecs/

При планировании новых проектов стоит учитывать новые #AWS #region, которые есть сейчас и которые откроются в ближайшем будущем. Например, для питерских проектов может быть важным, что вскоре появится #AWS в Швеции, а для болгарских - что в Италии.

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

Не стоит забывать, что #aws_cli поддерживает linux pipes, а потому, например, для для #s3 многие операции с файлами в бакете можно делать без предварительного их сохранения (используя stdin/stdout):

https://loige.co/aws-command-line-s3-content-from-stdin-or-to-stdout/

Это боль, когда у тебя больше пяти #AWS_accont (т.к. на текущий момент максимум 5 аккаунтов в history при переключении). Пока амазонозаводчики не порешали это у себя - можно использовать плагин под #Chrome для переключения ролей.

https://chrome.google.com/webstore/detail/aws-extend-switch-roles/jpmkfafbacpgapdghgdpembnojdlgkdl?hl=en

Такой же для #Firefox:

https://addons.mozilla.org/en-US/firefox/addon/aws-extend-switch-roles3/

Автоматизация преобразования #NVMe типов #EBS #volume вида /dev/nvme0n1 в обычные /dev/xvdf:

https://github.com/oogali/ebs-automatic-nvme-mapping

Проблема актуальна для новых Nitro-based виртуалок (C5/M5/T3/etc), где в качестве EBS используются NVMe block devices.

В случаях, когда нужно иметь #StaticIP для #ALB обычно используется #NLB перед ним (который имеет статический IP для каждой зоны) и #lambda, которая отрабатывает регистрации текущих IP у ALB в качестве целей для NLB.

https://aws.amazon.com/blogs/networking-and-content-delivery/using-static-ip-addresses-for-application-load-balancers/

С появлением AWS Global Accelerator можно упростить реализацию ALB Static IP, поставив перед ALB #Global_Accelerator (вместо NLB + Lambda). Решение "с перебором" (и более дороже), но может оказаться быстрым "на попробовать" и где-то более удобным в поддержке.

В случаях, когда узким местом становится скорость работы #S3 - не забываем, что дефолтные настройки можно изменить:

https://docs.aws.amazon.com/cli/latest/topic/s3-config.html

Например, для бакетов, имеющих #S3_Accelerate (в то время как по дефолту use_accelerate_endpoint=false) или просто для увеличения скорости загрузки (или наоборот - для уменьшения нагрузки на виртуалку).

Чтобы использовать безопасные #iam_policy для #SSM #Session_Manager, придётся использовать длинную простыню правил:

https://github.com/applerom/cloudformation-examples/blob/master/ssm/ssm-manager-policy.yml

#security

Очень полезный и детальный список #best_practices и #worst_practices или паттернов и анти-паттернов для современного #CI_CD.

https://www.gronau-it-cloud-computing.de/pattern-and-anti-pattern-cicd/

#design

Если вы умеете работать в #AWS_Console, но не умеете или лишь осваиваете #CloudFormation, то для вас #AWSConsoleRecorder может быть бесценной находкой.

https://github.com/iann0036/AWSConsoleRecorder

Вы делаете всё нужное в браузере с помощью плагина, а на выходе получаете готовый сценарий в виде команд, CloudFormation шаблона или других вещей, в частности #Terraform.

Добавление в #ECR возможности тэгировать репозитории может поломать ваши сценарии, т.к. в #IAM добавилось новое #policy 'ecr:ListTagsForResource':

... error getting ECR repository tags: AccessDeniedException: User: ... is not authorized to perform: ecr:ListTagsForResource ...