Enforcing policy from a central source
Lesson 2 of 3 in Consistent, Secure Deployment.
Here is the failure this lesson exists to prevent. A company standardises on a WAF web ACL with managed rule groups, rolls it out across 60 accounts, and is genuinely compliant on Friday. On Monday a team creates a new Application Load Balancer. Nobody did anything wrong; nobody associated the web ACL either. The control did not fail — it was never reachable by a resource that did not exist when it was applied.
Central enforcement means the control is a property of being in scope, not of someone having remembered. AWS Firewall Manager does this for the protection services: you define a policy once in a designated administrator account, scope it to accounts, OUs, resource types and tags, and Firewall Manager keeps in-scope resources configured — including resources and accounts that appear later, and including resources somebody deliberately detached.
| Policy type | What it pushes out | Typical requirement in a stem |
|---|---|---|
AWS WAF | A web ACL with your rule groups and managed rule groups, associated to in-scope CloudFront distributions, ALBs, API Gateway stages, AppSync APIs and more | “Every internet-facing application must sit behind the same WAF rules, including applications deployed next quarter” |
Shield Advanced | Shield Advanced protections applied to in-scope resource types, with DDoS protection consistently enabled | “All Elastic IPs and load balancers must be protected against DDoS without the application teams opting in” |
Security group — common | A primary security group replicated to and associated with in-scope resources | “A baseline security group must be attached to every ENI in the organization” |
Security group — content audit | Audit of existing security group rules against allowed or denied templates, with optional automatic removal of offending rules | “No security group anywhere may allow 0.0.0.0/0 on port 22, and violations must be remediated” |
Security group — usage audit | Detection of unused and redundant security groups | “Clean up security groups no resource references” |
Network Firewall | Network Firewall endpoints and rule groups across VPCs, in centralized or distributed deployment models | “Inspect egress traffic for every VPC in the organization with one managed rule set” |
Route 53 Resolver DNS Firewall | DNS Firewall rule groups associated with in-scope VPCs | “Block DNS resolution of known malicious domains in every VPC” |
Network ACL | Network ACL entries applied to in-scope subnets, with drift from the defined entries reported and remediable | “A standard subnet-level deny must exist and stay in place” |
Third-party firewalls | Palo Alto Cloud NGFW and Fortigate CNF deployments managed through the same policy framework | “Our existing vendor appliance must be deployed consistently across accounts” |
Firewall Manager has prerequisites, and they are a reliable exam question in their own right. The organization must run all features. The management account must designate a Firewall Manager administrator account — and since 2023 you may designate several, each scoped to particular OUs, Regions or policy types, so the network team and the application security team do not share one blast radius. AWS Config must be enabled in every account and Region a policy covers, because Firewall Manager evaluates resource configuration through Config; a Region where Config is off is a Region where policies silently find nothing. Shield Advanced policies additionally require the Shield Advanced subscription, and Network Firewall and DNS Firewall policies require resource sharing with AWS RAM to be enabled in the organization.
Each policy then chooses its posture: automatic remediation, where Firewall Manager brings non-compliant resources into line itself, or audit only, where it reports and leaves them alone. Start audit-only on a brownfield estate, read the compliance report, then switch remediation on — turning it on blind across 60 accounts is how a policy rollout becomes an outage.
How a resource created on Monday inherits Friday’s control
- A team creates a new ALB in a new account
Nobody filed a ticket, nobody read the standard, and the account did not exist when the control was designed.
- The account sits in the Prod OU
OU membership is the only thing the team had to get right — and account vending did that for them.
- In scope of a Firewall Manager policy?
Scope is accounts and OUs, resource types, and tag include/exclude rules. Note the tag path: tags are how you carve exceptions deliberately instead of by omission.
- Firewall Manager associates the web ACL
Automatic remediation. If the policy were audit-only, this box would instead be “report non-compliant” — the control would see the gap and not close it.
- Config records it; organization rules evaluate it
The second, independent net: organization Config rules and conformance packs evaluate the resource whatever created it, including console clicks that no pipeline saw.
- Compliant?
A verdict per resource per rule, aggregated into the security account’s view.
- Config remediation runs an SSM Automation runbook
Optionally with retries, or gated behind manual remediation where an automatic fix would be too blunt.
- Non-compliance routed to the security account
EventBridge on the compliance-change event → SNS or a ticket. A finding nobody receives is not a detective control.
- The control is a property of the OU, not of the team
That sentence is the whole point of a consistent deployment strategy. Every mechanism in this module is a way of making it true.
Organization Config rules are the other central source, and the distinction from a plain Config rule is worth stating plainly: an organization rule is deployed from the management account or the Config delegated administrator into every member account, with the option to exclude named accounts. A conformance pack does the same for a bundle of rules and their remediation as one versioned artifact, which is why "deploy AWS Config conformance packs" appears in the exam guide as an automation answer rather than a per-account chore.
Then there are tags, which the guide calls out directly: grouping resources by department, cost centre and environment. Tags are the organizing device that the rest of this module leans on, and they appear in four distinct roles that candidates blur together.
Organization — AWS Resource Groups and Tag Editor let you find and act on "everything tagged Environment=prod" across accounts and Regions, and activating cost allocation tags turns the same keys into a billing dimension.
Scope — a Firewall Manager policy, a Config rule's scope, a Backup plan's selection and a Service Catalog TagOptions set can all key off tags, so tags decide which resources a control covers.
Authorization — attribute-based access control compares aws:ResourceTag or aws:PrincipalTag in a policy condition; that machinery belongs to Domain 4 and is taught in policy evaluation.
Consistency — a tag policy standardises the shape of a tag: the exact capitalization of the key and the set of allowed values, with non-compliant resources reported and enforcement available per resource type.
And the trap: a tag policy does not require a tag to be present. "Every resource must carry a CostCenter tag at creation" is an IAM or SCP condition on aws:RequestTag/CostCenter, denying the create call when the tag is missing. Tag policy fixes environment versus Environment; a deny condition makes tagging mandatory.
Interactive sorting exercise: Which central mechanism enforces each requirement?
Key terms: AWS Firewall Manager, Firewall Manager policy, Organization Config rule, Tag policy, Conformance pack
Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.