Architecture overview - Automations for AWS Firewall Manager

Architecture overview

This section provides the reference implementation architecture diagrams for the components deployed with this solution.

Architecture diagram (Primary stack)

Deploying this solution's Primary stack with the default parameters deploys the following components in your AWS account.

Architecture diagram. Descriptive text follows.

Automations for AWS Firewall Manager solution Primary stack architecture

Note

AWS CloudFormation resources are created from AWS Cloud Development Kit (AWS CDK) constructs.

The architecture can be grouped into two separate workflows: policy manager and compliance report generator.

Policy manager

When the aws-fms-automations CloudFormation template deploys, an AWS Systems Manager Parameter Store containing three parameters is created, each with default values. The parameters that are created include /FMS/OUs, /FMS/Regions, and /FMS/Tags.

The high-level process flow for the solution components deployed with the CloudFormation template is as follows:

  1. You can update these parameters using Systems Manager:

    • For the /FMS/OUs parameter, add organizational unit IDs to apply policies and rule sets to multiple OUs.

    • For the /FMS/Regions parameter, specify AWS Region names.

    • For the /FMS/Tags parameter, create inclusion and exclusion tags and add tags to specific resources within accounts to indicate resources for which policies and rule sets should be applied or not applied respectively. For information about setting up Parameter Store parameters, refer to Scenarios for setting up the Systems Manager parameters.

  2. An Amazon EventBridge rule uses an event pattern to capture the Systems Manager parameter update event.

  3. An EventBridge rule invokes an AWS Lambda function.

  4. The Lambda function installs a set of predefined Firewall Manager security policies across the user-specified OUs. The policies include an AWS WAF web access control list (ACL) consisting of AWS-managed rule sets and Amazon VPC security group audit policies. Additionally, if you have a subscription to Shield Advanced, this solution deploys policies to protect eligible resources with Shield.

  5. The PolicyManager Lambda function fetches the policy manifest file from the Amazon Simple Storage Service (Amazon S3) bucket and uses the manifest file to create Firewall Manager security policies.

  6. Lambda saves policies metadata in the Amazon DynamoDB table.

For a complete list of policies and rule sets that are installed, refer to the List of policies and rule sets.

Compliance report generator

When the CloudFormation stack deploys, it creates a time-based EventBridge rule, a Lambda function, an Amazon Simple Notification Service (Amazon SNS) topic, and an S3 bucket.

The high-level process flow for the solution components deployed with the CloudFormation template is as follows:

  1. A time-based EventBridge rule invokes the ComplianceGenerator Lambda function.

  2. The ComplianceGenerator Lambda function fetches Firewall Manager policies in each Region and publishes the list of policy IDs in the Amazon SNS topic.

  3. The Amazon SNS topic invokes the ComplianceGenerator Lambda function with the payload {PolicyId: string, Region: string}.

  4. The ComplianceGenerator Lambda function generates a compliance report for each of the policies and uploads the report in CSV format in an S3 bucket.

Architecture diagram (with automations for Shield Advanced)

Deploying all of the solution's stacks with the default parameters deploys the following components in your AWS account.

Architecture diagram, described in the text that follows.

Automations for AWS Firewall Manager solution architecture with Shield Advanced Automations

Automations for AWS Firewall Manager solution architecture with Shield Advanced Automations

The high-level process flow for the automations for Shield Advanced feature of the solution includes workflows for both the policy manager and automated health-based detection.

Policy manager

  1. (Optional) Update the Parameter Store parameters created by the aws-fms-automations template with your desired values. The parameters that are created include /FMS/OUs, /FMS/Regions, and /FMS/Tags.

    Note

    If you have already set up Shield Advanced protections for your AWS resources, you can skip this step.

  2. The stack follows steps 2-5 for the Policy manager in the Architecture diagram (Primary stack) section to create Firewall Manager security policies. This includes Shield Advanced policies for Shield Advanced customers.

Automated health-based detection

When the aws-fms-shield-automations template is deployed, the stack creates an organization AWS Config rule, two Lambda functions, and an Amazon Simple Queue Service (Amazon SQS) queue in the account where the template is deployed.

  1. After deployment, the automated health-based detection workflow runs automatically. The organization AWS Config rule captures existing Shield Advanced protections across your AWS Organization. You can create these Shield Advanced protections automatically through the Firewall Manager security policies deployed by this solution, or manually using the Shield console. The following are all Shield Advanced-protected resource types supported for automated health-based detection:

    1. Amazon Elastic Compute Cloud (Amazon EC2) Elastic IP addresses (with attachments to EC2 instances or Network Load Balancers)

    2. Application Load Balancers

    3. Classic Load Balancers

    4. Network Load Balancers

    5. CloudFront distributions

    Shield Advanced doesn't create protections for Network Load Balancers directly. To protect a Network Load Balancer, you must first attach the Network Load Balancer to an Elastic IP address, and create a protection for that Elastic IP address instead. For more information, see List of resources that AWS Shield Advanced protects.

    Important

    The network interface used to attach a Network Load Balancer to an Elastic IP address must have the following in its description for automated health-based detection to create an Amazon Route 53 health check for the resource: net/network-load-balancer-name/network-load-balancer-resource-id. This is the default description when Network Load Balancers are attached to an Elastic IP address.

  2. Shield Advanced protections captured by the organization Config rule are sent to the ConfigRuleEval Lambda function for evaluation. This Lambda function determines whether or not the protection has Route 53 health checks associated with it.

  3. If there are no Route 53 health checks associated with the Shield Advanced protection, the solution publishes a message to the Amazon SQS queue requesting that health checks be created for the protection.

  4. The ConfigRuleRemediate Lambda function reads messages from the Amazon SQS queue.

  5. The ConfigRuleRemediate Lambda function creates a calculated Route 53 health check based on the type of resource that the Shield Advanced protection protects.

  6. The ConfigRuleRemediate Lambda function associates the Route 53 health check created in step 10 with the Shield Advanced protection being evaluated.

This flow runs continuously for all accounts in your AWS Organization that aren't excluded during CloudFormation template deployment. You can exclude accounts by providing a comma delimited list for the Excluded Accounts parameter when deploying the Shield Advanced Automations stack.

Note

You are responsible for maintaining the Route 53 health checks created by the solution for your Shield Advanced protections. Ensure that you keep the health checks up-to-date with the resources that they are monitoring. For more information, see Health-based detection using health checks with Shield Advanced and Route 53.