Secure, consistent deployment across accounts

CloudFormation StackSets across accounts

Yesterday you built the account structure with Organizations and Control Tower. Today you fill those accounts with the same secure resources, every time. Skill 6.2.1 is about infrastructure as code (IaC): you describe resources in a template and let a tool create them. When one template must reach many accounts and Regions, the AWS answer is CloudFormation StackSets.

A StackSet is one template plus parameters. Each copy that lands in one account and one Region is a stack instance. Typical uses are security baselines: a CloudTrail trail, a GuardDuty setting, an IAM role for the security team, an AWS Config rule, or an S3 bucket policy.

Drift detection and stack policies

IaC only stays secure if people don’t change resources by hand. Drift detection compares the real resources with the template. A resource is MODIFIED or DELETED; a stack is DRIFTED or IN_SYNC; a StackSet is drifted if any stack instance has drifted. Drift detection is an operation you start (or schedule yourself, for example from EventBridge or an AWS Config rule); it only reports and never fixes anything. It checks only properties that are set in the template and doesn’t include nested stacks. A stack policy protects resources from updates: once you set one, every resource is protected unless an Allow statement says otherwise, and Deny always wins. You can’t delete a stack policy, only replace it, and you can pass a temporary override policy for one update. Stack policies don’t stop stack deletion; turn on termination protection for that.

$ aws cloudformation create-stack-set --stack-set-name security-baseline \
    --template-body file://baseline.yaml \
    --permission-model SERVICE_MANAGED \
    --auto-deployment Enabled=true,RetainStacksOnAccountRemoval=false \
    --capabilities CAPABILITY_NAMED_IAM

$ aws cloudformation create-stack-instances --stack-set-name security-baseline \
    --deployment-targets OrganizationalUnitIds=ou-ab12-prod,ou-ab12-dev \
    --regions us-east-1 eu-west-1 \
    --operation-preferences MaxConcurrentPercentage=25,FailureTolerancePercentage=10
{ "OperationId": "4f1c2a9e-1d2b-4c3a-9e8f-0123456789ab" }

$ aws cloudformation detect-stack-set-drift --stack-set-name security-baseline

Policy as code: cfn-lint, Guard and Hooks

StackSets copy a template everywhere, so a mistake in the template is copied everywhere too. Skill 6.2.1 names two tools to catch mistakes before deployment: cfn-lint and CloudFormation Guard. AWS adds a third layer inside CloudFormation itself: CloudFormation Hooks. This idea is called shift left: find the problem as early, and as cheaply, as possible.

CloudFormation Hooks and third-party IaC

Hooks are checks that CloudFormation runs before it provisions resources. They can target resources, whole stacks, change sets and also resources created through the Cloud Control API. If a resource fails, the Hook either fails the operation or only emits a warning, depending on its failure mode. You can build Hooks from Guard rules, from Lambda functions, from custom code, or turn on AWS Control Tower proactive controls, which are ready-made Hooks. Remember the three Control Tower control behaviours from Day 1: preventive (SCPs and RCPs), detective (Config rules) and proactive (Hooks).

Third-party IaC such as Terraform or Pulumi is fine for the exam if you secure it: keep the Terraform state file in an encrypted, versioned S3 bucket with tight access (state can contain secrets), let the pipeline assume a role per account (for example with OIDC federation) instead of using long-term access keys, scan the plan with Guard or similar tools, and keep AWS Config rules as a detective safety net.

# s3.guard
let buckets = Resources.*[ Type == 'AWS::S3::Bucket' ]
rule s3_encrypted when %buckets !empty {
    %buckets.Properties.BucketEncryption exists
    %buckets.Properties.PublicAccessBlockConfiguration.BlockPublicAcls == true
}

$ cfn-guard validate --data template.yaml --rules s3.guard
template.yaml Status = FAIL
FAILED rules
s3.guard/s3_encrypted    FAIL

$ cfn-lint template.yaml
E3002 Additional properties are not allowed ('BucketNme' was unexpected)
template.yaml:12:7

Tagging strategy, tag policies and SCPs

Skill 6.2.2 is about tags: key and value labels such as Environment=prod. Tags let you group resources for cost reports, automation, incident response and access control (ABAC from the IAM days). They only help if everyone uses the same keys and every resource actually has them. Tag keys and values are case sensitive on the resource, so CostCenter and costcenter are two different tags. Careful: in an IAM or SCP condition, the tag key inside the key name (aws:RequestTag/CostCenter) is matched case-insensitively, while the value is compared exactly by StringEquals. To force one spelling of the key, use a tag policy that enforces capitalization or a Deny on aws:TagKeys.

A simple tagging strategy

Start with a short list of mandatory keys, for example Department, CostCenter, Environment (prod, staging, dev), Owner and DataClassification. Write them down with the exact spelling and allowed values. Then: put the rules in a tag policy, require the most important keys at creation with an SCP, apply default tags in IaC (StackSets, Service Catalog TagOptions, Terraform default tags), and use AWS Resource Groups to build tag-based groups that tools like Systems Manager can act on. AWS Config’s required-tags rule is a detective check for anything that slipped through.

{ "Version": "2012-10-17",
  "Statement": [{
    "Sid": "RequireCostCenterOnLaunch",
    "Effect": "Deny",
    "Action": "ec2:RunInstances",
    "Resource": "arn:aws:ec2:*:*:instance/*",
    "Condition": { "Null": { "aws:RequestTag/CostCenter": "true" } }
  }]}

Tag policy fragment (standard spelling, allowed values, enforced):
{ "tags": { "costcenter": {
    "tag_key":   { "@@assign": "CostCenter" },
    "tag_value": { "@@assign": ["100", "200", "300"] },
    "enforced_for": { "@@assign": ["ec2:instance"] } } } }

AWS Firewall Manager policies

Skill 6.2.3 says deploy and enforce policies and configurations from a central source, and the example is AWS Firewall Manager. On Infrastructure Day 1 you met it as the way to roll out WAF and Shield Advanced. Here you need the full picture: its prerequisites, all its policy types, and how scope and auto-remediation work.

Security group, Network Firewall and DNS Firewall policies

Security group policies come in three kinds. A common policy pushes a standard security group (for example “allow HTTPS from the corporate range”) to in-scope resources, such as EC2 instances and ALBs selected by tag. A content audit policy checks the rules inside groups and flags or removes forbidden ones, such as SSH from 0.0.0.0/0. A usage audit policy finds and cleans up unused or redundant groups. Changes to groups on EC2 network interfaces can take up to six hours to show in Firewall Manager. A Network Firewall policy creates firewall endpoints in in-scope VPCs with a central firewall policy, in a distributed model (one firewall per VPC) or a centralized inspection VPC. A DNS Firewall policy associates Route 53 Resolver DNS Firewall rule groups with VPCs to block lookups of bad domains. Like WAF policies, it uses central rule groups that run first and last, and account teams may add their own in between. A network ACL policy enforces baseline NACL rules on subnets.

$ aws fms put-policy --policy '{
  "PolicyName": "no-open-ssh",
  "SecurityServicePolicyData": {
    "Type": "SECURITY_GROUPS_CONTENT_AUDIT",
    "ManagedServiceData": "{\"type\":\"SECURITY_GROUPS_CONTENT_AUDIT\",\"securityGroupAction\":{\"type\":\"ALLOW\"},\"securityGroups\":[{\"id\":\"sg-0audit\"}]}"
  },
  "ResourceType": "AWS::EC2::SecurityGroup",
  "IncludeMap": { "ORG_UNIT": ["ou-ab12-workloads"] },
  "ExcludeResourceTags": false,
  "RemediationEnabled": false }'

$ aws fms list-compliance-status --policy-id a1b2c3d4-...
  "PolicyComplianceStatusList": [ { "MemberAccount": "222233334444",
     "EvaluationResults": [ { "ComplianceStatus": "NON_COMPLIANT", "ViolatorCount": 3 } ] } ]

AWS Service Catalog

Skill 6.2.4 is about securely sharing resources across accounts. The first example is AWS Service Catalog: instead of giving teams broad permissions to build things themselves, a central team offers a menu of approved, secure products. Teams launch them with a click, and the product is always built the approved way.

Sharing portfolios safely

When you share a portfolio you share a reference: the products and constraints stay in sync with your changes. The recipient administrator decides which of their users get access. With Organizations sharing you can also share principal names (role names that are matched in each account) and TagOptions. AWS recommends the IAM principal type rather than a pattern that could match roles created later, to avoid a privilege escalation path. Service Catalog AppRegistry is a related feature that records your applications and their resources.

$ aws servicecatalog create-constraint --type LAUNCH \
    --portfolio-id port-2abcxyz --product-id prod-7s3ncmnp \
    --parameters '{"LocalRoleName": "SCLaunch-S3Product"}'

$ aws servicecatalog create-portfolio-share --portfolio-id port-2abcxyz \
    --organization-node Type=ORGANIZATIONAL_UNIT,Value=ou-ab12-workloads \
    --share-principals --share-tag-options
{ "PortfolioShareToken": "share-6ffmm6rj6uqcy" }

AWS Resource Access Manager (RAM)

Service Catalog shares recipes. AWS RAM shares the actual resource. One network team can own a VPC subnet, a Transit Gateway or a Route 53 Resolver rule, and many accounts can use it. This avoids building the same thing in every account and keeps control with one owner.

VPC sharing in practice

In VPC sharing the network account owns the VPC and shares subnets with participant accounts in the same organization. Participants launch their own EC2 instances, RDS databases and Lambda functions into the shared subnets. Each participant owns and pays for its own resources and can’t see or change other participants’ resources or the subnet, route tables and NACLs. The owner can’t change participant resources either. This splits duties well: the network team controls routing and inspection; app teams control their workloads. Firewall Manager itself uses RAM to share Network Firewall and DNS Firewall rule groups, which is why RAM sharing is one of its prerequisites.

$ aws ram enable-sharing-with-aws-organization
{ "returnValue": true }

$ aws ram create-resource-share --name prod-subnets \
    --resource-arns arn:aws:ec2:eu-west-1:111122223333:subnet/subnet-0a1b \
                    arn:aws:ec2:eu-west-1:111122223333:subnet/subnet-0c2d \
    --principals arn:aws:organizations::111122223333:ou/o-abc123/ou-ab12-workloads \
    --no-allow-external-principals
{ "resourceShare": { "name": "prod-subnets", "status": "ACTIVE",
    "allowExternalPrincipals": false, "owningAccountId": "111122223333" } }

Cheatsheet extras: CloudFormation service roles, iam:PassRole and stack condition keys

Your cheat sheet has a warning that this lecture only touched: whoever can run a CloudFormation stack can borrow the permissions of the stack’s service role. That is a classic privilege escalation path, and it is also how you safely let developers deploy without giving them admin rights. The cheat sheet also lists IAM condition keys that control which templates and roles may be used.

{
  "Version": "2012-10-17",
  "Statement": [
    { "Sid": "StacksWithDeployRoleOnly",
      "Effect": "Allow",
      "Action": [ "cloudformation:CreateStack", "cloudformation:UpdateStack",
                  "cloudformation:CreateChangeSet" ],
      "Resource": "arn:aws:cloudformation:*:111122223333:stack/dev-*/*",
      "Condition": {
        "StringEquals": { "cloudformation:RoleArn":
          "arn:aws:iam::111122223333:role/CfnDeployRole" },
        "StringLike": { "cloudformation:TemplateUrl":
          "https://approved-templates.s3.amazonaws.com/*" } } },
    { "Sid": "PassOnlyTheDeployRole",
      "Effect": "Allow",
      "Action": "iam:PassRole",
      "Resource": "arn:aws:iam::111122223333:role/CfnDeployRole",
      "Condition": { "StringEquals": { "iam:PassedToService": "cloudformation.amazonaws.com" } } }
  ]
}

Lecture summary map

Day 2 on one screen.

1. Mind map

2. Match the requirement to the control

3. “If the question says… pick…”

Must-remember cheat sheet

Core quiz

Check the basics first. Pick an answer, then press Check.

Hard quiz

Harder than most real exam questions on purpose, with one “choose two” and one matching question. Aim for 9 out of 12 before Day 3.

Practice test questions (from your mock exams)

Five questions about baselines across accounts, tags and Service Catalog. These questions come from your own mock exams in the practice tests folder, matched to this lecture. Each one was checked against current AWS behavior, so some wording and answers are updated; the source is shown at the end of each explanation.

Hands-on lab (30 minutes, low cost)

1. On your laptop, install the tools (pip install cfn-lint, and cfn-guard from its GitHub releases). Write a small template with one S3 bucket and a typo in a property name. Run cfn-lint and read the error. Fix it, then write the s3.guard rule from section 2 and run cfn-guard validate until it passes. This step is free.
2. In one account, create the two self-managed StackSet roles (AWS provides sample templates for AWSCloudFormationStackSetAdministrationRole and AWSCloudFormationStackSetExecutionRole). Create a StackSet with your bucket template and deploy it to your own account in two Regions.
3. In the S3 console, change the bucket’s tags or versioning by hand. Run Detect drift on the StackSet and find the MODIFIED resource and the property difference.
4. If you have a test organization: create a tag policy for CostCenter, attach it to a test account, and view compliance in Resource Groups > Tag policies. Try launching a t3.micro with and without the tag after attaching the SCP from section 3, then terminate it at once.
5. In AWS RAM, create a resource share for a managed prefix list (free) and look at the managed permission it uses. Delete the share.
6. Clean up: delete the stack instances, then the StackSet; empty and delete the buckets; detach and delete the SCP and tag policy; delete the prefix list. Don’t create a Firewall Manager policy in a personal account just to try it: you pay per policy per Region, plus AWS Config recording in every account in scope.