Псевдо-переменные амазона. Самые востребованные:

AWS::Region
AWS::AccountId
AWS::StackName

#CloudFormation

В официальной документации по #cross_account #s3_replication ошибки - пример указан с неполными правами в #bucket_policy для аккаунта источника:
...

"Action":["s3:ReplicateObject", "s3:ReplicateDelete"],

...
Полные указаны в примере предыдущего поста. Их нужно добавить и для роли источника, особенно с учётом, если нужно менять владельца.
Потому, для простоты, можно сразу давать полные s3:* - т.е. в приведённой ссылке на документацию по #cross_region #s3 #replication будет работать, если сделать так:
{
"Version": "2008-10-17",
"Statement": [
{
"Sid": "Full access for other account",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:root"
},
"Action": "s3:*" ,
"Resource": [
"arn:aws:s3:::replication-bucket",
"arn:aws:s3:::replication-bucket/*"
]
}
]
}
Аналогично сделать и в роли аккаунта источника:
- Effect: Allow
Action: 's3:*'
Resource: ## destination bucket
- 'arn:aws:s3:::replication-bucket'
- 'arn:aws:s3:::replication-bucket/*'

Официальный амазоновский документ по #design #best_practices.

Amazon #Macie в картинках.

Для доступа к #s3 можно использовать #iam, #bucket_policy и #bucket_acl - что же лучше использовать?
Если коротко, то всегда лучше выбирать #IAM.
Когда не получается или нужен как раз #resource_based подход - выбираем #bucket_policy (без него не обойтись для случаев #cross_account).
Использовать ACL не стоит ни разу - это и старое и неудобное.

При использовании #cross_account #s3_replication нужно учитывать, что destination #s3 бакет должен:
- существовать на момент отработки #CloudFormation #templates
- иметь #versioning (обязательно требуется для #replication)
- быть в другом #region

Пример кода - cross-account cross-region s3 bucket replication.

Также стоит обратить внимание, что роль на репликацию создаётся в аккаунте источника (которая указывается в ReplicationConfiguration бакета), а не в аккаунте репликации, как может показаться логичным. Мы даём доступ внешнему аккаунту (с бакетом источника) к себе в аккаунте репликации.

Использование в #CloudFormation #templates автоматического получения самого нового #AMI_ID через #ssm_parameters, что было описано в посте и как это рекомендовано в блоге амазона - весьма опасная практика для #prod систем.
Дело в том, что в таком случае вы не контролируете все параметры и когда обновляете прод можете получить нежелательное обновление #AMI. Теоретически процессы должны быть выстроены так, чтобы это не влияло и где-то даже было желательным сценарием (т.к. всегда самый последний - самый защищённый), однако может привести к нежелательным задержкам просто на само обновление. Но страшней, когда порушатся временные костыли.
Потому лучше использовать #mappings для этого - пусть ручное обновление, но контролируемое. А чтобы #по-быстрому получить #latest_ami_id - можно использовать скрипты.

#AmiLinux2:

for region in $(aws ec2 describe-regions --region us-east-1 --query 'Regions[].[RegionName]' --output text | sort); \
do printf "    ${region}:\n      AmiId: $(aws ssm get-parameters --names /aws/service/ami-amazon-linux-latest/amzn2-ami-hvm-x86_64-gp2 --query 'Parameters[0].[Value]' --output text --region $region)\n" ; done

#ECS_optimized:

for region in $(aws ec2 describe-regions --region us-east-1 --query 'Regions[].[RegionName]' --output text | sort); \
do printf "    ${region}:\n      AmiId: $(aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux/recommended/image_id --query 'Parameters[0].[Value]' --output text --region $region)\n" ; done

Примеры кода.

Из рубрик #error + #issue. Пренеприятная проблема была получена при попытке срочного разворота важного окружения. В процессе подъёма #autoscaling_group для #ecs_cluster с несколькими рабочими нодами и сервисами на них с важным моментом - docker image лежит не в ECR, а в #private_docker_hub, то на давно отрепетированном сценарии (правда лишь с одной нодой) вылезла страннейшая ошибка - вторая (!) нода не могла загрузить контейнер. Т.е. первая грузила и успешно работала, а вторая (такая же, этот же образ) - зависала на ошибке:

STOPPED (CannotPullContainerError: API error (404): pull ac)

Не получив образ по таймауту срабатывал откат. Ошибка нерегулярная, т.к. с энной попытки получалось задеплоить и успешно работать. Либо поставить одну ноду - и тогда ни разу не было такой ошибки.
Гуглинг показал, что у такой же ошибки есть братья по разуму, где, судя по всему, такая ситуация возникала именно в связке докерхаб + новый #ecs_agent. И в данном случае он как раз был обновлён. потому наверняка это одна из причин.
После детального изучения выяснилось, что в результате, видимо, каких-то неадекватных лагов с отдачей второго образа, амазоновская команда для подключения в #autoscalig_group:

/opt/aws/bin/cfn-signal -e $? --stack ${AWS::StackName} --resource autoscalingGroup --region ${AWS::Region}

вылетала в ошибку и расположенный за ней код не исполнялся! И если, как в моём случае, именно после этой команды задавалась переменная ECS_ENGINE_AUTH_DATA для авторизации на докере, то, получается, она не попадала в ecs.config и агент после никак не мог получить доступ к приватному репозиторию.
Изменения последовательности команд - решило проблему. При чём важно учесть, что есть и другие команды, которые обладают таким поведением, потому важный код помещаем в начало #UserData, а проблемные - в самый конец и с учётом важности:
/opt/aws/bin/cfn-signal -e $? --stack ${AWS::StackName} --resource autoscalingGroup --region ${AWS::Region}
stop ecs
start ecs

В дополнение к ec2 - ещё и отличный каталог типов инстансов для #RDS - https://ec2instances.info/rds/

#info #comparison

При конструировании DNS для #s3 бакет нужно быть максимально внимательным - неоднозначное толкование официальной документации, где говорится про «you can use either of these endpoints» в реальности может давать различные проблемы.
С одной стороны, используя вариант с

.s3.amazonaws.com

даёт в результате перенаправление, а значит изначально #error #307 и лишь потом нужный файл/страницу. Это может приводить к некорректной работе критическим к такому поведению вещей. Например, когда через s3 бакеты подтягиваются конфиг-файлы #nginx, то такое поведение даст ошибку «unexpected end of file, expecting ";" or "}" in /etc/nginx/conf.d/...», т.к. получив 307 он не будет делать ещё один запрос по новому location из ответа. Потому правильно использовать именно вариант типа:

!Join ['',[!Ref Bucket, '.s3-', !Ref 'AWS::Region' , '.amazonaws.com' ]]

Однако бывает и противоположная ситуация, например, с регионом N.Virginia. Для #CloudFront #Origin (в том числе для Logging бакета) DomainName вариант bucket.s3-us-east-1.amazonaws.com даёт стабильные #error 502 для #distribution. Правильный вариант с bucket.s3.amazonaws.com:

Origins:
  - DomainName: !Join ['',[!Ref Bucket, '.s3.amazonaws.com' ]]

#issue

Если при использовании #pg_dump получаем #error схемы #topology

pg_dump: [archiver (db)] query failed: ERROR: permission denied for schema topology

или другого #PostGIS расширения для #Postgres #RDS, то нужно выполнить следующие спеллы:
1. Сменить владельца расширения #rdsadmin на #rds_superuser.
2. Сменить владельца объектов с помощью функции.
alter schema topology owner to rds_superuser;
CREATE FUNCTION exec(text) returns text language plpgsql volatile AS $f$ BEGIN EXECUTE $1; RETURN $1; END; $f$;
SELECT exec('ALTER TABLE ' || quote_ident(s.nspname) || '.' || quote_ident(s.relname) || ' OWNER TO rds_superuser;')
FROM (
SELECT nspname, relname
FROM pg_class c JOIN pg_namespace n ON (c.relnamespace = n.oid)
WHERE nspname in ('tiger','topology') AND
relkind IN ('r','S','v') ORDER BY relkind = 'S')
s;

Текущие функции #CloudFormation, которые поддерживаются по разным #region.

Рекомендуемый минимальный #db_instance_type для #RDS #Postgres - db.t2.small (minimum size - 20GB), т.к. db.t2.micro не поддерживает шифрование.

#encryption

#credits и #baseline для #t2 и #t3 инстансов - не забываем, что у #t3 два процессора даже для #nano, накопленные кредиты не сбрасываются в течении недели после остановки, да и просто всё выгодней, а цена ниже (чем у #t2).

#CloudFront нельзя завести на #internal #LoadBalancer, т.к. он не умеет (не может) работать с элементами в #VPC, потому с #CloudFront — только #public (#internet-facing) #LoadBalancer.

#DynamoDB #docker образ для локального #development - https://hub.docker.com/r/amazon/dynamodb-local/.

Завести #external (internet-facing/#public) #LoadBalancer (#ELB/#ALB/#NLB) на расположенные в #private #subnet виртуалки никаких проблем нет. Просто указываем для него, как и положено, #DMZ #subnet (#public):

albExt:
  Type: AWS::ElasticLoadBalancingV2::LoadBalancer
  Properties:
    Name: externalAlb
    Scheme: internet-facing
    Subnets: # DMZ if public
      - !ImportValue subnetVpc4DmzA
      - !ImportValue subnetVpc4DmzB
    SecurityGroups:
      - !Ref sgAlb

А виртуалкам, расположенным и в #private_subnet добавляем в #security_group правила полного доступа с данного балансера:

sgInstance:
  Type: AWS::EC2::SecurityGroup
  Properties:
    VpcId: !ImportValue vpc4
    GroupDescription: Full access for ALB
    SecurityGroupIngress:
      - IpProtocol: tcp
        FromPort:   0
        ToPort:     65535
        SourceSecurityGroupId: !Ref sgAlb
        Description: All TCP trafic - only for ALB

#CloudFormation #templates

Чтобы защитить #CloudFormation стэки от удаления/изменения (#termination_protection неудобно и даёт лишь защиту от удаления) в каком-то аккаунте (предполагая, что он входит в AWS #Organizations), можно добавить следующее #SCP:

"CloudFormation CRUD Deny"

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Stmt1539948147000",
      "Effect": "Deny",
      "Action": [
        "cloudformation:CreateChangeSet",
        "cloudformation:CreateStack",
        "cloudformation:CreateStackInstances",
        "cloudformation:CreateStackSet",
        "cloudformation:CreateUploadBucket",
        "cloudformation:DeleteChangeSet",
        "cloudformation:DeleteStack",
        "cloudformation:DeleteStackInstances",
        "cloudformation:DeleteStackSet",
        "cloudformation:ExecuteChangeSet",
        "cloudformation:SetStackPolicy",
        "cloudformation:UpdateStack",
        "cloudformation:UpdateStackInstances",
        "cloudformation:UpdateStackSet",
        "cloudformation:UpdateTerminationProtection"
      ],
      "Resource": [
        "*"
      ]
    }
  ]
}

#blue_green_deployment

При использовании #DNS #Alias нужно учитывать, что #HostedZoneId разный для разных Alias Target.
Для #CloudFront он фиксированный Z2FDTNDATAQYW2:

aliasSite:
  Type: AWS::Route53::RecordSet
  Properties:
    HostedZoneName: !Join ['', [!Ref MainDomain, '.']]
    Name:           !Ref MainDomain
    Type:           A
    AliasTarget:
      DNSName:      !Ref CnameSite
      HostedZoneId: Z2FDTNDATAQYW2

Для #LoadBalancer нужно получать его через #GetAtt, для #ELB это:

HostedZoneId1:
Value: !GetAtt [elbExt, 'CanonicalHostedZoneNameID']

Для #ALB это:

HostedZoneId1:
Value: !GetAtt [albExt, 'CanonicalHostedZoneID']

Для #alias на другую #RecordSet нужно получать #HostedZoneId домена:

def Result = sh( script: 'aws route53 list-hosted-zones-by-name --dns-name '+gos.MainDomain, returnStdout: true )
def ResultJson = readJSON ( text: Result )
Stack['dns']['params']['HostedZoneIdDomain'] = ResultJson['HostedZones'][0]['Id'].split('/')[2]

При использовании #ELB (созданного через #CloudFormation) с большим количеством инстансов, стоит помнить про фичу Cross-Zone Load Balancing, которая отключена по умолчанию (при создании балансера через консоль - включена по умолчанию).
Итого: для #ELB её нужно включать для более гладкого распределения трафика. У #ALB всегда включена, у #NLB - нужно включать самому.

#EC2 #network #performance cheat-sheet.

#info