Adding Custom Domains and SSL/TLS with AWS Amplify

Woohoo! You’ve spun up your first AWS Amplify app successfully thanks to the work we did in our first post. That was cool until you realized that now you have some funky domain name like which is not super friendly (unless your business happens to be named ka8enrkjasdf8het LLC).

Configuring a Custom Domain and SSL/TLS on AWS Route53

My domain that’s going to be used in the example is also hosted on AWS using the Route53 service. Another of my favorite on-demand services that I really adore because of how easy it is to configure both in the GUI and programmatically. Did I mention I have too many domains?!

You may have noticed that there’s a little wizard at the top of your AWS Amplify app configuration. These 5 steps show that I have just one completed, so now it’s time to click that second item!

AWS Amplify takes over from here and starts us down the road with the wizard-driven process to set up our DNS for our chosen custom domain. Note that this is my Route53 domain but does also work with externally hosted domains. You just have to do a couple of manual steps.

You use the Add Domain button and this becomes where you choose your Route53 domain which is auto-populated. This is why it’s handy to do a lot of stuff on one provider ūüôā

Your root domain will be the default, assigned in this case to the master branch. You can set up subdomains and even use sub-branches in your repo. This example is the most simple possible version which will be a root domain ( and the www CNAME being assigned to redirect to the root.

We set the Amplify wizard loose and this is where we get to just watch things turn from grey to blue and finally to green. First step is the backend configuration for our SSL (or TLS…that’s up to you how you want to refer to it).

Your SSL cert has been created by Amplify because the backend already knows how to configure your domain since it’s Route53. You may even see a short popup that displays the CNAME that is about to be injected into the DNS zone. This is the next phase that we reach:

You have the next phase done and it’s on the the last part of the backend configuration to active the domain using the new TLS/SSL. You’ll notice that this is all happening automatically. How cool is that?!

Now you’re ready to go! New domain configuration for you AWS Amplify app. New SSL/TLS cert created and attached, and all the Cloudfront updates are done.

Hang on a few minutes…it may be faster, but let’s be realistic and wait for the 5 minutes for all the DNS goodness to clear up. You can now go to the root domain or www of the domain and you are presented with a website and an active certificate for a secure HTTPS connection. Boom!

But, What’s the Downside?

I adore the ease-of-use and manageability of the service. Easy to setup, and easy to tear down. The issue will come with the obscurity of where all this stuff sits in the backend.

You can’t go digging around to find your SSL/TLS certificates like you can in the traditional AWS console using Certificate Manager. Maybe that’s the price of free..well, free-ish. It’s included is really the more accurate way to describe it.

There is Lots of Upside

Let’s review the good stuff as we close out:

  • Easy to use
  • Inexpensive
  • Custom domains without having to do heavy lifting
  • Custom SSL/TLS with auto-renewal and auto-configuration
  • Custom redirects and subdomains
  • Supports lots of adjacent services
  • Supports lots of static page types and languages

Overall, I’m a fan. I know there are alternatives in the market like Firebase and others so I will dig into variants to see where the wins and losses are for features and capabilities. The gravity factor for me is that I have all of my other infrastructure on AWS already, so it’s a natural fit.

Got something else you want to try with AWS Amplify? Hit me up in the comment section. I’m glad to help however I can!

Setting up a Jekyll Website with AWS Amplify

One of the fun parts of living my life in technology is that I really enjoy building web sites for different things I’m working on. Ok, I have a few too many. The bigger challenge is that I have a few different types of sites that I’m building.

Some are WordPress (which I use Kinsta for), some which are Ruby on Rails (which I use AWS EC2 for at the moment), and some which are Jekyll (which I’ve often just hosted as GitHub pages).

Jekyll is a nifty Ruby-based static page framework which makes my Infrastructure-as-Code goal achievable while keeping me fresh on some Ruby and HTML goodness. The issue I have with Jekyll on GitHub pages is that I want to do things like custom domains, subdomains, and collaboration with rapid updates.

Enter AWS Amplify!

Amplify is described as “set of tools and services that enables mobile and front-end web developers to build secure, scalable full stack applications, powered by AWS.” on the AWS console for the service.

There is a ton that can be done, and it’s also a very low cost way to run a front-end web application with lots of flexibility to leverage other adjacent services inside AWS.

Setting up Your Jekyll Site and Workflow

You already have your Jekyll code hosted somewhere for collaboration or just for basic version control. My example here uses GitHub with a private repository.

Launching the AWS Amplify wizard begins with checking which version control system you want, or you can also just choose to deploy without a Git provider like using an S3 backend.

You pick GitHub and connect up to your account. I’ve already done this once so you may get a prompt to allow AWS Amplify to authenticate with GitHub if you are doing this for the first time.

The cool thing is the dropdown will automatically find repositories with Amplify-compatible code so I already see my Jekyll and HTML repos marked for me in the drop down. This one will be my private repo that I’ve called which will also be the domain I set up in a follow up post.

You get a prompt for downloading or editing the configuration in case you have some custom details to inject. Good for keeping offline in case you’re building a few and want to share config files and settings.

Expanding the Advanced Settings (always check the advanced settings!) let’s you do things like add Environment Variables. I’m using these like my typical tag configuration and map a few things I use for other automation.

Now you’re all set for your first deployment! Click the nice shiny Save and Deploy button and then you see the magic happen right in your AWS console.

Remember that my reason for doing this is that I want a few criteria which will include:

  • Collaboration – using GitHub in my case
  • Custom domain and subdomains – I already use Route53 so this is easy to connect up
  • TLS configuration – you get a free TLS/SSL certificate with your AWS Amplify app which is auto-configured for you

Let’s jump back in and see the process in action! You see the 4-part process underway showing a Provision | Build | Deploy | Verify process that will progress as you watch.

First implementation takes a few minutes as the backend is created for your AWS Amplify app.

It’s kinda cool to just watch those little arrows turn green and then you are give your domain which is an auto-generated URL with some UUID on the front of it.

Voila! We have our Jekyll site up and running with the default domain that is provided. It’s just that easy!

That’s great, but I also want to see how this is now a workflow instead of just a static hosting that I have to manage getting content in and out of using something else. (anyone remember FTP…eek!).

You can run a few updates through your code and then just add, commit, and push back to the repository and there is a trigger already configured (on the Master branch in my case).

Head back over to your AWS Amplify console and you can even watch it update live through the 4-step process. So cool!

Now the code is deployed and my Cloudfront is automatically updated in the backend for me so that I can view the updates right away.

Now you are up and running with a default domain name and working web site. Great start, but we have more to explore as we go one step further and configure a custom domain and free TLS/SSL certificate in the next post.

What’s the Upside to AWS Amplify

Pricing anything in AWS can be a little challenging to wrap your head around. Amplify is one of those services that has a combination of charges based on a few factors. Full pricing is available at but here are the basics (as of the time I wrote this):

  • Build time – $0.01 per build minute
  • Data storage – $0.023 per GB stored per month
  • Data viewed – $0.15 per GB served

That’s really cheap compared to some of the alternatives, especially because if comes with a free TLS cert. Pricing is one win and the second one is just the ease-of-use. It literally took me a few minutes to configure with the wizard and that’s it. I’m fully up and running with collaborate code, DNS configuration (next post), TLS (also…next post), and Cloudfront configured. I like easy!

But, What’s the Downside?

The upside is probably also the downside. It isn’t free. There’s a free tier for the first while which I’m sure I’ll blow through without much difficulty. Once you are getting charged you also have the challenge of understanding what your bill “might” be in advance. The pricing is very low, so I’m looking purely to replace some standalone EC2 stuff I’m running which is hosting a few web sites for me.

Stay tuned for the next part coming with your TLS/SSL and custom domain config.

April 2020 Free Training Special from Pluralsight!

The team at Pluralsight have kindly opened up the platform for free in order to allow folks to skill up while being under the challenge of the current worldwide situation.  Being at home should not mean being out of the game.  If you are looking to skill up on any of a variety of literally hundreds upon hundreds of courses, Pluralsight is a spectacular option for you.

Just click this link to get setup and you are off to your learning journey!

My own course on HashiCorp Nomad is among those that are completely free for the month of April, so I will obviously recommend that you try it out and get your Nomad and container journey underway.  Please share if you enjoy and find value in the course as well as any ideas or feedback on what I can do with future advanced courses on Nomad.

Big thanks to the team at Pluralsight for opening this up and it is a testament to their support of the community.



CNCF Meetup Recap: Hello Lemur!

Tuesday March 3rd was another great day for community as the Boston CNCF Meetup group arrived at the Turbonomic offices on Boylston street in Boston for a great evening of discussions and learning.  I was happy to be able to be in town for the event and to watch as my colleague, Meng Ding, who presented the Turbonomic Lemur project.

With the challenges of Coronavirus, it was actually quite a good turnout.  I know that a lot of folks are re-evaluating meetup and travel policies.  Big thanks go out to Chris Graham and Asena Hertz from the Turbonomic team for pulling this together.

Introducing Turbonomic Lemur

The Turbonomic Lemur project is a packaged set of open source tools which includes Grafana, Kiali, Jaeger, and also a light version of Turbonomic which allows for the visualization of the dependencies and resourcing of the entire containerized stack.  This project has been created because of the amount of requests we hear out in the community about how challenging it can be to configure and deploy these tools, plus that even with them, there is no context to how it relates to the actual applications.  

Meng kicked off the event with a demo of what Lemur is and what it looks like when deployed. ¬†Being able to have a single interface for all of the tooling and easy ways to interact with the products was definitely a hit for the folks in the audience. ¬†Since I’ve been contributing to the documentation and some community engagement work for Lemur, this was especially exciting to see that people really loved what it did as a graphical tool….but then the real fun began!

Lemur on the big screen!

The next part of the demo featured the featured the Lemurctl command line tool and this really got some folks excited about the potential. ¬†Meng was able to easily spin up command lines that showed the different resources, utilization, and most importantly, the dependencies in a single CLI of everything from the app inside the container, through the container, pod, and node. ¬†There was a literal “wait, you can see all that and the dependencies in a single CLI command?!” from someone in the audience. ¬†So cool!!

Listening and Learning

Meng and all of the folks there are big fans of any community interaction because we can all learn so much from each other.  Tech and business do not exist in bubbles and learning from the lessons of others can really save time and effort for our own projects and deployments of new products and ideas.  Meng had a keen audience gathering after his presentation as you can see here:

There is much more planned for Lemur and for my own sharing of information about it. ¬†If you’re keen to get involved with this or to learn more, jump into the Github for Lemur and take a look. ¬†I’ll be posting some demo resources here on my blog as well in the coming weeks as I do more exploration and documentation to help folks get the most out of it and make it as easy as possible to build and deploy.

Meng and the entire engineering team who built it deserve some big kudos. ¬†They’ve made three particularly challenging open platforms deployable in a single package. ¬†That’s a massive time and resource saver.

Thanks to everyone again for supporting the CNCF meetup in Boston and the Lemur project.  Looking forward to sharing much more very soon!