AWS Notes

ReadOnly #bucket_policy для доступа к файлам/бакету из других аккаунтов ("расширенная версия" - не забываем добавлять ListBucket для возможности копировать с профиксом/рекурсией, а также GetBucketLocation для определения региона бакета): { "Version": "2012-10-17", "Statement": [ { "Sid": "Access to files/* for accounts: dev1, dev2", "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::111111111111:root", "arn:aws:iam::222222222222:root" ] }, "Action": [ "s3:GetObject", "s3:ListBucket", "s3:GetBucketLocation" ], "Resource": [ "arn:aws:s3:::shared-bucket/files/*", "arn:aws:s3:::shared-bucket" ] } ] } #s3 #cross_account #access

Для #vpc_endpoint типа Gateway не требуется PrivateDnsEnabled, его указывать не нужно (иначе будет #error). vpcEndpointDynamoDb: Type: AWS::EC2::VPCEndpoint Properties: VpcId: !ImportValue vpc4 ServiceName: !Sub 'com.amazonaws.${AWS::Region}.dynamodb' RouteTableIds: - !ImportValue rtbVpc4Dmz - !ImportValue rtbVpc4Private Также #vpc_endpoint типа Gateway требует RouteTableIds и работает лишь с ним (указание SubnetIds и/или SecurityGroupIds даст #error). В то время как для #vpc_endpoint типа Interface, наоборот, требуется SubnetIds и/или SecurityGroupIds: vpcEndpointEc2Messages: Type: AWS::EC2::VPCEndpoint Properties: VpcId: !ImportValue vpc4 ServiceName: !Sub 'com.amazonaws.${AWS::Region}.ec2messages' PrivateDnsEnabled: true VpcEndpointType: Interface SubnetIds: - !ImportValue subnetVpc4PrivateAppA - !ImportValue subnetVpc4PrivateAppB SecurityGroupIds: - !ImportValue sgVpc4Dummy Указывать несколько SubnetIds из одной подзоны нельзя (иначе будет #error), потому можно указать лишь Security Group (например, пустую - заглушку). Хотя можно и то, и другое. #CloudFormation #templates

Если добавлять #vpc_endpoints на что-то (с политиками), например, лишь для загрузки пакетов для обновления #AMI (), то вид следующий: vpcEndpointS3: Type: AWS::EC2::VPCEndpoint Properties: VpcId: !ImportValue vpc4 ServiceName: !Sub 'com.amazonaws.${AWS::Region}.s3' PolicyDocument: Version: 2012-10-17 Statement: - Effect: Allow Principal: '*' Action: - 's3:GetObject' Resource: - 'arn:aws:s3:::packages.*.amazonaws.com/*' - 'arn:aws:s3:::repo.*.amazonaws.com/*' RouteTableIds: - !ImportValue rtbVpc4Dmz - !ImportValue rtbVpc4Private #CloudFormation #templates

Общий способ добавления в шаблон #vpc_endpoint (без политик): vpcEndpointS3: Type: AWS::EC2::VPCEndpoint Properties: VpcId: !ImportValue vpc4 ServiceName: !Sub 'com.amazonaws.${AWS::Region}.s3' RouteTableIds: - !ImportValue rtbVpc4Dmz - !ImportValue rtbVpc4Private #CloudFormation #templates

#recommendation Для важных (неочевидных, а для кого-то - просто всех) выходных переменных #CloudFormation #templates стоит добавлять описание: Outputs: ## Common parameters dnsKong: Value: !Ref dnsKong Description: Kong External ELB DNS Export: Name: dnsKong

Когда в #CloudFormation #templates нужно иметь переменное количество параметров, то можно использовать Fn::Transform: Targets: - Id: !Ref SwarmMaster Port: 888 - Id: !Ref SwarmWorker1 Port: 888 Fn::Transform: Name: AWS::Include Parameters: Location: !If [ IsProd, !Ref ProdS3linkToYaml, !Ref DevS3linkToYaml ] #transform можно использовать и для отдельных параметров и для блоков.

Удобный каталог типов инстансов #ec2 с параметрами https://ec2instances.info/ #info #comparison

Slack Bot

Slack Bot на Лямбде. #slack #bot #lambda

#issue При обновлении #AMI для #ECS Autoscaling group через шаблон - есть проблема для действующих #prod систем. #CloudFormation не учитывает скорости деплоя убиваемых докеров (#task_definition) - новые инстансы (с обновлённым AMI) поднимаются очень быстро и как только они становятся доступными, предыдущие (ещё работающие с набитыми докерами) тупо терминируются. В результате появляется #downtime - пока на поднявшиеся новые инстансы задеплоятся убитые вместе с инстансами докеры. Обсуждение этой проблемы на Reddit.

#recommendation - периодически обновлять #AMI (в т.ч. докерных образов, как минимум сервисного) - раз в квартал (так обычно выходят обновления Amazon Linux). Для срочных патчей (очередная критическая уязвимость чего бы то ни было) - отработать процедуру запуска критических обновлений.

Чтобы в #ECS скопировать #task_definition через JSON и потом вставить это при создании другой #task_definition (т.е. сделать условный экспорт-импорт в консоли) - нужно удалить в полученном (скопированном) JSON следующие переменные: compatibilities requiresAttributes taskDefinitionArn revision status Иначе #error: Should only contain "family", "containerDefinitions", "volumes", "taskRoleArn", "networkMode", "placementConstraints", "requiresCompatibilities", "cpu", "memory", "executionRoleArn".

Отправляем VPC flow logs в ES. #vpc #logs #vpc_flow_logs #ES

CI/CD на Лямбде. #CI_CD #lambda

Для отладки проблем на AWS - мои #best_practices: - включить логирование с помощью awslogs - включить vpc flow logs (их можно/нужно складывать в ES для просмотра) - не забывать / проверить права Network ACL - не забывать про исходящий трафик, который может быть почему-то закрыт - смотреть в awslogs-логах на инстансе с проблемами - каких конкретно прав не хватает сервисам типа SSM - для S3 не забывать про зависимость от регионов - для cross-account работы S3 не забывать, что у аккаунта из которого идёт доступ даже админу нужно дать права на s3://bucket-in-other-acc (т.к. по умолчанию лишь на свои #check_it) - не забывать про Route Tables, особенно при VPC-пиринге в разные подсети - не забывать про текущие ограничения некоторых сервисов, что не всё может делаться через CloudFormation и что новообъявленные фичи не сразу имплементируются (в CloudFormation + зависит от региона) - не забывать про отличие IAM и S3 policy как resource-based - не забывать, что для public-ресурсов (например, ES) нельзя использовать IAM role (только user + credentials и уже у юзера может быть роль) - для IAM role нужно использовать ресурсы в VPC #trace #logs #todo #use_it

VPC endpoints есть не для всех сервисов, поэтому не все могут работать чисто в VPC. #vpc #vpc_endpoints

Большой сборник примеров шаблонов от самого амазона. Очень стоит просмотреть при вопросах реализации каких-то фрагментов - все забывают, что есть первоисточник. #CloudFormation #templates #useit

Design VPC #best_practices или как разбить на подсетки VPC, какую схему выбрать для dev/stg/prod, как грамотно организовать VPC для разных целей. Рекомендуемые ссылки почитать: - Официальная дока - Пошаговые инструкции с примерами для консоли и AWS CLI (не совсем про дизайн, но может быть полезно) - Базовые понятия и общие рекомендации (13 пунктов) - Старенькая, но тоже можно глянуть - Тоже старенькая, но весьма подробная (25 пунктов) - Полезное обсуждение на Reddit по вопросу разбивке на CIDR-blocks - Не про VPC, но полезные общие практики AWS Cloud Design Patterns #vpc #design #vpc_design #cidr

Статья по техническим подробностям внутренней работы Лямбд - первоисточник (pdf). #lambda

Stacker is a tool and library used to create & update multiple CloudFormation stacks. Весьма интересная штука для работы с большим количеством стэков. Написана поверх #troposhere и может быть отличным решением для CI/CD каких-то проектов, не использующих своих централизованных решений. #stacker #CloudFormation #multiple_stacks