Check web-tier subnet connectivity to VPC NAT Gateway

01 Sign in to your Cloud Conformity console, access Check web-tier subnet connectivity to VPC NAT Gateway conformity rule settings, identify and copy the tag set defined for all AWS resources available within your web tier (e.g. <web_tier_tag>:<web_tier_tag_value>).

02 Sign in to the AWS Management Console.

03 Navigate to VPC dashboard at https://console.aws.amazon.com/vpc/.

04 Select the Virtual Private Cloud (VPC) that you want to examine from the Select a VPC dropdown menu.

05 In the navigation panel, under Virtual Private Cloud, click Subnets.

06 Select the VPC subnet that you want to examine.

07 Select the Tags tab from the dashboard bottom panel.

08 On the Tags panel, search for the tag set identified at step no. 1 (i.e. <web_tier_tag>:<web_tier_tag_value>). If these two tag sets do not match, or the verified resource is not tagged at all, the selected subnet is not a component of your web tier and the audit process ends here. If the tag sets match, continue the audit with the next step.

09 Select the Route Table tab from the dashboard bottom panel to access the routes configured for the selected web-tier subnet.

10 Verify the existing routes to determine if these contain the default route (i.e. the route with Destination set to 0.0.0.0/0) pointing to a NAT Gateway (e.g. nat-01234567890123456). If there is no such route defined, the selected route table configuration is not compliant with the conformity rule requirements.

11 Repeat steps no. 6 – 10 to check the rest of the web-tier subnets for compliant route tables. If none of the verified route tables have the default route linked to a NAT Gateway, the EC2 instances provisioned within the selected web-tier do not have Internet access via an AWS NAT Gateway.

12 If required, change the AWS region from the navigation bar and repeat steps no. 4 – 11 for other regions.

01 Sign in to your Cloud Conformity console, access Check web-tier subnet connectivity to VPC NAT Gateway conformity rule settings, identify and copy the tag set defined for all AWS resources available in your web tier (e.g. <web_tier_tag>:<web_tier_tag_value>).

02 Run describe-subnets command (OSX/Linux/UNIX) to list the IDs of the subnets associated with your web tier, available in the selected VPC, created within US East (N. Virginia) region:

aws ec2 describe-subnets
	--region us-east-1
	--filters Name=tag:<web_tier_tag>,Values=<web_tier_tag_value> Name=vpc-id,Values=vpc-1234abcd
	--query "Subnets[*].SubnetId"

03 The command request should return one of the following outputs:

1. If describe-subnets command output returns an empty array (i.e. []), as shown in the example below, there are no VPC subnets created for your web tier in the selected AWS region, therefore the audit process ends here:
   []
   

2. If the command output returns an array with subnet IDs, as shown in the example below, one or more web-tier subnets are available within the selected Virtual Private Cloud (VPC), therefore the audit process continues with the next step:
   [
       "subnet-aaaabbbb",
       "subnet-ccccdddd"
   ]
   

04 Run describe-route-tables command (OSX/Linux/UNIX) to describe the routes configured for the route table associated with the web-tier subnets returned at the previous step, available in the selected AWS region:

aws ec2 describe-route-tables
	--region us-east-1
	--filters Name=association.subnet-id,Values=subnet-aaaabbbb,subnet-ccccdddd
	--query "RouteTables[*].{RouteTableId:RouteTableId, Routes:Routes}"

05 The command output should return the existing route(s) for the associated route table:

[
    {
        "Routes": [
            {
                "GatewayId": "local",
                "DestinationCidrBlock": "10.0.0.0/16",
                "State": "active",
                "Origin": "CreateRouteTable"
            }
        ],
        "RouteTableId": "rtb-12345678"
    }
]

06 If required, change the AWS region by updating the --region command parameter value and repeat steps no. 2 – 5 for other regions.

01 Sign in to the AWS Management Console.

02 Navigate to VPC dashboard at https://console.aws.amazon.com/vpc/.

03 From Select a VPC dropdown menu, select the Virtual Private Cloud where the web-tier subnets were deployed.

04 In the navigation panel, under Virtual Private Cloud, click Route Tables.

05 Select the route table that you want to reconfigure (see Audit section part I to identify the right VPC resource).

06 Select the Routes tab from the bottom panel to access the table routing configuration.

07 On the Routes panel, choose Edit, then click Add another rule button add a new route.

08 Type 0.0.0.0/0 in the Destination box then click inside the Target box and select the ID of the NAT Gateway (e.g. nat-01234567890123456) created for the current VPC. If there is no AWS NAT Gateway deployed within the selected VPC, follow the instructions outlined in this conformity rule to create one.

09 Click Save to create the route and apply it to the existing route table. The new route matches all traffic (i.e. 0.0.0.0/0) and routes it to the managed NAT Gateway available in the selected VPC.

10 If required, change the AWS region from the navigation bar and repeat steps no. 3 – 9 for other regions.

01 Run create-route command (OSX/Linux/UNIX) using the ID of the route table that you want to reconfigure (see Audit section part II to identify the right route table) as identifier to create a new route that matches all traffic (i.e. 0.0.0.0/0) and routes the traffic to the NAT Gateway deployed within the Virtual Private Cloud that hosts the web-tier subnets. If there is no AWS NAT Gateway deployed within the selected VPC, follow the instructions outlined in this conformity rule to create one before executing the create-route command:

aws ec2 create-route
	--region us-east-1
	--route-table-id rtb-12345678
	--destination-cidr-block 0.0.0.0/0
	--gateway-id nat-01234567890123456

02 The command output should return true if the request succeeds, otherwise, it should return an error:

{
    "Return": true
}

03 If required, change the AWS region by updating the --region command parameter value and repeat step no. 1 and 2 for other regions.