AWS Notes

Для решения такой проблемы можно использовать специально обученную #Lambda, которая триггерится перед удалением инстанс в #ECS cluster, когда обновляется #AMI инстанса: https://aws.amazon.com/blogs/compute/how-to-automate-container-instance-draining-in-amazon-ecs/

Тоже #Linter для #CloudFormation, но с прицелом на #security. https://github.com/stelligent/cfn_nag

#Linter для #CloudFormation https://github.com/awslabs/cfn-python-lint

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

Я на какое-то время пропал, но вот вернулся) На прошлой неделе отгремел 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 Продолжение >>

Бывает нужно узнать, когда была добавлена фича в #CloudFormation - для этого есть #history (или просто можно подписаться на обновления). https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/ReleaseHistory.html

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

Бывает, что, казалось бы, банальное копирование файлов в #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

Пример реализации #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

При изменении #EBS с обычного на #iops, нужно учитывать, что эта операция может занять некоторое время (до 40 минут для 200ГБ), а вернуть обратно (на обычный) можно будет лишь через шесть часов, иначе #error: Wait at least 6 hours between modifications per EBS volume. Кроме того, операция возвращения будет ещё более длительной (раза в два дольше - до двух часов на 200ГБ).

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

В общем случае стоит избегать использования #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": "*"
}

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

#note Чтобы обработать что-то в #s3 бакете без сохранения на диск: aws s3 cp s3://mybucket/file ‐ | bzip2 -best | aws s3 cp ‐ s3://mybucket/file.bz2

#note Чтобы задать #json-запрос для #aws_cli со своими параметрами: aws --region=eu-west-2 deploy create-deployment --cli-input-json "file://create-deployment.json" Чтобы получить структуру параметров - используем ключик --generate-cli-skeleton.

#note После применения (изменения) #IAM_role на инстанс, права изменяются (обновляются) где-то через 30 секунд, а после добавления в #role новой #policy — где-то 2-3 минуты. При проблемах на амазоне максимальное время применения #IAM — 5-6 минут. Если прошло больше и всё равно не работает, то "проблема на вашей стороне".

#note При копировании #s3_cp или синхронизации #s3_sync пустые каталоги не создаются, т.к. #S3 работает с объектами (файлами) и не в курсе про каталоги (это лишь путь к объекту). Если нужно с пустыми - используем сторонние утилиты (например, S3cmd). При особо страстном желании, можно добавить энный плюсик в просьбу добавления такого функционала в официальную версию.

#recommendation Используемая практика именования переменных в #CloudFormation #templates у самого Амазана весьма ущербная - параметры начинаются с маленькой буквы p, а ресурсы начинаются с маленькой r:

pDMZSubnetA
rDMZSubnetA

Ущербность выявляется, когда выходишь за пределы одного стэка (особенно явно в #nested_stacks) — приходится переименовывать "бывшие" в одном стэке ресурсы в параметры в другом, что приводит при такой схеме к смене имени и сильно затрудняет сопровождение, а также плодит ошибки при переиспользование кода. За многие годы я пришёл к другой схеме именования - параметры и ресурсы (если их нужно передавать) имеют одинаковые имена, лишь только добавляется правило, что все ресурсы начинаютс с маленькой буквы, а параметры с большой. Кроме того, в имени ресурса почти всегда принципиально видеть тип, потому пример выше преобразуется в:

SubnetDmzA
subnetDmzA

Сначала кажется, что это как раз добавит путаницу, но очень скоро станет понятно, что обычно совпадающие имена (лишь начинающиеся с разной буквы) встречаются редко (обычно при создании бакетов или юзеров, где передаётся их имя), а возможность поиска по всему проекту(-ам) для последующего оптового переименования в случае надобности - крайне удобна.

#recommendation — для имён переменных в #CloudFormation #templates лучше не использовать имена переменных, начинающихся с имени стэка, т.к. в Physical ID добавляется имя стэка и возникает визуальная путаница (особенно при использовании #nested_stacks): jdot-St1IAM-16Z64H1UDUQF3-jdotInstanceProfile-WJ74BPFLW925

Когда нужно подобрать/оценить нужный тип #EC2 инстанса по требованиям типа "ходовые и только самые современные с 4 или 8 процессорами в Лондоне", то можно использовать regex ((c|m)5|t3).*(4|8) vCPUs на https://ec2instances.info/?filter=((c%7Cm)5%7Ct3).*(4%7C8).vCPUs&region=eu-west-2 — #info.

Чтобы узнать #instance_type из #metadata на самой #ec2 виртуалке:

wget -T 10 -O- http://169.254.169.254/latest/meta-data/instance-type 2>/dev/null

https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-instance-metadata.html