#note Чтобы задать #json-запрос для #aws_cli со своими параметрами:

aws --region=eu-west-2 deploy create-deployment --cli-input-json "file://create-deployment.json"

Чтобы получить структуру параметров - используем ключик --generate-cli-skeleton.

#note Чтобы обработать что-то в #s3 бакете без сохранения на диск:

aws s3 cp s3://mybucket/file ‐ | bzip2 -best | aws s3 cp ‐ s3://mybucket/file.bz2

В общем случае стоит избегать использования #IAM #ManagedPolicy, т.к. граждане в Амазоне не утруждают себя использованием ограниченных #permissions в них и запросто ставят "жирные" #policy.

Например, в AmazonEC2RoleforSSM, которое рекомендуется для работы с #SSM #Session_Manager, имеется правило на работу #s3 с любыми ресурсами:

{
  "Effect": "Allow",
  "Action": [
    "s3:GetBucketLocation",
    "s3:PutObject",
    "s3:GetObject",
    "s3:GetEncryptionConfiguration",
    "s3:AbortMultipartUpload",
    "s3:ListMultipartUploadParts",
    "s3:ListBucket",
    "s3:ListBucketMultipartUploads"
  ],
  "Resource": "*"
}

#ужас #сколькоможнотерпеть

#info #inter_region #latency #performance #AWS #Azure #GCP
https://marketo-web.thousandeyes.com/rs/thousandeyes/images/ThousandEyes-2018-Public-Cloud-Performance-Benchmark-Report.pdf

При изменении #EBS с обычного на #iops, нужно учитывать, что эта операция может занять некоторое время (до 40 минут для 200ГБ), а вернуть обратно (на обычный) можно будет лишь через шесть часов, иначе #error:

Wait at least 6 hours between modifications per EBS volume.

Кроме того, операция возвращения будет ещё более длительной (раза в два дольше - до двух часов на 200ГБ).

Пример реализации #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). Решение "с перебором" (и более дороже), но может оказаться быстрым "на попробовать" и где-то более удобным в поддержке.