Secure IaC Deployment: CloudFormation, StackSets, and Service Catalog

Infrastructure as code makes security consistent because every account receives the same reviewed definition instead of hand-built configuration. A control that exists in most accounts is a finding waiting to happen in the rest, and console-built infrastructure guarantees that kind of inconsistency. When every resource comes from a CloudFormation template, the template — not the console — is where security is defined, reviewed, and versioned.

The change-control properties come from where the template lives, so it is worth being precise:

So "peer reviewed, attributable, revertible" requires a repository with pull requests feeding the deployment pipeline; versioned object storage gives only the revert.

The counterpart to declared state is detecting departure from it. Drift detection compares a stack's actual resource configuration against its template and reports each resource as IN_SYNC, MODIFIED, or DELETED, or NOT_CHECKED for resource types that drift detection does not support. Its scope is narrower than it looks: CloudFormation compares only the property values explicitly set in the template or its parameters. A property the template never declares — say, a bucket's public-access settings left at their defaults — is not compared, so someone can change it out-of-band and the resource still reports IN_SYNC. If a setting matters for security, declare it explicitly so drift detection can see it; continuous evaluation of undeclared settings is AWS Config's job.

Drift detection tells you what changed, not who: for attribution you pivot to the CloudTrail management event for the modifying API call, which records the principal, the time, and the source IP address. Drift on an ordinary stack is a hygiene problem; drift on a security stack — an IAM trust policy widened, a security group rule added — is a potential incident.

Note the boundary: CloudFormation drift and template review govern deployment consistency. Continuously evaluating whether deployed resources comply with rules is AWS Config's job, which belongs to Task 6.3. And where accounts, OUs, and SCPs come from is Task 6.1 — this lesson assumes that structure exists and deploys into it.

CloudFormation gives a deployed security stack three distinct protections — stack policies, deletion/replacement policies, and termination protection — plus service roles that control who deploys it. Each covers a different event:

A stack policy is a JSON document that controls which resources can be modified during stack updates. The pattern: deny Update:* on critical logical resources — the trail, the central logging bucket, the audit roles — so a routine update cannot replace or delete them. Updating a protected resource requires an explicit, temporary policy override, which turns a silent mistake into a deliberate act. A stack policy is evaluated only by CloudFormation, though: an administrator calling the EC2 or IAM API directly is not subject to it. Preventing out-of-band edits needs an IAM-layer control that account administrators cannot remove — typically an SCP that denies the modifying actions on baseline resources unless aws:PrincipalArn matches the pipeline's deploy role. Drift detection then becomes confirmation rather than the only line of defence.

DeletionPolicy: Retain keeps a resource when its stack is deleted (Snapshot captures a final snapshot for supported types). Evidence stores — log buckets, KMS keys, audit tables — should carry it so evidence outlives the stack, with UpdateReplacePolicy: Retain covering replacement during updates.

A service role answers who deploys what. Instead of acting with the caller's credentials, CloudFormation assumes a dedicated IAM role scoped to the resource types a template legitimately creates. The deploying human or pipeline needs only CloudFormation permissions plus iam:PassRole — and the PassRole statement must name that specific role's ARN. iam:PassedToService only limits which service receives the role; on a wildcard resource such as role/* it still lets the caller hand CloudFormation an administrator role and deploy anything. That separation — users hold the right to use a scoped role, never the underlying permissions — is the load-bearing idea of this task, and it returns in Service Catalog launch roles and pipeline design below.

CloudFormation StackSets deploy one template as stack instances across many accounts and Regions from a single administration point, which makes them the standard mechanism for giving every account the same security stack. The baseline StackSet typically carries what Task 6.1 decided every account needs: GuardDuty detector settings, the AWS Config recorder and delivery channel, standard security-tooling roles, and log-forwarding plumbing.

The two permission models behave differently in ways that decide most StackSet scenarios:

Two consequences follow. A requirement covering "current and future accounts" with no manual step is met only by service-managed permissions with automatic deployment turned on. And when the management account also needs the baseline, deploy it there separately — as an ordinary stack or through a self-managed stack set — because adding its ID as a target does not override the exclusion.

Operation preferences control rollout, not permissions: maximum concurrent accounts (how many accounts deploy at once), failure tolerance (how many account failures per Region stop the operation), Region concurrency (sequential or parallel), and Region order. A low concurrency or zero failure tolerance slows or halts an operation; it does not by itself cause a particular account's instance to fail. When one account fails, look at that account's roles and guardrails (see the walkthrough below).

Shift-left validation means rejecting a misconfiguration before it reaches an account: caught in CI it costs a failed build, caught after deployment it costs an incident. The tools differ in what they check and when they run:

cfn-lint answers "is this valid CloudFormation?" — malformed properties, invalid values, structural mistakes. It has no notion of your organization's security policy. CloudFormation Guard answers "is this allowed here?": every S3 bucket encrypted, no security group open to 0.0.0.0/0 on SSH, no IAM policy with "Action": "*". Run in the pipeline, a Guard violation fails the build — this is how a security team's requirements become machine-enforced instead of living in a wiki. Because Guard evaluates any structured document, the same rule logic can gate other IaC tools (see the Terraform section below).

CloudFormation Hooks move a policy check into the account itself: a hook activated in the account runs every time CloudFormation provisions matching resources, so it catches deployments that bypass the CI pipeline. Hooks can be written as Guard rules or as Lambda functions, and Control Tower's proactive controls are delivered as hooks. AWS Config also has a proactive evaluation mode for supported rules, which evaluates proposed resource properties before deployment — but on its own it only reports a result and never blocks or remediates; the blocking comes from a hook or pipeline that acts on that result. Config rules in their usual detective mode, including custom policy rules written in Guard, evaluate resources that already exist, so they detect and remediate after the fact rather than prevent.

For CDK projects, cdk-nag applies rule packs to the synthesized output; CDK apps synthesize to CloudFormation templates, so every template-level control here still applies. Order the gates: lint and Guard on every commit in CI, hooks as the in-account backstop, change-set review guarding the production apply, Config watching what exists.

Third-party IaC tools such as Terraform are secured with the same principles as CloudFormation — reviewed code, least-privilege deploy roles, pre-deployment policy checks — plus one risk CloudFormation does not have: the state file. Terraform records every managed resource's attributes in state, and that includes secrets such as a database master password, stored in plaintext. Marking a variable sensitive only redacts it from plan and apply output on screen; the value is still written to state.

Protect remote state as the secret store it effectively is:

• Confidentiality — store state in an S3 backend encrypted with a KMS key, and limit both the bucket policy and the key policy to the pipeline's deploy role (plus break-glass). Developers who can read the state can read every secret in it.
• Integrity and concurrency — state locking (S3 lock files, or a DynamoDB table in older setups) stops two runs writing state at once, and bucket Versioning lets you recover a corrupted or overwritten state. Neither does anything for confidentiality.
• Keep secrets out of state where possible — let the service own the secret (for example, RDS managing the master password in Secrets Manager), or use Terraform's ephemeral values and write-only arguments, which are not persisted to state.

Gating a Terraform apply uses the plan, not the HCL source: export the saved plan as JSON (terraform show -json) and evaluate it with CloudFormation Guard rules in the build, failing the stage before apply runs. This lets a team reuse its existing Guard rule logic across both tools. cfn-lint cannot do this — it understands only CloudFormation templates. Service Catalog also supports Terraform-based products, so a governed self-service path does not require converting everything to CloudFormation.

Secrets belong in a secret store and are pulled into a deployment by reference; a template or stack parameter should never carry the value. The classic finding is a database password visible in a CloudFormation template or in the stack's parameter history, and the mitigations rank clearly.

Plaintext secrets in templates are always wrong. Templates live in Git, flow through pipelines, and are readable via cloudformation:GetTemplate — a secret in a template is published to everyone with repository or stack read access and preserved in version history.

The NoEcho parameter attribute masks a parameter's value (as asterisks) in console and Describe API output. It does not encrypt the value or remove it from what CloudFormation stores. If the parameter has a default, the default is masked in output too — but the default is written in the template itself, so anyone who can read the template has the secret. NoEcho also does not mask anything you place in the template's Metadata section, a resource's Metadata attribute, or Outputs, so a NoEcho value referenced there is exposed. Treat NoEcho as display hygiene, never as secrets management.

The correct pattern is a dynamic reference: the template stores a pointer, and CloudFormation resolves the value at deployment time. The three forms differ in ways that matter:

With either secure form, the secret never appears in the template, the repository, or the stack's stored parameters, and access to it is governed separately by IAM, the key policy, and (for Secrets Manager) the secret's resource policy. When the requirement includes scheduled rotation without a custom process, Secrets Manager is the store that provides it. Better still, resources such as AWS::RDS::DBInstance can have RDS manage the master password in Secrets Manager, so no human ever supplies one.

Three services handle cross-account sharing and central enforcement, and each shares a different thing: Service Catalog shares approved templates that others launch, AWS RAM shares live resources that others use, and Firewall Manager pushes and maintains network protections everywhere.

AWS Service Catalog

Service Catalog packages approved templates (CloudFormation or Terraform) as products in portfolios, shared across the organization so one security-owned catalog serves every account. Constraints attached to a product in a portfolio shape how it launches:

A launch constraint can name a role ARN, but an ARN pins one account. For a portfolio shared to many accounts, set LocalRoleName instead: Service Catalog uses the role with that name in the account where the user launches, so a role of the same name deployed to every spoke (typically by a stack set) makes one constraint work everywhere. Control Tower's Account Factory is itself built on Service Catalog.

AWS Resource Access Manager (RAM)

RAM shares live resources with specific accounts, OUs, or the whole organization, so one owner manages a resource that many accounts use instead of each account running a copy. Sharing with the whole organization or with OUs requires turning on RAM sharing with AWS Organizations (which also removes the invitation step); individual accounts can be shared with by invitation without it; some resource types can also be shared with external accounts, but subnets only within the organization. The owner always keeps control:

That last row is the general point: when a resource must stay single-owner, share it with RAM; a stack set or Service Catalog product would instead create an independent copy in each account that drifts on its own.

AWS Firewall Manager

Firewall Manager is central enforcement for network protections. Its prerequisites are an organization with all features enabled, a Firewall Manager administrator account (set from the management account; can be a delegated member account), and AWS Config enabled in every in-scope account and Region, because Firewall Manager detects resources and noncompliance through Config. Policies are scoped to accounts/OUs and resource types, automatically cover new accounts and new resources, and with automatic remediation on, fix noncompliance instead of only reporting it. Policy types:

• AWS WAF — applies a web ACL / rule groups to ALBs, API Gateway stages, CloudFront and similar resources; auto remediation associates it with new in-scope resources and restores it if removed.
• Security group, in three kinds: common (applies a primary security group to in-scope resources), content audit (checks the rules in teams' own security groups against a reference group or managed rule list, and with remediation removes noncompliant rules — e.g. world-open admin ports — without taking over the groups themselves), and usage audit (finds and cleans up unused or redundant groups).
• Shield Advanced (requires a Shield Advanced subscription), Network Firewall, Route 53 Resolver DNS Firewall, network ACL, and third-party firewall policies.

A stack set deploys what its template declares at deployment time; it does not keep watching for in-scope resources that appear afterwards or for protections that are later changed. Firewall Manager evaluates its policies continuously across the organization and, with automatic remediation on, applies or reapplies the protection — continuous, org-wide enforcement is what it adds over a one-time deployment.

Four services in this lesson all "deploy things to many accounts"; they differ in what is standardized and who initiates:

Tagging is part of deploy-time consistency too: bake required tags into StackSet templates and Service Catalog products so correct tags are the default, then enforce and group them as described in the next section.

Tags organize resources by department, cost center, environment, or application, and four different mechanisms act on them — one standardizes, one requires, and two group. Mixing them up is the usual mistake:

Requiring a tag at creation takes care. The SCP must deny the create action itself (for EC2, ec2:RunInstances on the instance resource) with a Null condition on aws:RequestTag/CostCenter. A deny on ec2:CreateTags does not work for this: tagging authorization is checked only when the launch request includes tags, so a launch with no tags never evaluates it. Tag policies also have a newer required tag key setting, but it is enforced only through infrastructure-as-code tools that validate against it — the CloudFormation AWS::TagPolicies::TaggingComplianceValidator hook, tag-policy validation in the Terraform AWS provider configuration, or a Pulumi policy pack — so console and CLI launches are not blocked. A detective required-tags AWS Config rule catches stragglers (evaluation itself is Task 6.3). The common pairing is a tag policy to standardize keys and values plus the Config rule or the tag policy's compliance report to find existing noncompliant resources.

Resource group scope has three rules that change results:

• A resource group is Regional — resources in two Regions need a group in each Region.
• A tag-based group's query matches only resources that carry all listed tag keys (for each key, any of its listed values). Each additional tag key narrows membership.
• A CloudFormation stack-based group contains only that stack's resources, so it reflects that stack's boundary, not every resource an application uses. A tag-based group picks up new resources automatically as soon as they carry the tags.

Tags also drive attribute-based access control, which is covered with IAM authorization in Domain 4.

The pipeline that deploys infrastructure is itself infrastructure to secure: the CI/CD system should hold almost nothing and assume a scoped deploy role per environment — a cross-account role in each target account (dev, staging, prod), scoped to the resource types its templates create. Production adds a manual approval gate on the change set before execute.

External CI systems should authenticate with OIDC federation: the CI provider issues a short-lived token that an IAM OIDC identity provider trusts, and the pipeline assumes a role with no long-term access keys stored anywhere. Environment isolation lives in each role's trust policy: condition it on the token's sub claim (and aud) so only that environment's pipeline — a specific repository, branch, or deployment environment — can assume it. If the trust condition is broad — matching every repository or workflow the CI provider issues tokens for — any of those pipelines can assume the role, so a compromise in a lower environment becomes a production compromise. IAM Roles Anywhere is the alternative for workloads outside AWS that can hold an X.509 certificate: it needs a certificate authority registered as a trust anchor, so it fits where certificate issuance is already managed; where the CI system issues OIDC tokens, web identity federation needs no certificates to distribute or rotate. (The federation mechanics live in Domain 4.)

Remember which policies can stop a deploy role that "has every permission it needs." SCPs cap what principals in member accounts can do, and resource control policies (RCPs) cap what can be done to resources in member accounts; neither ever grants anything — they only set a maximum, so the deploy role still needs an allow from its own policies (or a resource policy), and anything outside the SCP or RCP limit is refused regardless. SCPs and RCPs do not apply to the management account. Artifact integrity closes the loop: the template that was reviewed and scanned must be the one that deploys, so pipeline stages consume immutable, access-controlled artifacts rather than re-fetching from a mutable branch.

Walkthrough. A baseline stack set reports FAILED for one member account while the others succeed. Start with the account-specific causes. Under self-managed permissions, the execution role is missing from that account or its trust policy does not name the administration role; StackSets then cannot get into the account at all, so none of the work the operation should have done appears in that account's activity history. Recreate or fix the role and retry the instance. If the account's CloudTrail instead records the template's API calls being refused with AccessDenied although the execution role's own policies permit them, look above the role: a guardrail attached to the account or its OU (an SCP, or an RCP on the target resource) is capping it; adjust the guardrail exemption or the template. A cause that explains one failing account has to be specific to that account; operation preferences such as concurrency and failure tolerance govern the whole rollout, so they never single out one account. Later, drift detection shows the account's Config recorder MODIFIED: drift names the change, CloudTrail names the actor; re-apply the template and close the path with an SCP denying recorder changes except by the deploy role, so the gap is shut, not just repaired.