Contents

AWS Amplify Custom Domain Management

Recently I moved my personal blog from GitHub Pages to AWS Amplify. While it was fairly easy to setup the Amplify project and CI/CD pieces, the DNS configuration for Custom Domains was less straightforward. The following observations are what I found to be less than ideal while using Amplify for the first time.

AWS Amplify DNS instructions

One problem that I found with AWS Amplify, which was surprising for someone who is familiar with Route53 and DNS, is that the suggested instructions on the Amplify Domain Management page are somewhat cryptic. Amplify is a fairly new AWS service, so I’ll give them some lattitude, but this UI/UX needs to be improved.

/images/amplify-dns.png
Amplify DNS update instructions (image)

These were the problems that I think are the most blatant, and how they can be improved.

  1. The ownership verification CNAME should clearly indicate what the host name is and what the record is. In the above image, it just shows the host name on the left side of the CNAME record type, and the record value on the right side. It was slightly confusing to me, and for someone who is unfamiliar with DNS and AWS Route53 it is likely even more difficult to follow.

  2. The ANAME information is confusing if you’re using AWS Route53, though it does say in very small grey type that this also means ALIAS record. Isn’t this commonly known simply as an A record? I’m no DNS expert but I expect AWS to use common terminology when possible. They do discuss terminology in the Amplify documentation but it should be clearly described in the actual instructions where you’re telling people how to set this up. Documentation should be secondary, as many people don’t read AWS documentation and it is not often easy to locate AWS docs.

  3. The DNS record information (shown in the above image) is hidden in the Actions drop down here.

    /images/amplifyviewdnsrecords.png
    Amplify DNS records (image)

    This should be much more visible. Possibly a big red button saying “Setup Your DNS HERE”.

  4. The CloudFront distribution domain name in the above image is helpful, but it should also include the CloudFront distribution zone ID. I had to pretend to add this CNAME record in the Route53 console before I could figure out what zone this CloudFront distribution was part of. This is necessary if you’re using something like Terraform to proivsion these CNAME or ANAME records.

  5. When a user has a Route53 zone in another AWS organizational account, it should be possible to use that zone, rather than creating ACM certs and zone records in the AWS organization account which houses the Amplify website. This might be possible with IAM cross account roles or something else but I haven’t found documentation to indicate that as of yet.

So there are quite a few concerning UI/UX issues that need to be addressed to make Amplify more welcoming to the average bear.

Integration with other AWS organization accounts

My blog using Amplify is in a separate AWS account than my AWS Route53 and AWS Certificate Manager resources, which might be a common pattern for many organizations. In effect, because the Amplify application is not in the same account as the Route53 and ACM resources for the domain, this becomes the equivalent of configuring a custom domain managed by a third-party DNS provider.

I understand that AWS cannot automatically grant its own services access to another AWS account in the same AWS organization to enable these two services to work together. But there should be the capability to use IAM permissions or roles to grant another account access to the DNS services that Amplify seems to manage under the covers.

Amplify provisions other AWS resources which are not visible

The above observation segues into the next concern, why are Ampify created resources such as Route53 zones and records, CloudFront distributions and ACM certificates hidden when using this service? When Amplify creates your application using a custom domain, it creates ACM certificates, DNS records, and a CloudFront distribution that are all (as far as I can tell) invisible in the console.

I’m familiar with the pattern that when I use the AWS console to create an EC2 instance for example, it creates security groups and possibly VPC resources for me. Anyone who has created an EC2 instance using Infrastructure as Code (IaC) tooling knows there are multiple things that AWS does under the covers in the console for this operation. The difference here though, is that those resources are visible and accounted for in the console.

Oddly, if I create an Amplify app using the console, additional resources that get created on my behalf are not visible in the console. Now I can possibly understand that these are hidden because they might be non-billable resources, and the costs are rolled up into one single Amplify cost line item (although that is not reflected or described in the pricing page.) But these resources should still be shown to me so that I can view them for example to see the Route53 zone ID if I was using it for my own custom domain CNAME record.

Again, this may be because the Amplify team doesn’t want you to attempt to manipulate or configure these resources, but it seems to me an antipattern to generate resources that are not visible, while some of the information from those resources is necessary to use the service properly. I’d much rather that these were visible, but there was a disclaimer that they were associated with an Amplify app and not billed as normal Route53, ACM or CloudFront resources that the user initiated and created themselves.

Conclusion

Overall I’m happy with the complexity that the service is able to abstract for its users. But there are rough edges and I’d ask for AWS to look into working on addressing these concerns. It does appear that in order to make this a very approachable service for some, it has traded off some configurability. That may mean the Amplify service is really only operable in a subset of use cases.