Yeah, the default cert is file system, and let’s say there are 10 instances in New York, 5 in London and 3 in Singapore. If only the file system cache is used, there would need to be 18 certs issued, which is a problem. They would also need to be constantly re-issued every time the instance restarted, because the hard disk is ephemeral. LE would likely throttle you, especially if there are a lot of certs and instances.
But even that would work only in the DNS challenge, in the HTTP and TLS challenge, the file system cache is a non-starter. There’s no guarantee that the verification check will reach the same instance or the region that asked for it and currently has the token. To have all instances in a region share the cache, we’d want to put them in a DynamoDB table (or a database or S3) in that region. Since the same cert is applicable no matter what the region is, we’d want it replicated to all regional copies of the database, which Global Tables will do.
The walking of tables when a key not found is to handle the edge case where a cert is requested from London and the verification call goes to New York. The challenge token would have been stored in London, and will sync up to New York eventually, but that may happen after the verification call. So if New York can’t find a key it’s trying to verify it needs to check London and Singapore as well — walk all active database regions (can do this in parallel) — until if finds the key somewhere or all return empty.