/shieldadvanced

Aggregating Resources into Protection Groups

Overview

Domain expertise for grouping AWS Shield Advanced protected resources so Shield treats them as one unit for detection. Covers when a group helps (noisy per-resource detection, resources that share traffic patterns), the aggregation choice (sum, mean, max), the membership pattern (all, by resource type, or an explicit list), and the boundary that protection groups are detection-only and do not apply shared mitigation.

Does not cover subscribing and protecting resources, automatic mitigation, health-based detection, SRT setup, or event review; those are separate references.

Execute commands using the AWS MCP server when connected (sandboxed execution, audit logging, observability). Fall back to the AWS CLI otherwise. Shield Advanced control-plane calls run in us-east-1; pass --region us-east-1 on every command.

Table of Contents

• Overview
• Workflow
• Decision: aggregation
• Decision: membership pattern
• Protection groups are detection-only
• Troubleshooting
• Security considerations
• Procedure
• Additional Resources

Workflow

To aggregate resources into a protection group end to end, follow the procedure exactly. See the Procedure section below.

The procedure covers:

• Confirming the member resources are already individually protected
• Choosing the aggregation and the membership pattern
• Creating the protection group
• Surfacing the console link to verify the group

Always tell the customer (state all of these)

When advising on protection groups, you MUST state ALL of the following points together, not a subset:

1. Protection groups are detection and reporting only — they do NOT apply shared mitigation; automatic mitigation still applies per individual resource, never to the group as a whole.
2. Every member must already be individually protected with Shield Advanced before it joins the group — a group built over unprotected resources shows zero members and aggregates nothing.
3. For a multi-tier topology (e.g. CloudFront in front of an Application Load Balancer in front of EC2), use MAX aggregation so one high-traffic tier is not diluted by the others.

The sections below give the detail behind each point.

Decision: aggregation

Constraints:

• You MUST match the aggregation to the customer's topology rather than leaving it as a guess; the wrong choice makes detection too sensitive or too slow
• You SHOULD use sum for many small-traffic resources or for a new resource that needs an existing baseline, mean for uniform-traffic members, and max for a multi-tier application

Decision: membership pattern

Constraints:

• You MUST choose a membership pattern that matches how the customer wants resources grouped
• You SHOULD use an arbitrary list when the customer wants a specific set of related resources (for example a distribution and the load balancer behind it) rather than a whole resource type

Protection groups are detection-only

A protection group changes detection across its members; it does not apply mitigation as a group. Customers expect a group to mitigate the whole set and are surprised when it does not.

Constraints:

• You MUST state that protection groups are for detection and reporting only
• You MUST tell the customer that automatic application layer mitigation still applies to individual resources, not to the group, even when the resources are grouped
• You MUST NOT present a protection group as a shared mitigation control
• You MUST tell the customer that every member resource must already be individually protected with Shield Advanced before it can be in the group: a protection group only aggregates resources that already carry their own protection, so a group built over unprotected resources shows zero members and aggregates nothing. State this membership prerequisite explicitly, not just by implication

Troubleshooting

A protection group shows zero members

The pattern only matches resources that are already individually protected. Protect the resources first, then they fall into the group (Procedure, Step 1).

Grouping did not mitigate an attack across the members

Protection groups are detection-only. Mitigation still applies per resource (Protection groups are detection-only).

Detection is too sensitive or too slow after grouping

The aggregation does not match the topology. Reconsider sum vs mean vs max (Decision: aggregation).

Security considerations

Protection groups change detection across protected resources, so call out the risks and the controls that contain them.

• Removing the Shield rule group silently disables mitigation. A protection group is detection-only and does not apply shared mitigation; automatic application layer mitigation still runs per resource through its ShieldMitigationRuleGroup rule group. Warn against removing that rule group from a web ACL during cleanup, since its removal turns off automatic mitigation for every resource using that web ACL with no obvious signal.
• Least privilege for the operator. Scope the caller's IAM permissions to the minimum this procedure needs (shield:ListProtections, shield:CreateProtectionGroup, shield:ListProtectionGroups) rather than broad Shield or administrator access.
• Audit trail. Keep AWS CloudTrail enabled and logging shield:* calls so every protection-group configuration change leaves a record, and confirm the CloudTrail trail uses SSE-KMS encryption on its S3 log bucket and CloudWatch Logs log group, since CloudTrail records contain sensitive API metadata (caller identities, resource ARNs, parameters).

Procedure

Overview

This procedure creates a protection group over resources that are already individually protected, with the chosen aggregation and membership pattern, then surfaces the console link to verify.

Parameters

• protection_group_id (required): A name for the protection group.
• aggregation (required): SUM, MEAN, or MAX.
• pattern (required): ALL, BY_RESOURCE_TYPE, or ARBITRARY.
• resource_type (required when pattern is BY_RESOURCE_TYPE): The resource type to group. ALL does not take a resource type.
• members (required when pattern is ARBITRARY): The list of resource ARNs to include.

Constraints for parameter acquisition:

• You MUST ask for all required parameters upfront in a single prompt
• You MUST confirm every intended member is already an individual Shield Advanced protection (via list-protections) BEFORE creating the group. A protection group never protects an unprotected resource; if members are not already protected the group is created with zero effective members and silently protects nothing

Steps

1. Verify dependencies

Constraints:

• You MUST confirm credentials with aws sts get-caller-identity

• You SHOULD use temporary credentials from an assumed IAM role (for example via IAM Identity Center or an instance profile) rather than long-lived IAM user access keys for these security-sensitive Shield Advanced operations

• You SHOULD scope the caller's IAM permissions to the minimum this procedure needs (shield:ListProtections, shield:CreateProtectionGroup, shield:ListProtectionGroups) rather than broad Shield or administrator access

• You SHOULD confirm AWS CloudTrail is enabled and logging shield:* calls so every Shield Advanced configuration change leaves an audit trail

• You SHOULD confirm the CloudTrail trail is configured with SSE-KMS encryption on its S3 log bucket and CloudWatch Logs log group, since CloudTrail records contain sensitive API metadata (caller identities, resource ARNs, parameters)

• You MUST confirm the member resources are already protected:

  aws shield list-protections --region us-east-1

2. Create the protection group

Constraints:

• You MUST create the group with the chosen aggregation and pattern. For an ALL pattern (every protected resource regardless of type), do not pass --resource-type:

  aws shield create-protection-group --protection-group-id {protection_group_id} \
    --aggregation {aggregation} --pattern ALL --region us-east-1

• For a BY_RESOURCE_TYPE pattern, you MUST pass the resource type:

  aws shield create-protection-group --protection-group-id {protection_group_id} \
    --aggregation {aggregation} --pattern BY_RESOURCE_TYPE --resource-type {resource_type} --region us-east-1

• For an ARBITRARY pattern, you MUST pass the member ARNs instead of a resource type:

  aws shield create-protection-group --protection-group-id {protection_group_id} \
    --aggregation {aggregation} --pattern ARBITRARY --members '["{member_arn}"]' --region us-east-1

3. Confirm and surface the console link

Constraints:

• You MUST confirm the group was created:

  aws shield list-protection-groups --region us-east-1

• You MUST present the Shield protected-resources console link and tell the customer to open it and confirm the protection group and its members:

  https://us-east-1.console.aws.amazon.com/wafv2/shieldv2#/protections

Example

Example input

{
  "protection_group_id": "edge-and-origin",
  "aggregation": "MAX",
  "pattern": "ARBITRARY",
  "members": [
    "arn:aws:cloudfront::111122223333:distribution/EDFDVBD6EXAMPLE",
    "arn:aws:elasticloadbalancing:us-east-1:111122223333:loadbalancer/app/origin-alb/abc"
  ]
}

Example output

Confirmed both members are individually protected.
Created protection group edge-and-origin with MAX aggregation over the distribution and origin ALB.
Note: this groups detection only — automatic mitigation still applies per resource.
Open the Shield console and confirm the protection group:
https://us-east-1.console.aws.amazon.com/wafv2/shieldv2#/protections

Example input (group every protected Application Load Balancer)

{
  "protection_group_id": "all-albs",
  "aggregation": "MEAN",
  "pattern": "BY_RESOURCE_TYPE",
  "resource_type": "APPLICATION_LOAD_BALANCER"
}

Example output (group every protected Application Load Balancer)

Confirmed protected Application Load Balancers exist.
Created protection group all-albs with MEAN aggregation over every protected ALB.
Note: this groups detection only — automatic mitigation still applies per resource.
Open the Shield console and confirm the protection group:
https://us-east-1.console.aws.amazon.com/wafv2/shieldv2#/protections

Troubleshooting

The group shows zero members

The members are not individually protected. Protect them first (Step 1).

Grouping did not mitigate across members

Protection groups are detection-only (Protection groups are detection-only).

Detection is too sensitive or too slow

Reconsider the aggregation against the topology (Decision: aggregation).

Additional Resources

• Grouping your AWS Shield Advanced protections (AWS WAF, AWS Firewall Manager, and AWS Shield Advanced Developer Guide)
• Adding and configuring resource protections with Shield Advanced (AWS WAF, AWS Firewall Manager, and AWS Shield Advanced Developer Guide)