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: