Using AWS DynamoDB DAX from local development machine

5.4k Views Asked by At

I'm trying out the DAX client for my application currently using DynamoDB and found out it's only supported within a VPC. The DAX endpoint is in the 172.31.x.y range.

Does this mean it's impossible to test DAX features from my local development machine, or is it possible to configure DAX to be reachable from the Internet for testing purposes in some way? Or am I stuck with SSH-ing into an EC2 in the VPC?

2

There are 2 best solutions below

0
On

It is possible to access DAX from outside your cluster if you create a VPC endpoint and nlb

import com.amazon.dax.client.dynamodbv2.DaxClient;
AmazonDynamoDB amazonDynamoDb = new DaxClient(
                "vpce-XXX-YYY.vpce-svc-ZZZ.us-west-2.vpce.amazonaws.com",
                8111, region, credentials);

more details are here : https://stackoverflow.com/a/62094056/278266

4
On

Answer: Seems like the answer is No, we can't even test via our local dev machine.

I faced this same issue. After spending so many hours digging through videos and documentation I finally think I figured it out. I don't see why Amazon should restrict this to be in the VPC only. As long as the customer uses their private and public credential keys, I don't see why you can't securely access the DAX from outside VPC. (Only thing I can think of is potential DDOS attacks). Regardless, Amazon could have done a much better job communicating this... They didn't mention in any video, and I only found this hidden away in one random document...

https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/DAX.html

Usage Notes For a list of AWS regions where DAX is available, refer to https://aws.amazon.com/dynamodb/pricing.

DAX supports applications written in Java, Node.js, .Python and .NET, using AWS-provided clients for those programming languages.

DAX does not support Transport Layer Security (TLS).

DAX is only available for the EC2-VPC platform. (There is no support for the EC2-Classic platform.)

DAX clusters maintain metadata about the attribute names of items they store, and that metadata is maintained indefinitely (even after the item has expired or been evicted from the cache). Applications that use an unbounded number of attribute names can, over time, cause memory exhaustion in the DAX cluster. This limitation applies only to top-level attribute names, not nested attribute names. Examples of problematic top-level attribute names include timestamps, UUIDs, and session IDs.

Note that this limitation only applies to attribute names, not their values. Items like this are not a problem: