The following scenarios are supported by AWS ElastiCache platform to connect to clusters in a VPC. We already know from previous chapters that we use a EC2 instance to connect to a node in a cluster. But the cluster and the EC2 instance may remain in the same VPC or different VPC. Also, they may remain in the same or different regions within the VPCs. Approaches to handle these scenarios are discussed in this chapter.
Following are the access patterns for these scenarios.
Accessing an ElastiCache Cluster when it and the Amazon EC2 Instance are in the same Amazon VPC
Accessing an ElastiCache Cluster when it and the Amazon EC2 Instance are in Different Amazon VPCs but in the same region
Accessing an ElastiCache Cluster when it and the Amazon EC2 Instance are in Different Amazon VPCs but in different region
Accessing an ElastiCache Cluster from an Application Running in a Customer's Data Center using VPN connectivity
Accessing an ElastiCache Cluster from an Application Running in a Customer's Data Center using direct connectivity
The first scenario above has already been addressed in the chapter awselasticache_accessing_memcached_cluster.htm and the second scenario is discussed in this chapter.
In this scenario, the networks are geographically dispersed. So, we need a transit VPC. A transit VPC simplifies network management and minimizes the number of connections required to connect multiple VPCs and remote networks. This design can save time and effort and also reduce costs, as it is implemented virtually without the traditional expense of establishing a physical presence in a colocation transit hub or deploying physical network gear. The below diagram illustrates how such an arrangement is going to work.
The steps to connect using a transit VPC are listed below.
Deploy a Transit VPC Solution. For more information, see, How do I build a global transit network on AWS.
Update the VPC routing tables in the App and Cache VPCs to route traffic through the VGW (Virtual Private Gateway) and the VPN Appliance. In case of Dynamic Routing with Border Gateway Protocol (BGP) your routes may be automatically propagated.
Modify the Security Group of your ElastiCache cluster to allow inbound connection from the Application instances IP range. Note that you will not be able to reference the application server Security Group in this scenario.
In this scenario there is a Hybrid architecture where clients or applications in the customer’s data center may need to access an ElastiCache Cluster in the VPC. This scenario is also supported providing there is connectivity between the customers’ VPC and the data center either through VPN or Direct Connect.
The below diagram shows how the transit VPC concelt is going to work through a VPN.
Below are the steps to access the cluster form a client machine using VPN connectivity.
Establish VPN Connectivity by adding a hardware Virtual Private Gateway to your VPC. For more information, see a Hardware Virtual Private Gateway to Your VPC.
Update the VPC routing table for the subnet where your ElastiCache cluster is deployed to allow traffic from your on-premises application server. In case of Dynamic Routing with BGP your routes may be automatically propagated.
Modify the Security Group of your ElastiCache cluster to allow inbound connection from the on-premises application servers
AWS Direct Connect lets you establish a dedicated network connection between your network and one of the AWS Direct Connect locations. This is a dedicated connection can be partitioned into multiple virtual interfaces.
The below diagram indicates how this direct connect is going to work.
The steps to implement for this arrangement are as below.
Establish Direct Connect connectivity. For more information, see, Getting Started with AWS Direct Connect.
Modify the Security Group of your ElastiCache cluster to allow inbound connection from the on-premises application servers.
In all of the above scenarios there will be networking latencies and additional data transfer charges.