How to automate rule management for AWS Network Firewall
AWS Network Firewall is a stateful managed network firewall and intrusion detection and prevention service designed for the Amazon Virtual Private Cloud (Amazon VPC). This post concentrates on automating rule updates in a central Network Firewall by using distributed firewall configurations. If you’re new to Network Firewall or seeking a technical background on rule management, see AWS Network Firewall – New Managed Firewall Service in VPC.
<p>Network Firewall offers three <a href="https://aws.amazon.com/blogs/networking-and-content-delivery/deployment-models-for-aws-network-firewall/" target="_blank" rel="noopener">deployment models</a>: Distributed, centralized, and combined. Many customers opt for a centralized model to reduce costs. In this model, customers allocate the responsibility for managing the rulesets to the owners of the VPC infrastructure (spoke accounts) being protected, thereby shifting accountability and providing flexibility to the spoke accounts. Managing rulesets in a shared firewall policy generated from distributed input configurations of protected VPCs (spoke accounts) is challenging without proper input validation, state-management, and request throttling controls.</p>
<p>In this post, we show you how to automate firewall rule management within the central firewall using distributed firewall configurations spread across multiple AWS accounts. The <a href="https://github.com/awslabs/anfw-automate" target="_blank" rel="noopener">anfw-automate</a> solution provides input-validation, state-management, and throttling controls, reducing the update time for firewall rule changes from minutes to seconds. Additionally, the solution reduces operational costs, including rule management overhead while integrating seamlessly with the existing continuous integration and continuous delivery (CI/CD) processes.</p>
<h2>Prerequisites</h2>
<p>For this walkthrough, the following prerequisites must be met:</p>
<ul>
<li>Basic knowledge of networking concepts such as routing and Classless Inter-Domain Routing (CIDR) range allocations.</li>
<li>Basic knowledge of YAML and JSON configuration formats, definitions, and schema.</li>
<li>Basic knowledge of <a href="https://suricata.readthedocs.io/en/suricata-6.0.0/rules/intro.html" target="_blank" rel="noopener">Suricata Rule Format</a> and <a href="https://docs.aws.amazon.com/network-firewall/latest/developerguide/rule-groups.html" target="_blank" rel="noopener">Network Firewall rule management</a>.</li>
<li>Basic knowledge of CDK deployment.</li>
<li><a href="https://aws.amazon.com/iam/" target="_blank" rel="noopener">AWS Identity and Access Management (IAM)</a> permissions to bootstrap the AWS accounts using <a href="https://aws.amazon.com/getting-started/guides/setup-cdk/module-two/" target="_blank" rel="noopener">AWS Cloud Development Kit (AWS CDK)</a>.</li>
<li>The firewall VPC in the central account must be reachable from a spoke account (<a href="https://aws.amazon.com/blogs/networking-and-content-delivery/deployment-models-for-aws-network-firewall/" target="_blank" rel="noopener">see centralized deployment model</a>). For this solution, you need two AWS accounts from the centralized deployment model:
<ul>
<li>The <em>spoke account</em> is the consumer account the defines firewall rules for the account and uses central firewall endpoints for traffic filtering. At least one spoke account is required to simulate the user workflow in validation phase.</li>
<li>The <em>central account</em> is an account that contains the firewall endpoints. This account is used by application and the Network Firewall.</li>
</ul> </li>
<li>StackSets deployment with service-managed permissions must be enabled in <a href="https://aws.amazon.com/organizations/" target="_blank" rel="noopener">AWS Organizations</a> (<a href="https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-orgs-enable-trusted-access.html" target="_blank" rel="noopener">Activate trusted access with AWS Organizations</a>). <a href="https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-orgs-delegated-admin.html" target="_blank" rel="noopener">A delegated administrator account</a> is required to deploy <a href="https://aws.amazon.com/cloudformation" target="_blank" rel="noopener">AWS CloudFormation</a> stacks in any account in an organization. The CloudFormation StackSets in this account deploy the necessary CloudFormation stacks in the spoke accounts. If you don’t have a delegated administrator account, you must manually deploy the resources in the spoke account. Manual deployment isn’t recommended in production environments.</li>
<li>A <em>resource account</em> is the CI/CD account used to deploy necessary <a href="https://aws.amazon.com/codepipeline" target="_blank" rel="noopener">AWS CodePipeline</a> stacks. The pipelines deploy relevant cross-account cross-AWS Region stacks to the preceding AWS accounts.
<ul>
<li>IAM permissions to deploy CDK stacks in the resource account.</li>
</ul> </li>
</ul>
<h2>Solution description</h2>
<p>In Network Firewall, each firewall endpoint connects to one firewall policy, which defines network traffic monitoring and filtering behavior. The details of the behavior are defined in rule groups — a reusable set of rules — for inspecting and handling network traffic. The rules in the rule groups provide the details for packet inspection and specify the actions to take when a packet matches the inspection criteria. Network Firewall uses a <a href="https://docs.suricata.io/en/latest/what-is-suricata.html" target="_blank" rel="noopener">Suricata rules engine</a> to process all stateful rules. Currently, you can create Suricata compatible or basic rules (such as domain list) in Network Firewall. We use Suricata compatible rule strings within this post to maintain maximum compatibility with most use cases.</p>
<p>Figure 1 describes how the anfw-automate solution uses the distributed firewall rule configurations to simplify rule management for multiple teams. The rules are validated, transformed, and stored in the central AWS Network Firewall policy. This solution isolates the rule generation to the spoke AWS accounts, but still uses a shared firewall policy and a central ANFW for traffic filtering. This approach grants the AWS spoke account owners the flexibility to manage their own firewall rules while maintaining the accountability for their rules in the firewall policy. The solution enables the central security team to validate and override user defined firewall rules before pushing them to the production firewall policy. The security team operating the central firewall can also define additional rules that are applied to all spoke accounts, thereby enforcing organization-wide security policies. The firewall rules are then compiled and applied to Network Firewall in seconds, providing near real-time response in scenarios involving critical security incidents.</p>
<div id="attachment_33412" class="wp-caption aligncenter">
<img aria-describedby="caption-attachment-33412" src="https://infracom.com.sg/wp-content/uploads/2024/02/img1.jpg" alt="Figure 1: Workflow launched by uploading a configuration file to the configuration (config) bucket" width="780" class="size-full wp-image-33412">
<p id="caption-attachment-33412" class="wp-caption-text">Figure 1: Workflow launched by uploading a configuration file to the configuration (config) bucket</p>
</div>
<p>The Network Firewall firewall endpoints and anfw-automate solution are both deployed in the central account. The spoke accounts use the application for rule automation and the Network Firewall for traffic inspection.</p>
<p>As shown in Figure 1, each spoke account contains the following:</p>
<ol>
<li>An <a href="https://aws.amazon.com/s3" target="_blank" rel="noopener">Amazon Simple Storage Service (Amazon S3)</a> bucket to store multiple configuration files, one per Region. The rules defined in the configuration files are applicable to the VPC traffic in the spoke account. The configuration files must comply with the defined naming convention (<span>$Region-config.yaml</span>) and be validated to make sure that only one configuration file exists per Region per account. The S3 bucket has event notifications enabled that publish all changes to configuration files to a local default bus in <a href="https://aws.amazon.com/eventbridge" target="_blank" rel="noopener">Amazon EventBridge</a>.</li>
<li>EventBridge rules to monitor the default bus and forward relevant events to the custom event bus in the central account. The EventBridge rules specifically monitor <span>VPCDelete</span> events published by Amazon CloudTrail and S3 event notifications. When a VPC is deleted from the spoke account, the <span>VPCDelete</span> events lead to the removal of corresponding rules from the firewall policy. Additionally, all create, update, and delete events from Amazon S3 event notifications invoke corresponding actions on the firewall policy.</li>
<li>Two <a href="https://aws.amazon.com/iam/" target="_blank" rel="noopener">AWS Identity and Access Manager (IAM)</a> roles with keywords <span>xaccount.lmb.rc</span> and <span>xaccount.lmb.re</span> are assumed by <span>RuleCollect</span> and <span>RuleExecute</span> functions in the central account, respectively.</li>
<li>A CloudWatch Logs log group to store event processing logs published by the central <a href="https://aws.amazon.com/lambda" target="_blank" rel="noopener">AWS Lambda</a> application.</li>
</ol>
<p>In the central account:</p>
<ol start="5">
<li>EventBridge rules monitor the custom event bus and invoke a Lambda function called <span>RuleCollect</span>. A dead-letter queue is attached to the EventBridge rules to store events that failed to invoke the Lambda function.</li>
<li>The <span>RuleCollect</span> function retrieves the config file from the spoke account by assuming a cross-account role. This role is deployed by the same stack that created the other spoke account resources. The Lambda function validates the request, transforms the request to the Suricata rule syntax, and publishes the rules to an <a href="https://aws.amazon.com/sqs" target="_blank" rel="noopener">Amazon Simple Queue Service (Amazon SQS)</a> first-in-first-out (FIFO) queue. Input validation controls are paramount to make sure that users don’t abuse the functionality of the solution and bypass central governance controls. The Lambda function has input validation controls to verify the following:
<ul>
<li>The VPC ID in the configuration file exists in the configured Region and the same AWS account as the S3 bucket.</li>
<li>The Amazon S3 object version ID received in the event matches the latest version ID to mitigate race conditions.</li>
<li>Users don’t have only top-level domains (for example, .com, .de) in the rules.</li>
<li>The custom Suricata rules don’t have <em>any</em> as the destination IP address or domain.</li>
<li>The VPC identifier matches the required format, that is, <span>a+(AWS Account ID)+(VPC ID without vpc- prefix)</span> in custom rules. This is important to have unique rule variables in rule groups.</li>
<li>The rules don’t use security sensitive keywords such as <em>sid</em>, <em>priority</em>, or <em>metadata</em>. These keywords are reserved for firewall administrators and the Lambda application.</li>
<li>The configured VPC is attached to an <a href="https://aws.amazon.com/transit-gateway" target="_blank" rel="noopener">AWS Transit Gateway</a>.</li>
<li>Only pass rules exist in the rule configuration.</li>
<li>CIDR ranges for a VPC are mapped appropriately using IP set variables.</li>
</ul> <p>The input validations make sure that rules defined by one spoke account don’t impact the rules from other spoke accounts. The validations applied to the firewall rules can be updated and managed as needed based on your requirements. The rules created must follow a strict format, and deviation from the preceding rules will lead to the rejection of the request.</p> </li>
<li>The Amazon SQS FIFO queue preserves the order of create, update, and delete operations run in the configuration bucket of the spoke account. These state-management controls maintain consistency between the firewall rules in the configuration file within the S3 bucket and the rules in the firewall policy. If the sequence of updates provided by the distributed configurations isn’t honored, the rules in a firewall policy might not match the expected ruleset. <p>Rules not processed beyond the <a href="https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SetQueueAttributes.html" target="_blank" rel="noopener">maxReceiveCount</a> threshold are moved to a dead-letter SQS queue for troubleshooting.</p> </li>
<li>The Amazon SQS messages are subsequently consumed by another Lambda function called <span>RuleExecute</span>. Multiple changes to one configuration are batched together in one message. The <span>RuleExecute</span> function parses the messages and generates the required rule groups, IP set variables, and rules within the Network Firewall. Additionally, the Lambda function establishes a reserved rule group, which can be administered by the solution’s administrators and used to define global rules. The global rules, applicable to participating AWS accounts, can be managed in the <a href="https://github.com/awslabs/anfw-automate/blob/main/app/data/defaultdeny.yaml" target="_blank" rel="noopener">data/defaultdeny.yaml</a> file by the central security team. <p>The <span>RuleExecute</span> function also implements throttling controls to make sure that rules are applied to the firewall policy without reaching the <span>ThrottlingException</span> from Network Firewall (<a href="https://docs.aws.amazon.com/network-firewall/latest/APIReference/CommonErrors.html" target="_blank" rel="noopener">see common errors</a>). The function also implements back-off logic to handle this exception. This throttling effect can happen if there are too many requests issued to the Network Firewall API.</p> <p>The function makes cross-Region calls to Network Firewall based on the Region provided in the user configuration. There is no need to deploy the <span>RuleExecute</span> and <span>RuleCollect</span> Lambda functions in multiple Regions unless a use case warrants it.</p> </li>
</ol>
<h2>Walkthrough</h2>
<p>The following section guides you through the deployment of the rules management engine.</p>
<ul>
<li>Deployment: Outlines the steps to deploy the solution into the target AWS accounts.</li>
<li>Validation: Describes the steps to validate the deployment and ensure the functionality of the solution.</li>
<li>Cleaning up: Provides instructions for cleaning up the deployment.</li>
</ul>
<h3>Deployment</h3>
<p>In this phase, you deploy the application pipeline in the resource account. The pipeline is responsible for deploying multi-Region cross-account CDK stacks in both the central account and the delegated administrator account.</p>
<p>If you don’t have a functioning Network Firewall firewall using the centralized deployment model in the central account, see the <a href="https://github.com/awslabs/anfw-automate" target="_blank" rel="noopener">README</a> for instructions on deploying Amazon VPC and Network Firewall stacks before proceeding. You need to deploy the Network Firewall in centralized deployment in each Region and Availability Zone used by spoke account VPC infrastructure.</p>
<p>The <em>application pipeline stack</em> deploys three stacks in all configured Regions: LambdaStack and ServerlessStack in the central account and StacksetStack in the delegated administrator account. It’s recommended to deploy these stacks solely in the primary Region, given that the solution can effectively manage firewall policies across all supported Regions.</p>
<ul>
<li><strong>LambdaStack</strong> deploys the <span>RuleCollect</span> and <span>RuleExecute</span> Lambda functions, Amazon SQS FIFO queue, and SQS FIFO dead-letter queue.</li>
<li><strong>ServerlessStack</strong> deploys EventBridge bus, EventBridge rules, and EventBridge Dead-letter queue.</li>
<li><strong>StacksetStack</strong> deploys a service-managed stack set in the delegated administrator account. The stack set includes the deployment of IAM roles, EventBridge rules, an S3 Bucket, and a CloudWatch log group in the spoke account. If you’re manually deploying the CloudFormation template (<span>templates/spoke-serverless-stack.yaml</span>) in the spoke account, you have the option to disable this stack in the application configuration.<br>
<div id="attachment_33413" class="wp-caption aligncenter">
<img aria-describedby="caption-attachment-33413" src="https://infracom.com.sg/wp-content/uploads/2024/02/img2.jpg" alt="Figure 2: CloudFormation stacks deployed by the application pipeline" width="740" class="size-full wp-image-33413">
<p id="caption-attachment-33413" class="wp-caption-text">Figure 2: CloudFormation stacks deployed by the application pipeline</p>
</div> </li>
</ul>
<h4>To prepare for bootstrapping</h4>
<ol>
<li><a href="https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html" target="_blank" rel="noopener">Install</a> and <a href="https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html#cli-configure-files-using-profiles" target="_blank" rel="noopener">configure</a> profiles for all AWS accounts using <a href="https://aws.amazon.com/cli" target="_blank" rel="noopener">Amazon Command Line Interface (AWS CLI)</a></li>
<li><a href="https://docs.aws.amazon.com/cdk/v2/guide/getting_started.html" target="_blank" rel="noopener">Install</a> the Cloud Development Kit (CDK)</li>
<li><a href="https://git-scm.com/book/en/v2/Getting-Started-Installing-Git" target="_blank" rel="noopener">Install</a> Git and clone the <a href="https://github.com/awslabs/anfw-automate" target="_blank" rel="noopener">GitHub repo</a></li>
<li><a href="https://docs.docker.com/desktop/" target="_blank" rel="noopener">Install</a> and enable Docker Desktop</li>
</ol>
<h4>To prepare for deployment</h4>
<ol>
<li>Follow the <a href="https://github.com/awslabs/anfw-automate" target="_blank" rel="noopener">README</a> and <a href="https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping.html" target="_blank" rel="noopener">cdk bootstrapping guide</a> to bootstrap the resource account. Then, bootstrap the central account and delegated administrator account (optional if StacksetStack is deployed manually in the spoke account) to trust the resource account. The spoke accounts don’t need to be bootstrapped.</li>
<li>Create a folder to be referred to as <span></span>, where <span>STAGE</span> is the name of your deployment stage — for example, <span>local</span>, <span>dev</span>, <span>int</span>, and so on — in the <span>conf</span> folder of the cloned repository. The deployment stage is set as the <span>STAGE</span> parameter later and used in the AWS resource names.</li>
<li>Create <span>global.json</span> in the <span></span> folder. Follow the <a href="https://github.com/awslabs/anfw-automate" target="_blank" rel="noopener">README</a> to update the parameter values. A sample JSON file is provided in <a href="https://github.com/awslabs/anfw-automate/tree/main/conf/sample" target="_blank" rel="noopener">conf/sample</a> folder.</li>
<li>Run the following commands to configure the local environment:
<div class="hide-language">
<pre class="unlimited-height-code"><code class="lang-text">npm install
export STAGE=
export AWS_REGION=
<h4>To deploy the application pipeline stack</h4>
<ol>
<li>Create a file named <span>app.json</span> in the <span></span> folder and populate the parameters in accordance with the README section and defined schema.</li>
<li>If you choose to manage the deployment of spoke account stacks using the delegated administrator account and have set the <span>deploy_stacksets</span> parameter to <span>true</span>, create a file named <span>stackset.json</span> in the <span></span> folder. Follow the <a href="https://github.com/awslabs/anfw-automate" target="_blank" rel="noopener">README</a> section to align with the requirements of the defined schema. You can also deploy the spoke account stack manually for testing using the AWS CloudFormation template in <span>templates/spoke-serverless-stack.yaml</span>. This will create and configure the needed spoke account resources.</p> </li>
<li>Run the following commands to deploy the application pipeline stack:
<div class="hide-language">
<pre class="unlimited-height-code"><code>export STACKNAME=app && make deploy</code></pre>
</div>
<div id="attachment_33414" class="wp-caption aligncenter">
<img aria-describedby="caption-attachment-33414" src="https://infracom.com.sg/wp-content/uploads/2024/02/img3.jpg" alt="Figure 3: Example output of application pipeline deployment" width="740" class="size-full wp-image-33414" />
<p id="caption-attachment-33414" class="wp-caption-text">Figure 3: Example output of application pipeline deployment</p>
</div> </li>
</ol>
<p>After deploying the solution, each spoke account is required to configure stateful rules for every VPC in the configuration file and upload it to the S3 bucket. Each spoke account owner must verify the VPC’s connection to the firewall using the centralized deployment model. The configuration, presented in the YAML configuration language, might encompass multiple rule definitions. Each account must furnish one configuration file per VPC to establish accountability and non-repudiation.</p>
<h3>Validation</h3>
<p>Now that you’ve deployed the solution, follow the next steps to verify that it’s completed as expected, and then test the application.</p>
<h4>To validate deployment</h4>
<ol>
<li>Sign in to the AWS Management Console using the resource account and go to CodePipeline.</li>
<li>Verify the existence of a pipeline named <span>cpp-app----</span> in the configured Region.</li>
<li>Verify that stages exist in each pipeline for all configured Regions.</li>
<li>Confirm that all pipeline stages exist. The LambdaStack and ServerlessStack stages must exist in the <span>cpp-app----</span> stack. The StacksetStack stage must exist if you set the <span>deploy_stacksets</span> parameter to true in <span>global.json</span>.</li>
</ol>
<h4>To validate the application</h4>
<ol>
<li>Sign in and open the Amazon S3 console using the spoke account.</li>
<li>Follow the schema defined in <a href="https://github.com/awslabs/anfw-automate/blob/main/app/RuleCollect/schema.json" target="_blank" rel="noopener">app/RuleCollect/schema.json</a> and create a file with naming convention <span>${Region}-config.yaml</span>. Note that the Region in the config file is the destination Region for the firewall rules. Verify that the file has valid VPC data and rules.
<div id="attachment_33415" class="wp-caption aligncenter">
<img aria-describedby="caption-attachment-33415" src="https://infracom.com.sg/wp-content/uploads/2024/02/img4.jpg" alt="Figure 4: Example configuration file for eu-west-1 Region" width="740" class="size-full wp-image-33415" />
<p id="caption-attachment-33415" class="wp-caption-text">Figure 4: Example configuration file for eu-west-1 Region</p>
</div> </li>
<li>Upload the newly created config file to the S3 bucket named <span>anfw-allowlist---</span>.</li>
<li>If the data in the config file is invalid, you will see ERROR and WARN logs in the CloudWatch log group named <span>cw----CustomerLog-</span>.</li>
<li>If all the data in the config file is valid, you will see INFO logs in the same CloudWatch log group.
<div id="attachment_33416" class="wp-caption aligncenter">
<img aria-describedby="caption-attachment-33416" src="https://infracom.com.sg/wp-content/uploads/2024/02/img5.jpg" alt="Figure 5: Example of logs generated by the anfw-automate in a spoke account" width="740" class="size-full wp-image-33416" />
<p id="caption-attachment-33416" class="wp-caption-text">Figure 5: Example of logs generated by the anfw-automate in a spoke account</p>
</div> </li>
<li>After the successful processing of the rules, sign in to the Network Firewall console using the central account.</li>
<li>Navigate to the Network Firewall rule groups and search for a rule group with a randomly assigned numeric name. This rule group will contain your Suricata rules after the transformation process.
<div id="attachment_33417" class="wp-caption aligncenter">
<img aria-describedby="caption-attachment-33417" src="https://infracom.com.sg/wp-content/uploads/2024/02/img6.jpg" alt="Figure 6: Rules created in Network Firewall rule group based on the configuration file in Figure 4" width="740" class="size-full wp-image-33417" />
<p id="caption-attachment-33417" class="wp-caption-text">Figure 6: Rules created in Network Firewall rule group based on the configuration file in Figure 4</p>
</div> </li>
<li>Access the Network Firewall rule group identified by the suffix <em>reserved</em>. This rule group is designated for administrators and global rules. Confirm that the rules specified in <a href="https://github.com/awslabs/anfw-automate/blob/main/app/data/defaultdeny.yaml" target="_blank" rel="noopener">app/data/defaultdeny.yaml</a> have been transformed into Suricata rules and are correctly placed within this rule group.</li>
<li>Instantiate an EC2 instance in the VPC specified in the configuration file and try to access both the destinations allowed in the file and any destination not listed. Note that requests to destinations not defined in the configuration file are blocked.</li>
</ol>
<h3>Cleaning up</h3>
<p>To avoid incurring future charges, remove all stacks and instances used in this walkthrough.</p>
<ol>
<li>Sign in to both the central account and the delegated admin account. Manually delete the stacks in the Regions configured for the app parameter in <span>global.json</span>. Ensure that the stacks are deleted for all Regions specified for the app parameter. You can filter the stack names using the keyword <span>--</span> as defined in <span>global.json</span>.</li>
<li>After deleting the stacks, remove the pipeline stacks using the same command as during deployment, replacing <span>cdk deploy</span> with <span>cdk destroy</span>.</li>
<li>Terminate or stop the EC2 instance used to test the application.</li>
</ol>
<h2>Conclusion</h2>
<p>This solution simplifies network security by combining distributed ANFW firewall configurations in a centralized policy. Automated rule management can help reduce operational overhead, reduces firewall change request completion times from minutes to seconds, offloads security and operational mechanisms such as input validation, state-management, and request throttling, and enables central security teams to enforce global firewall rules without compromising on the flexibility of user-defined rulesets.</p>
<p>In addition to using this application through S3 bucket configuration management, you can <a href="https://aws.amazon.com/blogs/devops/integrating-with-github-actions-ci-cd-pipeline-to-deploy-a-web-app-to-amazon-ec2/" target="_blank" rel="noopener">integrate this tool with GitHub Actions into your CI/CD pipeline</a> to upload the firewall rule configuration to an S3 bucket. By combining GitHub actions, you can automate configuration file updates with automated release pipeline checks, such as schema validation and manual approvals. This enables your team to maintain and change firewall rule definitions within your existing CI/CD processes and tools. You can go further by allowing access to the S3 bucket only through the CI/CD pipeline.</p>
<p>Finally, you can ingest the AWS Network Firewall logs into one of our <a href="https://aws.amazon.com/network-firewall/partners/" target="_blank" rel="noopener">partner solutions</a> for security information and event management (SIEM), security monitoring, threat intelligence, and managed detection and response (MDR). You can launch automatic rule updates based on security events detected by these solutions, which can help reduce the response time for security events.</p>
<p> <br />If you have feedback about this post, submit comments in the<strong> Comments</strong> section below. If you have questions about this post, <a href="https://console.aws.amazon.com/support/home" target="_blank" rel="noopener noreferrer">contact AWS Support</a>.
<!-- '"` -->