- AWS ElastiCache Tutorial
- Launching Cluster
- Viewing Cluster Details
- Cluster Endpoints
- Accessing Cluster
- Modifying Cluster
- Rebooting Cluster
- Adding Nodes
- Removing Nodes
- Scaling the Clusters
- Delete Cluster
- Redis Shards
- Parameter Group
- Listing Parameters
- Deleting Parameters
- Engine Parameters
- Backup and Restore
- Monitoring Node - Metrics
- Memcached & Redis
- Accessing Memcached Cluster
- Lazy Loading
- Write Through
- Add TTL
- Memcached VPC
- Creating Memcached Cluster
- Connecting to Cluster in VPC
- Delete Memcached Cluster
- IAM policies
- SNS Notifications
- Managing Tags
- Managing Costs
- AWS ElastiCache - Resources
- Quick Guide
- Useful Resources
- Selected Reading
- UPSC IAS Exams Notes
- Developer's Best Practices
- Questions and Answers
- Effective Resume Writing
- HR Interview Questions
- Computer Glossary
- Who is Who
AWS ElastiCache - Connecting to Cluster in VPC
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.
Different Regions of Different VPCs
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.
Running in a Customer's Data Center
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.
Accessing through VPN
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
Accessing through Direct Connect
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.