0

We're in the process of setting up AWS Elasticache Memcached instances to speed up the processing in our REST APIs.

For this we have VPCs setup in AWS with public and private subnets and VPN tunnels from our office into the VPCs using a Customer Gateway and Virtual Private Gateways.

The Elasticache Memcached service will be instantiated in the private subnets of a VPC.

I just read in below link that Elasticache can only be accessed from outside of AWS such as our office through a NAT Instance (or Bastion Host).

http://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/Access.Outside.html

Is there really no way to access Elasticache through a VPN??? It would be shocking to me that AWS forces you to go through the public internet to get to Elasticache instead of allowing access through a private VPN tunnel.

Bernie Lenz
  • 1,967
  • 23
  • 45
  • Have you tried it? They *might* simply be intending to say that it is not possible to directly expose this service to the Internet, and a hardware VPN connection doesn't fall into the definition of "outside" the VPC as intended here. Otherwise, an HAProxy server running in TCP mode on a small EC2 instance should completely work around such a limitation... assuming it is really a limitation. Test it? Note that there really is such a limitation on Elastic File System, but the same sort of protocol-agnostic TCP proxy in EC2 [works around it](http://serverfault.com/a/799213/153161), perfectly. – Michael - sqlbot Mar 31 '17 at 00:48
  • @Michael-sqlbot Yeah we tried it... Running a telnet command from the office network to the 10.1... ip of memcached on port 11211 just hangs. The same telnet command works from an ec2 instance inside the vpc.. – Bernie Lenz Mar 31 '17 at 21:00
  • 1
    The link you posted has a captivating comment: "The interesting thing about these ENIs is that they do not appear to use the route tables for the subnets to which they are attached. They seem to be able to respond only to instances inside the VPC, regardless of security group settings". Something similar might happen with Elasticache. – Bernie Lenz Mar 31 '17 at 21:00
  • We did get it to work using a NAT Instance in the public subnet and by connecting over the internet through the NAT Instance as recommended by Amazon. To be honest though, I find that solution a real nasty hack. I haven't tried setting up a NAT instance in the private subnet of the VPC yet, which would at least eliminate any security concerns of connecting through the public internet but in my mind that's a hack too, although a more secure hack. – Bernie Lenz Mar 31 '17 at 21:01
  • And you tested with telnet with the security group configured to allow it, but no joy? *"Something similar might happen with Elasticache."* We know they have at least one service that works this way, so... yeah. Note, you wouldn't normally deploy what AWS calls a NAT Instance on a private subnet. To do this, you could use any AMI you like, if you know how to work iptables. Or use the proxy, which I often use even when not "needed" because it has logs and stats, and is easier to deploy redundantly, since it terminates the TCP connections back-to-back, avoiding any route asymmetry issues. – Michael - sqlbot Mar 31 '17 at 21:42
  • 1
    Thanks @Michael-sqlbot for your help. It turned out that our "internal" connection problem was an issue with the java spring libraries we used, and not any VPC issue after all. We indeed now can connect directly to ElastiCache through a VPN without using any kind of jump box. The statement in the AWS ElastiCache documentation "The cluster must reside within a VPC and be accessed through a Network Address Translation (NAT) instance. There are no exceptions to this requirement." is not correct. – Bernie Lenz Apr 04 '17 at 18:29

0 Answers0