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

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

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

#CloudFormation #templates #useit

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

#vpc #vpc_endpoints

Для отладки проблем на 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

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

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

#vpc #logs #vpc_flow_logs #ES

Чтобы в #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".

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

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

Обсуждение этой проблемы на Reddit.

Slack Bot на Лямбде.

#slack #bot #lambda

Slack Bot

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

#info #comparison

Когда в #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 можно использовать и для отдельных параметров и для блоков.

#recommendation Для важных (неочевидных, а для кого-то - просто всех) выходных переменных #CloudFormation #templates стоит добавлять описание:

Outputs:
## Common parameters
dnsKong:
Value: !Ref dnsKong
Description: Kong External ELB DNS
Export:
Name: dnsKong

Общий способ добавления в шаблон #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

Если добавлять #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 типа 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

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 для #s3.
Если коротко, то при использовании приватных подсетей, когда исходящий трафик идёт через NAT GW - через него же идут запросы к сервисам амазона, в частности, #s3, что тарифицируется (т.к. "выходит в интернет" как обычный https запрос). Чтобы такого не происходило, стоит поднимать #vpc_endpoint и тогда трафик будет внутренним (не будет "выходить в интернет").

#cost_saving

На данный момент через #CloudFormation нельзя создавать #ES в #VPC, нужно предварительно создать #IAM #role, для этого выполнить #aws_cli:

aws iam create-service-linked-role --aws-service-name es.amazonaws.com