Not free (looks like $1 per domain name per month), but just announced today:
(The non-exportable certificates only usable within the AWS infrastructure are still free where you don't have access to the actual private key, but this expands their offerings beyond the paid "exportable" ones that used their own APIs to also offer ACME-based paid certificates.)
A quick read looks like all domain validations are done in advance and persist.
Authorization: The ACME server checks pre-configured domain validations. Because the endpoint uses PRE_APPROVED authorization, no live challenges are required from the client.
From: Issuing certificates through ACME - AWS Certificate Manager
I believe that means the Order would be marked valid assuming your config on AWS ACM is correct. It uses a CNAME record to store the needed value. This is the same format used by ACM for its free certs that are bound to an AWS service and are not exportable. For Route53 these CNAME are setup automatically during your config for this in ACM.
I did not see any mention of it supporting ACME ARI.
I'm curious to try it out but not sure if I'll get to that soon.
Looks like it’s layered pricing. $.50 cents after 1000 and $0.25 after 4000 certs in a month. That’s a lot. Do any of you issue 1000 public certs in a month ? I’m wondering why the tiers are at 1000 and 4000 certs and who uses so many. In our org, we use like 10.
Domain parkers, CDNs, and hosting providers have potentially millions of certs
It is not "certs", it is domain names. So two FQDN in one cert start at $2
A single wildcard entry starts at $5
I used the new AWS ACM ACME service. Not sure what I plan to do with it long-term but thought these comments useful.
ARI
I confirm there is no ARI support. This endpoint is not advertised in the directory
Testing
There is no test endpoint so each issued cert costs money.
New-Nonce
AWS ACME sets a response header of Content-Type: application/json even though there is no response data. Some json parsers may fail if you pass them an empty string. Certbot was not affected.
CSR algorithms must match
This caused me the largest grief. In short, in the CSR the public key algorithm and the digest signature algorithm must "match". Example: If your public key is 384 bit EC then the CSR signature must be ecdsa-with-SHA384 (type and bit size match).
Because of this I could not issue a P-384 cert using current Certbot. I could issue P-256. It seems the --elliptic-curve option for Certbot does not affect the CSR signature algo. This requirement also affected my custom client that is based on ACMECert. Google says acme.sh keeps these aligned but I did not test it.
The error if they do not match is like (w/value reflecting the mis-match):
EC P-384 key requires signing algorithm SHA384withECDSA
This algo matching requirement does not exist for other ACME CA like Let's Encrypt, Google Trust Services, or ZeroSSL as examples. Which is partly why it took me so long to understand exactly what it was complaining about. I don't think much about the CSR either so there's that too. I've submitted a support case to AWS about at least improving messaging or docs.
CSR public key algo must match ACM ACME Endpoint config
This is perhaps obvious but given the other algo issue it confused me. The message also seems more like an IAM policy restriction or similar which led me down some fruitless paths when the remedy was simple.
In the AWS ACM Console you setup an "endpoint" for ACME. In that you indicate the key type(s) for the cert. If your CSR public key algo does not match that selection it fails with a very long error something like:
User: arn:aws:sts::XXX:assumed-role/AcmAcmeIssuanceRole-XXX/acme-request-XXX is not authorized to perform: acm:RequestCertificate on resource: arn:aws:acm:RRR:XXX:certificate/* with an explicit deny in a resource-based policy
UPDATE Jul10:
ACM ACME allows RSA 2028 in addition to the ECDSA P-256 and P-384 I noted above.
For RSA, the CSR digest signature algorithm must be SHA256WithRSA
Using SHA384 or SHA512 resulted in the Finalize request failing to complete within 4 minutes. A successful cert request takes less than 15 seconds and I repeated this multiple times so this seems a bug related to a "mis-matched" CSR sig algo similar to the constraint shown with ECDSA
ACM ACME does not allow any RSA size other than 2048. Trying to create one results in that long "not authorized ... explicit deny" message noted above.
I don't use RSA certs but curiosity got the best of me so checked it out.
How obscure it is!
I need some guidance please, Asking here as I believe the fundamentals hold true for Let’s Encrypt as well. I tried out this ACM offering and it works well. However, gehow do I ensure my servers that spin up on containers auto bind with EABs so that they can request a certificate. I’m struggling with how I can secure the EABs and allow secure access to it by required clients on demand in an automated fashion. Any advise, pointers helpful.
I realize I can delegate the certificate request to cluster-level controller, But the question still remains on how I can authorize anything in an automated manner through EABs.
First, you are getting off-topic for a thread in the Client Dev section. This is intended for people to discuss issues related to developing ACME Clients. Usually focused on Let's Encrypt but not always. Your question is a general Help query about designing a system. And, given it's not even for Let's Encrypt it's a bit far afield for this forum in general 
I supplied the info I did with other ACME Client authors in mind. Probably Peter did too when he started this thread.
There are a number of threads in the Help section on this forum that discuss the general idea of handling multiple servers and cert acquisition / distribution. Searching those topics might give you some ideas.
I will say that generally acquiring the cert in one location is best. And then distribute that to your other servers by whatever method you prefer. This depends on your specific architecture and security requirements.
Cert acquisition is relatively slow and not guaranteed due to outages and what-not. You don't want a container / server startup to lag or fail due to cert acquisition. Further, problems with cert acquisition is easier to debug / manage at a central locale.
Doing this with AWS ACM ACME will be different than Let's Encrypt. ACM ACME uses EAB but LE does not. LE has rate limits that can impact frequent cert acquisition. I haven't seen AWS docs about that.
There are a number of AWS support options for these kinds of system design questions