So far, we have looked at a number of security techniques to help you secure your AWS environment and the data within it. However, many organizations will be connecting to the AWS cloud from their own on-premises environment from within their own data center. As a result, you need to understand the different methods of secure connectivity between your own corporate site and that of the AWS cloud, allowing you to effectively extend your corporate network in a secure manner.

This chapter will look at some of the connectivity options and the security behind them to ensure you can maintain and implement a secure connection from your corporate environment to your AWS environment. We will be looking at the configuration of security options, such as routing and security groups, and the permissions behind connectivity options, such as an AWS Virtual Private Network (VPN) and AWS Direct Connect.

 We will cover the following topics in this chapter:

• Understanding your connection
• Using an AWS VPN
• Using AWS Direct Connect

Technical requirements

To follow along with this chapter, you do not need any software or hardware. However, to get the most out of the information presented, you should have an understanding of the following:

• AWS route tables and basic routing principles (covered in Chapter 7, Configuring Infrastructure Security)
• Security groups (covered in Chapter 7, Configuring Infrastructure Security)
• IAM policies and policy syntax (covered in Chapter 4, Working with Access Policies)

Understanding your connection

If you are an organization building solutions on AWS, then you can easily access your resources and services via the internet, as many of you would have already experienced from using the AWS Management Console. From here, you can configure, deploy, and architect your infrastructure using the multitude of services that AWS offers. From a logical perspective, using the internet to connect to your AWS environment from your on-premises environment would look as follows:

However, you might want to establish a more secure connection to these resources and connect to them as if they were an extension of your own internal network.  To do this effectively and securely, you would need to enforce a private connection between your on-premises environment and AWS. This can be achieved via a couple of different connectivity options:

• By using a VPN connection
• By using a Direct Connect connection

In the following sections of this chapter, we will discuss both of these options in great detail. Let's begin with the VPN option first and the various configurations available to you.

Using an AWS VPN

With an AWS-managed VPN site-to-site connection, a private connection is established between the on-premises site and AWS Virtual Private Cloud (VPC). This connection is established across the internet using two AWS components:

• A Virtual Private Gateway (VPN gateway)
• A customer gateway

As you can see in the following diagram, the VPN gateway is located on the AWS side of your architecture, and the customer gateway is associated with the remote customer location (on-premises):

As this is a managed service, the VPN gateway component, which resides within AWS, is implemented and designed with redundancy in mind and actually consists of two endpoints, each of which is located in different data centers for resiliency (note: this is not depicted in the preceding logical diagram). 

In addition to this, the VPN connection itself consists of two IPsec tunnels. But what is an IPsec tunnel?

IPsec, or Internet Protocol Security, is a secure network protocol suite allowing a cryptographic method of communication between two endpoints, such as between two gateways (creating a network-to-network connection), much like we have in the preceding example with AWS VPNs, or simply between two hosts, creating a host-to-host connection. The IPsec protocol simply outlines the required framework for implementing security at the IP layer, which can include functions such as encryption/decryption, authentication, and key management.

When an end-to-end connection is established between two gateways using a VPN connection with IPsec, the connection is referred to as a tunnel. Within a tunnel, the IPsec protocol wraps the entire data packet being sent, ensuring it’s encrypted, and attaches a new header to the packet before it is sent to the other end of the tunnel.

Once your VPN gateway and customer gateway are configured, you need to configure routing options and security groups to enable communication between the site-to-site connections of VPC and your on-premises corporate network.

Configuring VPN routing options

Once you have created your VPN gateway and customer gateway, you are then in a position where you can begin to add routing configuration to your subnets to allow you to route traffic across to your corporate site via the VPN site-to-site connection. 

Let’s take a look at an example:

As you can see, AWS VPC has a 10.0.1.0/24 subnet within the VPC CIDR block of 10.0.0.0/16. The main route table has a manually added static route pointing to the network address space within the corporate data center on the other side of the VPN connection. You will notice that this route has been added with the destination pointing to our VPN gateway (vgw-wxyz6789). As a result of this route, any traffic destined to this network will go via the VPN gateway. 

A key point of understanding AWS routing in general is the principle of the longest prefix match. Understanding this can really help you troubleshoot routing issues. Longest prefix match determines how routes are prioritized in directing traffic to a target, especially when a route table has overlapping CIDR blocks—how will AWS determine where to send the traffic? Well, AWS will use the destination that has the most precise destination network listed, known as the longest prefix match.

For example, let’s imagine you have the following route table:

From the preceding table, we can understand the following:

• The first route is the local route of the VPC found in every route table.
• The second route points to a target relating to a VPC peering connection.
• The third route points to a VPN gateway, which then connects to a remote location.

If a packet was destined to a host on the 172.16.1.0 network, which target would it use? There are two routes that the route table could send the traffic to—the second and the third route. Both destinations fall into the network of a host on the 172.16.1.0 network. However, the third route has a longer prefix match in its destination field, and as a result, AWS routing would select this route as it’s more precise. 

Now, looking at the same route table, if a packet was destined for a host on the 172.16.2.0 network, there is now only one feasible route—the second one (the peering connection).

When using a VPN gateway, route propagation can be enabled. By enabling route propagation, all other routes to networks represented across your site-to-site VPN connection will be automatically be added within your route table, preventing you from having to manually add them. However, do be aware that should you encounter any overlapping CIDR blocks from propagated routes with static routes, then the static routes will always take precedence, regardless of the longest-prefix match principle between propagated and static routes.

If you don’t use route propagation, then you will simply need to add in your static routes to your remote networks across the other side of the VPN connection.

Configuring your security groups

Once your routing has been configured and you have established a connection between your internal corporate network and AWS VPC, you will still need to configure and update your security groups to allow the required access inbound from your corporate network. 

For example, if you intended to remotely connect to instances running in VPC from your corporate network using protocols such as RDP or SSH, then you need to open up these protocols within the security groups associated with your instances. 

Using this VPC connection is one option of securing connectivity between your corporate infrastructure and AWS, which uses the internet as the underlying backbone of your connection. Now, let's take a look at AWS Direct Connection, which uses private infrastructure instead.

Using AWS Direct Connect

Similar to an AWS VPN connection, Direct Connect is another method of extending your own infrastructure and joining it to your AWS architecture as if it were a single network. However, with Direct Connect, you do not use a public network to initiate the connection. Instead, your connection runs across a private network via an AWS Direct Connect location. 

These AWS Direct Connect locations are data centers where your own network and the network of AWS physically connect to each other via cross-connects using a standard fiber-optic cable between your router and an AWS Direct Connect router. These data centers are managed by AWS Direct Connect partners. 

Let’s look at a diagram to help explain how this connection is established at a high level:

As you can see, there are three distinct locations involved to establish a link using AWS Direct Connect:

• Your corporate site where your own private network resides
• An AWS Direct Connect location (typically owned by an AWS partner)
• An AWS VPC within a specific AWS region

I have also highlighted two network segments. The network infrastructure highlighted by the dashed line on the right is managed by your organization and any of your associated network partners. You are responsible for implementing and managing the physical network infrastructure within this area. On the other hand, the physical network infrastructure highlighted by the dashed line on the left side is the responsibility of AWS.

With this segregation of physical network architecture, there are a number of networking prerequisites that need to be met prior to configuring and establishing a Direct Connect connection. From a network point of view, your network must meet at least one of the following requirements:

• Your organization works with one of the AWS Direct Connect partners, who is a member of the AWS Partner Network (APN).
• Your network infrastructure has a co-location connection to an AWS Direct Connect location.

• Your organization works with an independent service provider allowing a connection to AWS Direct Connect.

Once you have established a physical network connection to an AWS Direct Connect location, you must also ensure that your network meets the following criteria:

• For authentication, your router must support both Border Gateway Protocol (BGP) and BGP MD5 (message-digest algorithm) authentication.
• Depending on the speeds required, your network infrastructure must use single-mode fiber. If you intend to use your Direct Connect connection as a 1 gigabit Ethernet connection, you have to use a 1000BASE-LX transceiver. For greater speeds of 10 gigabits over Ethernet, your transceiver must be a 10GBASE-LR.
• The port on your device must have manually configured speed and full-duplex mode enabled. However, auto-negotiation for the port must be disabled.
• You must ensure that you have 802.1Q VLAN encapsulation support across your network infrastructure, from your network source on-premises up to your customer/partner router at the AWS Direct Connect location. 

An important element of Direct Connect is its ability to partition the connection into different virtual interfaces, so let's now take a look at these in more detail and see what they allow you to do.

Virtual interfaces

As mentioned, due to the requirement of enforcing 802.1Q VLAN encapsulation, you can partition the Direct Connect link into multiple connections, known as virtual interfaces. This allows you to gain access to other AWS services other than those within your VPC. For example, you could configure both a private and a public virtual interface. The private virtual interface will terminate within your VPC, establishing a private link between your corporate network and your VPC using private IP addresses. The public virtual interface, however, could be used to access all public AWS resources, such as objects stored in S3 with a public address space. 

The following diagram shows how this would be represented:

In this diagram, you can see that there are two virtual interfaces that are configured across the connection. Firstly, there is a private virtual interface, indicated by 802.1q VLAN 1. Secondly, there is a public virtual interface that connects to publicly accessible AWS resources, such as configured S3 objects, indicated by 802.1q VLAN 2.

Controlling Direct Connect access using policies

As with all AWS services, access can be controlled by a series of policies, and Direct Connect is no different. Configuring access policies allows you to instill granular access in relation to using and implementing Direct Connect.

When using identity-based policies, Direct Connect uses the prefix of directconnect: for any actions. 

The following policy is an AWS-managed policy found within IAM titled AWSDirectConnectReadOnlyAccess, and provides read-only access to AWS Direct Connect via the AWS management console:

Following on from this, the following policy is another AWS-managed policy, AWSDirectConnectFullAccess, and provides full access to AWS Direct Connect via the AWS management console:

You will notice, in these two example policies, that there are two ec2: actions referring to VPN gateways and transit gateways. I have already explained what a VPN gateway is earlier in this chapter. However, an AWS transit gateway is something slightly different. Without digressing too much, let me quickly explain what it is.

A transit gateway enables the connectivity of multiple AWS VPCs and remote on-premise networks together via a central transit hub. This transit gateway can accept connections from VPCs, VPNs, and Direct Connect connections within a single region and route traffic between all connected networks. Multi-region transit gateway connectivity will likely become possible soon; however, at the time of writing this chapter, it is only feasible within a single region.

 OK, back to the policy management of Direct Connect. When it comes to identifying resources relating to the Direct Connect, there are four different Amazon Resource Names (ARNs), which are as follows:

Using these resources types, you can create more granular policies relating to specific connection IDs, LAGIDs (Link Aggregation Group IDs: https://docs.aws.amazon.com/directconnect/latest/UserGuide/lags.html), virtual interfaces, and DC gateway IDs.

For example, if you wanted to reference a specific interface identified as dxcon-1234abcd in AWS account 6666777788889999, you would reference the ARN in your policy statement, as follows:

"Resource": "arn:aws:directconnect:us-east-1:666677788889999:dxcon/dxcon-1234abcd

You can also use tagging to help manage permissions to your Direct Connect resources. As with most resources in AWS, you can associate tags; for example, you can add a tag to a virtual interface, perhaps to identify different environments. Once tags have been applied, you can then add conditions within your policy to govern what actions can be carried out based on the result of the condition.  

As an example, the following policy will allow an identity to delete a virtual interface on the condition that the resource's environment tag matches the development value:

      {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Effect": "Allow",
          "Action": [
            "directconnect:DeleteVirtualInterface"
          ],
         "Resource": "arn:aws:directconnect:*:*:dxvif/*",
          "Condition": {
            "StringEquals": {
              "aws:ResourceTag/environment": [
                "development"
              ]
            }
          }
        },
        {
          "Effect": "Allow",
          "Action": "directconnect:DescribeVirtualInterfaces",
          "Resource": "*"
        }
      ]
    }
…  

For more information on access policies and JSON policy syntax, please refer back to Chapter 4, Working with Access Policies.

Summary

In this chapter, we looked at both VPN site-to-site connectivity and Direct Connect as a means of connectivity to your AWS infrastructure from your on-premises location via both public and private infrastructure. We saw that VPN connectivity uses the internet as an intermediary network to connect to your AWS infrastructure, whereas Direct Connect uses a private network that physically connects your corporate network to that of AWS within a specific region. Direct Connect generally provides a more consistent and reliable connection and offers enhanced throughput up to a speed of 10 gigabit Ethernet. 

When using either option, consideration needs to be given to your routing configuration, security groups, and access policies. This chapter was designed to cover some of these points; however, for greater in-depth configuration of some of the routing protocols, such as BGP, please refer to the AWS documentation.

In the next chapter, I will be focusing on how AWS allows you to implement various logging capabilities across multiple different services, and so we will be looking at S3 server access logs, VPC flow logs and traffic mirroring, AWS CloudTrail logs, and the CloudWatch logging agent.

Questions

As we conclude, here is a list of questions for you to test your knowledge of this chapter's material. You will find the answers in the Assessments section of the Appendix:

1. When configuring a VPN connection, a VPN gateway is configured as well as what other type of gateway?
2. True or false: when an end-to-end connection is established between two gateways using a VPN connection with IPsec, the connection is referred to as a tube.
3. Does Direct Connect use a public or private network to establish a connection with AWS?
4. True or false: by enabling route propagation, all other routes to networks represented across your site-to-site VPN connection will be automatically added to your route table, preventing you from having to manually add them.