Can AWS block access from embargoed countries

The AWS CLI now supports the --query parameter which takes a JMESPath expressions.

This means you can sum the size values given by list-objects using sum(Contents[].Size) and count like length(Contents[]).

This can be be run using the official AWS CLI as below and was introduced in Feb 2014

 aws s3api list-objects --bucket BUCKETNAME --output json --query "[sum(Contents[].Size), length(Contents[])]"

Interesting question - it doesn't appear to be explicitly documented whether Amazon Route 53 supports IP addresses outside of the published Amazon EC2 Public IP Ranges, but I think it does to some extend, here's what I've figured/tested:

Documentation

The introductory blog post Multi-Region Latency Based Routing now Available for AWS mentions that If you enter an EC2 instance public IP, Elastic IP, or Elastic Load Balancer target in the Route 53 console it will suggest the correct region for you - This is indeed the case, while entering a non EC2 IP address leaves this selection up to you, see Tests below. The post also states the following:

Behind the scenes, we are constantly gathering anonymous internet latency measurements [...]. These measurements help us build large tables of comparative network latency from each AWS region to almost every internet network out there. They also allow us to determine which DNS resolvers those end-users generally use.

Furthermore, the post mentions that Latency Based Routing is available for the "A", "AAAA", "CNAME", "TXT" DNS record types as well [...].

Test

With the above background information I've created a latency based resource record set with EC2 instances us-east-1, us-west-2, ap-southeast-1, ap-southeast-2 and added a non AWS router/gateway of ours in Europe, specifying eu-west-1 as region accordingly.

I've used a low TTL and included/excluded and cross tested the respective DNS responses from these four instances and Route 53 delivered the desired result indeed, i.e. responding with the non AWS IP address in eu-west-1 where appropriate and depending on which regions have been included in the set.

• Please note that I've performed these tests manually and gained no 100% systematic test coverage - ideally this should be a respectively automated and configurable setup of course.

Conclusion

Latency based routing to non AWS IP addresses seems to work to the extend that you need to subsume your own addresses to one of the available AWS regions - this does make sense, insofar AWS needs to employ latency measurements for non AWS routes anyway to achieve the desired shortest path analysis from an end user perspective and these systems are mostly running outside of AWS.

• A prominent example would be end users of Amazon CloudFront, where the facilitated latency based routing technology originated and which features dozens of edge locations worldwide, many of which are outside the AWS regional datacenters, see the Global Infrastructure map/info.