Scenario - creating a highly available campaign site for loungebeer.com
The course is part of these learning paths
In this group of live videos, we tackle a practical scenario to help you learn real-world cloud consulting skills.
This is a unique and engaging live video format where we join the Cloud Academy AWS, Azure, and Google Cloud Platform teams in a real-time work situation. The team listen to a customer brief, discuss and define technical requirements and then evaluate which of the public cloud platforms could best deliver on the customer requirements.
From this course, you will learn how cloud professionals go about solving real-world business problems with cloud solutions.
With this course, you will learn how cloud professionals tackle and solve a business problem with each of the three public cloud platforms. This course is highly recommended for anyone interested in learning how to become a cloud architect, specialist or consultant!
Learning how to use your cloud skills in real-world situations is an important skill for a cloud professional. Real life projects require you to be able to evaluate requirements, define priorities and use your knowledge of cloud services to come up with recommendations and designs that can best meet customers' requirements. As a cloud professional you often have to think on your feet, process information quickly and be able to demonstrate design ideas quickly and efficiently.
In this course, we work through a customer scenario that will help you learn how to approach and solve a business problems with a cloud solution. The scenario requires us to build a highly available campaign site for an online competition run by loungebeer.com - a "craft" beer launching a new product in to the market at the US Superbowl event.
In these interactive discussions we join the team as they evaluate the business requirements, define the project constraints, and agree the scope and deliverables for the solution. We then work through the technical requirements we will use to evaluate how each of the three cloud platforms - Google Cloud Platform, AWS and Microsoft Azure - could be used to meet the technical requirements.
We follow each of the platform teams as they define solution architectures for Google Cloud Platform, AWS and Microsoft Azure. We then regroup to run a feature and price comparison before the team builds a proof of concept for our solution design.
This group of lectures will prepare you for thinking and reacting quickly, prioritzing requirements, discussing design ideas and coming up with cloud design solutions.
02/2018 - DynamoDB now supports encryption at rest so that would potentially influence our choice of database in thie scenario
For planning tools see
For more information on White Listing see
- Okay. Hi cloud academy ninjas. Let's do a quick Chalk Talk about what you need to do to transfer a domain from one registrar to Route 53. The domain we'll work with today is thefreshlounge.com and let's transfer that away from the current provider, which is easy space to Route 53. So that actual domain, when we look it up, the first thing that happens is that top level domain is referred to the Root DNS, which is generally an ICANN registrar, which we'll in turn point us to who is the SOA for that particular domain. And in that first look-up it will tell us that the SOA is easy space. And easy space holds the name server records for that particular top level domain. So what we'll need to do is to request easy space to release the domain so that we can transfer it to Route 53. So there's a few steps that happen to make that possible, so we're going to step through those. Once we are referred to the easy space name service, then the zone file at easy space will refer to our records. Which can be MX records, an A name record, a triple A name record, which is a IPV6 record, or it could be a C name record. So each of these basic resolvers will point to an IP address or a service of type, so that we know that when we look for this particular domain, we're referred to a particular IP address by following our steps. So the things that we're going to need to do here are: first of all we have to unlock the domain. So we have to ask easy space to unlock the domain so that the domain name details can be transferred, okay. That essentially removes the who is privacy lock from the domain record, which means that another registrar can access those records. So at this point, we can then ... Once that record has been unlocked, we request our authorization key, or auth key as it's often referred to; and that's simply just an ID which allows us to work with the domain. So those two things can happen almost immediately. Okay so now that we've got those two done, we're able to go into Route 53 and ask Route 53 if we can manage our domain. The unlock has been successful, then we have the option to create a new zone record in Route 53. Before we can do that though, we do need to create that zone record. So let's just step through how we do that. As you can see, we simply add the name and give it the details. Add an authorization address, which is essentially the person who is responsible for maintaining this domain. And once we've done that, we're now able to go back into the Route 53 domain, or TLD manager, which is top level domain, and then see if we can transfer or register our thefreshlounge.com as a Route 53 managed domain. And as we can see here in the on the console, that's now possible because we've created our zone record. Now a zone record at this stage doesn't actually contain anything. All it's saying is that Route 53 will become the new SOA, once this transfer is complete, that the name servers will be managed by Route 53. So it'll be taken away from the easy space name server that we were using previously. Both name servers will refer requests for this domain name depending on the sub-domain, whether it's mx.freshlounge or www.freshlounge, or whatever we choose as a sub-domain A name of C name record, we'll refer to the name servers now managed at Route 53. So at this point, if we do look up the name we won't find anything. So, a classic example here is: if we send an email address to our domain, after this period of transfer, it will comeback with a bounce, because there's no MX record yet. Okay so now we need to create our Route 53 records. So to do that, first once we say what type of record it will be, we'll create an MX record, which will resolve any smtp or email requests to our email provider, which in this instance will be Google. So we're managing our mail through Google, but it could be any other provider or it could be a mail server that you're managing yourself. We will add an A name record, which allows any reference to www requests to a specific IP address. And we'll add a C name record, which we'll say is div.thefreshlounge.com and that will refer to a different IP address again. So what we're creating here is a record set, which will tell our name servers at Route 53 where to direct traffic to. So in essence, we've done this section here. Now the transfer process itself can take five to seven days; so while unlocking the domain is usually immediate, it's really just the on off switch, once the who is privacy is available then you can transfer the domain in or our of a one registrar to another. Requesting the authorization key is generally another simple process, you're either given it directly or it will arrive as an email. And managing the domain itself, creating the domain on Route 53 is easy as well. So all this could happen in one day. However, we then have a three to five day wait period. And this is dependent on the latency between providers; registrars take a little while to hand out a record sometimes, which means that this is not going to happen immediately, in most cases. So you need to factor that in when you are thinking of transferring your domain names, okay. So the first thing that you do is create your zone record on Route 53 first. You can go as far as creating your Route 53 records as well. So that that whole file is ready to go. Then all we have to do is to wait for the zone transfer to complete. And again that's going to be dependent on how long it takes the registrars to talk to each other. Now there's generally a couple of things here that can easily be overlooked. There's one of fee of 12 dollars, currently, to transfer a top level domain from one provider to Route 53. The cost of managing that domain then becomes rolled up in your AWS bill, which in my view is way easier than having to manage numerous domains at other registrars. I actually find this a very, very easy way of managing your domains. Okay, so once we've done all that, we can then just test the domain and there is a test function, which is really useful so you can test the records inside Route 53 and that allows us to just see if the names are resolving correctly. So apart from the fee, what other things can catch you out? Okay, well MX records, making sure you've got those setup correctly. You've got to remember that all of this is going to take time. So it takes time for records to propagate out to caches. There's a thing called the TTL value, which is the time to live. So we can set that to be particular values to basically say refresh the request to ... Refresh any look-up. The TTL is an important value. You can set it to be quite aggressive. The TTL value is 300 seconds So you do have to factor this in so that you may have a period during the hand over where emails go astray, where A name records don't resolve to the right host, and things of the like. So to avoid that, my recommendation is to ensure that you get your Route 53 zone records setup correctly. Create the records ensure that those are setup correctly and then make sure that you've got yourself just a little bit of leeway between the two registrars so that there isn't ... Or less chance of there being requests going astray. Okay, so that's pretty much the process. It's pretty simple. Alright, well done ninjas. See you next time.
About the Author
Head of Content
Andrew is an AWS certified professional who is passionate about helping others learn how to use and gain benefit from AWS technologies. Andrew has worked for AWS and for AWS technology partners Ooyala and Adobe. His favorite Amazon leadership principle is "Customer Obsession" as everything AWS starts with the customer. Passions around work are cycling and surfing, and having a laugh about the lessons learnt trying to launch two daughters and a few start ups.