The key used in HMAC is, by definition, symmetric: the same key is used to compute the MAC value, and to verify the MAC value. Digital signature algorithms are asymmetric, which means that the key for verification is distinct from the key used for generation; this "difference" is strong: the key used for generation cannot be recomputed from the key used for verification (at least, nobody found a way to do that in a non-ridiculous time with existing technology).
Digital signatures make sense in situations where the verifier must be able to verify signatures, but without being granted the power to generate other signatures of its own. This is typical of non-repudiation scenarios: only the signer must be able to produce valid signatures, otherwise the signature cannot be unambiguously attributed by third parties (e.g. a judge) to that specific signer. However, in authentication scenarios such as Amazon AWS, there is no third party to convince; there is only the client and Amazon. When a HMAC value is successfully verified, the Amazon server is convinced that someone knowing the HMAC key was involved; since that key is known only to the client and the server itself, and the server remembers not having used the key for that message himself, the server easily concludes that the client computed the HMAC.
Digital signatures imply some overhead:
More CPU: generating a digital signature and verifying a digital signature requires more work than HMAC (difference is negligible for big messages, but can be significant for small messages of less than a few kilobytes).
More network bandwidth: a very robust HMAC value fits in 16 bytes, whereas an equivalently robust RSA signature will use 256 bytes (this can be lowered to about 64 bytes with DSA or ECDSA). There again, this is significant when processing lots of small messages.
More storage size: a RSA public key (for verification) will use 256 bytes; the private key will use more (about one or two kilobytes). ECDSA can help, to some extent (down to about 32 bytes for either key), but it is still larger than the 16 bytes for a HMAC key.
Randomness: many digital signatures require some per-signature randomness, which must be obtained from a cryptographically secure PRNG.
More complexity: mathematics and code involved in digital signatures are more complex than HMAC (HMAC is just a pair of hash function invocations; digital signatures begin with a hash function invocation, and then do weirder things). For security, complexity is bad.
So you do not want to use digital signatures in contexts which can be equally well served with a simpler HMAC. In my view, the most compelling reason is the last one: complexity should be avoided.
