Connecting Your On-Premises Network to Your RONIN AWS Cloud Account

There are a number of reasons why you might want to connect to AWS from your on-premises network infrastructure, and a number of ways to do so. This blog post is a helpful starting point to determine which solution might work best for you.

Connecting Your On-Premises Network to Your RONIN AWS Cloud Account

There are a number of reasons why you might want to connect to AWS from your on-premises network infrastructure, including:

  • Simplicity of managing a single merged environment
  • Sharing services across both infrastructures
  • The ability to securely access and manage AWS resources from your on-premises network e.g. via Active Directory
  • Advantages of VPN encryption when using unsecured protocols to connect to your AWS resources
  • The ability to access AWS resources using private IP addresses

Before we get started, there is one big question we advise all of our customers to seriously think about before extending and exposing their on-premises network to their RONIN AWS account:

"Do you really need a dedicated connection between your network and AWS?"

On the surface, connecting and extending your existing environment to AWS sounds great. Users can seamlessly connect their RONIN AWS machines and clusters to their corporate file shares and access corporate systems for finance, reporting, email, etc....

However, your security team might see the above paragraph, perform a quick "find-and-replace" on the word "User" with "Malicious Actor and Malware", and promptly deny your request for connectivity.

For your network administrators, immediate heartburn sets in upon hearing that a self-service HPC cluster tool will be claiming large chunks of the remaining corporate network's IP pool.

A quote you can quote us on - For all connectivity back to on-premises systems, we always advise you conduct an internal risk assessment and design a plan for connectivity that is based on focused and specific exposure options configured with "least privilege" security principles in mind.

A dedicated connection between your on-premises network and AWS is not always necessary, because secure and sophisticated access can be achieved natively within AWS using MFA (Multi Factor Authentication), Access Lists, Security Groups, and Inbound Filtering, etc. Nevertheless, if you do decide that merging your on-premises and AWS network is the best solution, there are a number of ways to achieve this. We will cover each of these options below.

Option 1: Direct Connect

AWS Direct Connect enables a secure connection to your RONIN AWS environment from your on-premises data center or office via a standard 1GB or 10GB Ethernet fiber-optic connection (for most organizations, 10Gb resilient uplinks will be most suitable, especially when thinking long term). This solution offers a dedicated high speed, low latency connection, which bypasses internet service providers in your network path. With AWS Direct Connect you also have the ability to logically partition the fiber-optic connections into multiple Virtual Local Area Networks (VLAN) to meet your desired security, compliance and performance requirements.

To implement this solution, you will need to allocate a new scope of IP addresses (that don't conflict with anything in your Data Center) via your AWS Virtual Private Cloud (VPC), and a BGP dynamic routing protocol will need to be configured to allow reachability between the AWS and on-premises environments. You will also need to ensure that you have 'fat margins' on your Firewall policy to effectively handle the 50-100% increase in size at your Edge, Extranet and LAN points due to the additional traffic to/from AWS.

With AWS Direct Connect, there are no charges for the connection, but there are charges associated with the data transfer. For example, if you order a 1GB connection to the US East region (Virginia) and you expect to transfer 1TB out on a monthly basis, the total cost would be $236 per month. Ensure that you estimate your costs using the AWS Pricing Calculator.

More information on the Direct Connection option and what it will require can be found here.

Option 2: Site-to-Site VPN

If you already have a pair of Firewalls or Routers (with VPN accelerator hardware) in High-Availability mode connected to the Internet, this solution is much faster to implement than Option 1.

By default, instances that you launch into an Amazon VPC can’t communicate with your own (remote) network. You can enable access to your remote network from your VPC by creating an AWS Site-to-Site VPN connection, and configuring routing to pass traffic through the connection.

Site-to-Site VPN supports Internet Protocol security (IPsec) VPN connections and offers two (Active/Standby) VPN tunnels between a virtual private gateway or a transit gateway on the AWS side, and a customer gateway on the remote (on-premises) side.

More information on the Site-to-Site VPN option can be found here. Ensure you also understand the pricing associated with this solution — pricing examples can be found here.

Option 3: Client VPN

AWS Client VPN is a managed client-based VPN service that enables you to securely access your AWS resources and resources in your on-premises network. This solution requires the network team administrators to set up and configure the VPN service. Once downloaded, the Client VPN endpoint configuration file is distributed to end-users that require this service.

End-users will connect to the VPN endpoint and establish the VPN session from their local computer or mobile device using an OpenVPN-based VPN client application. Once connected, they will be able to securely access the resources in the VPC in which the associated subnet is located. They can also access other resources in AWS or an on-premises network if the required route and authorization rules have been configured.

More information on the Client VPN option can be found here.

When merging your on-premises and AWS networks, it is important to carefully consider which of the above options will be most suitable for your infrastructure and needs. We hope this blog post is a helpful starting point, but please reach out to your local AWS representative if you wish to discuss any of the solutions in detail.