DEV Community: ~\Chirchir

Create a Static Website with AWS S3 and Route 53

~\Chirchir — Sun, 01 Oct 2023 17:30:57 +0000

Amazon Route 53 is the AWS answer to a well-known, reliable, cost-effective service for managing and maintaining domains. Route 53 is an Amazon Web Service, a highly available and scalable cloud Domain Name System (DNS) that connects the internet traffic to the web servers hosting your Web application.
Route 53 lets developers and organizations route end users to their web applications in a very reliable and cost-effective manner.
Like a traditional Domain Name System (DNS), Route 53 translates domain names into IP addresses to direct global traffic to your website. Route 53 converts World Wide Web addresses like www.example.com to IP addresses like 10.20.30.40.

Why is it called Route 53?

In the name Route 53, "Route" is a likely reference to the U.S. Routes featuring the United States Numbered Highway System, often called U.S. Routes or U.S. Highways. The "53" is a possible reference to the TCP/UDP port 53 used for DNS server requests.

How does Route 53 work?

AWS Route 53 connects customer and service requests to your infrastructure running in AWS. These requests may originate from AWS ELB, Amazon EC2 instances, or Amazon S3 buckets. AWS Route 53 also routes users to your infrastructure outside of AWS.
With Route 53, you can also set up DNS health checks, continuously monitor your applications' ability to recover from failures, and control application recovery using Route 53 Application Recovery Controller service.

AWS Route 53 traffic flow helps you manage traffic globally via various routing types, including latency-based routing, geo DNS, weighted round-robin, and geo proximity. All Route 53 routing types can be easily combined with DNS Failover to enable various low-latency, fault-tolerant architectures.

Some of the features of Route 53 include;

If a web application requires a domain name, Route 53 service helps to register the name for the website (i.e., domain name).
You can register your custom domain name by purchasing one from AWS if the domain name is available or move your current domain name to AWS with Route 53.
Route 53 also works with other AWS services to automatically route the user to a healthy resource if any failure is detected at any level.

What is commonly mentioned with Route 53

Records
Records are created to route internet traffic to the resources. Records are usually objects in the hosted zone that determine how traffic is routed for a domain name for it to reach the resources. Each record entry in a hosted zone must end with the name of the hosted zone.

Hosted zone
It is a collection of records containing information about how to route traffic for all the domains and subdomains. When you register a domain name with Route 53, a public hosted zone with the same name as the domain name is also created.

DNS Recursor
A DNS recursor is responsible for receiving queries from the client machines and making additional requests to fulfill the DNS query. It is the librarian that finds the specific book you asked for, using a recursive search.

DNS query
A DNS query is the request for information about a resource, in this case, a webserver through its domain name, that is sent from a DNS client to a DNS server.

Alias records
In the AWS world, Alias records help route internet traffic to other AWS resources like an S3 Bucket or Amazon CloudFront. Alias records are usually created in the top node of the DNS namespace.

Name servers
A name server in the DNS resource pipeline translates domain names into IP addresses, allowing you to find the specific web server that matches your DNS query. It ensures that your request is routed to the correct resources.

DNS failover
DNS failover is a DNS routing method that routes traffic from an unhealthy resource to a healthy resource, usually a web server, whenever a resource failure is detected.

Routing policy; A Routing policy usually determines how Amazon Route 53 responds to queries.

DNS query
A request submitted by a computer or a smartphone to the Domain Name System (DNS) to connect to a resource associated with a domain name. When you search for amazon.com, you generate a DNS query for a web server that matches amazon.com to the DNS service.

Root Nameserver
It's the first step to converting human-readable hostnames like Amazon.com into IP addresses. Think of a Root nameserver as the library index used to find the location of a particular book on the shelves.

TLD Nameserver
Think of a top-level domain server (TLD) as a specific rack of books in a library. The TLD nameserver is the next step to discovering the specific IP address, and the last part of the hostname (for example, the TLD server is "com") is hosted in it.

Authoritative Name Server
An Authoritative Name Server is the final nameserver in terms of web search. Think of it like a dictionary on a rack of books that translates a specific name into its definition. The authoritative nameserver is the final step in the nameserver query.

Domain Registration
With a scalable DNS management service like Route 53, users can either transfer management of existing domains or register new domain names to AWS Route 53 and enjoy consolidated management and billing from one console.
Traffic Management
AWS Route 53 provides intelligent traffic routing based on parameters, including the health of endpoints, proximity, and latency, among many more.

Route 53 performs real-time Health Checks and Failover operations depending upon the specific configurations; Route 53 then directs internet traffic to a healthy target. The health-checking agents will route the traffic to healthy endpoints if any unhealthy endpoint is found.
The function of the health check feature is to generate CloudWatch metrics that trigger AWS Lambda functions to perform appropriate corrective actions.

DNS Routing Strategies

Simple routing policy
It is a simple Route 53 routing technique that can route internet traffic to a single resource. With simple routing, routing multiple records with the same name cannot be created, but multiple values ( such as multiple IP addresses ) can be specified in the same record. Simple routing is used for a single resource that performs a given function for a particular domain. It allows configuring DNS with no unique Route 53 Routing.

Failover routing policy
Whenever a resource goes unhealthy, this policy allows routing the traffic from an unhealthy resource to another or alternate resource. It uses an ELB (Elastic Load Balancing) setup with one resource in active mode and the other in standby mode. It switches automatically when there is a failover. One of the sites is active and serves all the traffic at a time, while the other Disaster Recover (DR) site remains in standby mode. The health of the primary site is monitored by Route 53 using the health check feature.

Geolocation routing policy
This routing policy routes the traffic to resources based on the user's geographic location. Geographic locations can be specified by continent, country, or state. It localizes the content or website in the language of the user. These are specified by continent or by country. The Geolocation Routing Policy routes the traffic as per the geographic location from where the DNS query originated. With the help of this policy, the traffic can be sent to resources in the same region from where the request originated.

Geo proximity routing policy
It routes traffic based on the user's geographical location and the type of content the user wants to access. The user can optionally shift traffic from resources at one location to resources at another location. Using this policy, a user can redirect more traffic to one location than another by specifying a value known as bias. The function of a bias is to expand or shrink the size of the geographic region from which traffic is routed to a resource. A Route 53 traffic flow must be used to use geo proximity routing.

Latency routing policy
Latency Routing is used when the resources are in multiple AWS Regions, and the traffic needs to be routed to the region that provides the best latency. A latency-based routing policy is used if your website has to be hosted in multiple regions, but users need extremely low latency when accessing your website. To use this policy, the resource latency records are created in multiple AWS regions.

Multivalue routing policy
It is used when users want Route 53 to return multiple values in response to DNS queries. It first checks the health of resources and then returns the multiple values only for the health resources.

Weighted routing policy
This routing policy routes traffic to multiple resources with a single domain name according to the proportion decided by the user. It routes multiple resources with a single domain name and controls the traffic routed to each resource. It is mainly useful for testing and load-balancing new versions of the software. A Weighted Routing Policy is used when multiple resources exist for the same functionality, and the traffic must be split between the resources based on specified weights.

Should you use Route 53, and why?

Highly Reliable: Route 53 is built using AWS's highly available and reliable infrastructure. The distributed nature of the AWS DNS servers helps ensure a consistent ability to route the end-users to the web application.
Scalable: It automatically scales the resources during traffic spikes and handles large queries without the user's intervention.
Easy to use: Very user-friendly and easy to configure DNS settings. Route 53 can begin responding to DNS queries within minutes and be mapped easily to any resource.
Health Check: Route 53 monitors the health of the application. If any failure is detected, it automatically redirects the user to a healthy resource before the customer can identify the problem.
Flexible: You can decide which policy you want to use at a given time.
Simple: Using routing types, Route 53 helps to manage traffic globally.
Cost-effective: Payment is made only according to the services used.
Secure: By integrating it with IAM, access to Amazon Route 53 is secured by giving its permissions to only authorized users.
Mapped with various AWS services: It can map domain names to Amazon EC2 instances, S3 buckets, and other AWS resources.
53 traffic flow helps to manage traffic globally via various routing types. All these routing types can be easily combined with DNS Failover to enable various low-latency, fault-tolerant architectures.

How does this happen exactly?

A user opens a web browser and searches for www.mysite.com. This creates a DNS request for www.mysite.com
The DNS request is routed to a DNS resolver, usually managed by the Internet Service Provider (ISP).
The ISP DNS resolver forwards the DNS request to a DNS root name server as the first stop.
The DNS resolver then forwards the request to a top-level domain (TLD) nameserver corresponding to the .comdomain. One of the several hundreds or thousands of the name servers will respond with the Route 53 name servers associated with the www.mysite.com domain. The DNS resolver then caches the name servers for future use.
Out of the returned Route 53 name servers, the DNS resolver will forward the request to one of them.
The Route 53 name server will then look for a match or a www.mysite.com record in the hosted zone and retrieve the value. The value can be the Alias of a CloudFront distribution if it is a case of simple routing, a healthy nameserver, or sometimes a record corresponding to geolocation routing conditions.
The DNS resolver then finds the route to the DNS record or CloudFront IP that the user can use to access www.mysite.com and returns this value to the web browser.
Your web browser then sends a request to the IP address of the CloudFront distribution containing the website.
The CloudFront distribution will then serve the web page based on its content delivery settings from the cache or the origin server to your web browser.
www.mysite.com is then displayed on your web browser.

How Route 53 is priced

1. DNS zones The first 25 hosted zones charge is $0.50 per hosted DNS zone/month and then $0.10 for additional zones.
Policy records For every DNS name (such as "www.mysite.com"), the charge is $50 per Standard query, then $0.4 per million queries for the first billion queries/month, and then it charges $0.2 per million queries/month.
Latency-based routing queries The charge is $0.6 per million queries for the first billion queries/month. After that, it charges $0.3 per million queries/month.
Geo-based queries It charges $0.7 per million queries for the first billion queries/month. After that, it charges $0.35 per million queries/month.
Health checks There is no charge for the first 50 AWS endpoints. After that, it charges $0.5 / endpoint/month.
Domain registration For domains across different TLDs, AWS charges as per a price sheet.

Things to watch out for

Route 53 does not support DNSSEC: DNSSEC or Domain Name System Security Extensions is used by the Internet Engineering Task Force as a suite of extension specifications. It effectively secures the data exchanged in DNS in Internet Protocol networks.
Route 53 does not provide forwarding or conditional forwarding options for domains used in an on-premise network.

Because Route 53 is combined with other AWS services, it may become a single point of failure. This results in a significant problem for AWS Route 53 disaster recovery and other relevant issues.

Limited Route 53 DNS Load Balancing as Route 53 load balancing only provides basic load balancing capabilities because it lacks advanced policy support and enterprise-class features.

Route 53 can be pretty expensive for businesses using non-AWS endpoints. Users can also experience slight latency with Route 53 when queries are forwarded to external servers after contacting Amazon infrastructure.

Working with Route 53

Migrating your domain to Route 53

Option 1: Leave your domain name with your current registrar.
If you want to leverage Route 53 routing features but don't want to move your domain name, you need to give your registrar the new name server addresses you'll get from the Route 53 records upon creating a hosted zone. Once you have updated the NS records in your current DNS, Route 53 will ensure the routing of all new domain requests through its name servers, but this propagation can take some time, so be patient.

Option 2: Move your domain name to Route 53
When you decide to transfer your domain to Route 53, you will need to get the DNS record data from your DNS provider. You will then import this data to a Route 53 hosted zone and replace the registrar's name server records with AWS name servers that you get after creating Hosted Zones. Depending on your settings, changes usually take up to a day to reflect.

Route 53 hosted zone creation

With Route 53, you must create a Route 53 hosted zone. There are two types of hosted zones:

Public hosted zones are the most frequently used and specify how you want to route traffic on the Internet. Visit working with public hosted zones for more info.
Private hosted zones specify how you want to route traffic in an Amazon VPC (Virtual Private Cloud). Visit working with private hosted zones for more info.

How to create a Route 53 public hosted zone

To create a public hosted zone, open up the Route 53 dashboard from your AWS management console.
You can then enter the domain name, which becomes the name of the hosted zone, and select the type as a public hosted zone.

How to create a Route 53 private hosted zone
Creating a private zone starts in the same place; however, when you select private hosted zone, a new dialogue appears where you can choose the VPC or VPCs you want to route traffic to when someone enters the domain URL.

To configure Amazon Route 53 to route traffic to the S3 bucket
i.e., host a static site, we’ll do the following;

Get a domain name from a provider like GoDaddy or namecheap.com
Create a hosted zone in Route 53
Host a static website in an S3 bucket in the root domain
Create a subdomain bucket for redirect
Configure Route 53 to point to the S3 bucket.

Getting a registered domain name.
There are numerous domain name registrars available including Route 53. You can register a domain on Route 53 or use other providers available. I went with GoDaddy.com.

Create a Route 53 hosted zone
On the Route 53 console, click on Hosted Zones in the left sidebar menu. You should see a window similar to this. I already have a hosted zone but you might not have any.

Click on create a hosted zone and you will see the options below

Type the domain name similar to the one you registered above. Mine is named emmory.online . You can add a description then click on create hosted zone to create it.

It may take a few seconds for the zone to be created. Once it is created, you should see a similar window.

Since your zone is empty, you should see two records only. The NS and SOA record types. (I have selected them in the illustration). We will need the NS record.
Click on the NS record check box and a window should appear on the right side. Copy all the values under the Value section.

You will then update these values (all 4) in the nameserver section of your domain name provider where your domain is registered. I registered wth GoDaddy.com. Login on your Godaddy account > Select your profile > My products and Services > DNS > Nameservers and click use custom Nameservers then paste all the four you took from Route 53. When done, you should see something similar to this. Yours may look different but the premise holds.

You have now updated your domain to use Route 53 nameservers. Traffic and requests will use AWS provided nameservers.

Create a static hosting for the root domain in S3 bucket
You probably figured out that you need website files by now to have a website. You can get templates or create a static website from scratch by yourself. Either way, review the files you will need for your static website.

Create the root domain S3bucket

Create a bucket with your exact domain name. I named mine emmory.online since that’s the domain name.

Search for S3 in the AWS console. In the S3 console, click on Create bucket and add your domain name under the bucket name.
Disable Block all public access and check the I acknowledge... box. This will enable public access for the bucket contents. Then click on Create bucket.
The next step is to upload all your website files to the bucket (your-domain-name). To upload files, click Upload from the S3 bucket menu and select all the files and click on upload.

If you’d prefer a much shorter way than drag and drop. You can use theAWS cli from your terminal. Change your directory with cd /yourwebsite files directory and then type the following command
aws s3 cp . s3://<domain-name>

Attach a bucket policy to your bucket.
Earlier on, public access was enabled to the bucket. This is not always the recommended way and to fix it, you need to attach a bucket policy that controls access to your bucket and its contents.
From the bucket window, go to** permissions** then scroll down and find the bucket policy. Click on Edit and paste the following inside the bucket policy editor.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Stmt1405592139000",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": [
                "arn:aws:s3:::<domain-name>/*",
            ]
        }
    ]
}

Make sure to replace the with your bucket name. Click on Save changes.

Enable static website hosting.
On the S3 bucket console, go to the properties tab then scroll to the bottom to find Static website hosting and click on Edit.
Choose Enable **and specify the index.html file inside the **Document part and click on Save changes. You should see a Bucket website endpoint. If you click on the link, you should see your website.

We’ll need another bucket for website redirect.
Create another bucket but add _www. _as the name of the bucket. Simply create the bucket and leave all the default setting on.

Enable static hosting on the website as well. Except this time, choose Redirect requests for an object as the Hosting type. Enter your domain name as the Host name without the www. part then choose http as the protocol and click save changes.

The endpoint for this bucket should redirect you to your domain name when you click on it. You might get a This site can’t be reached page but that’s is purely intentional.

Next. Configuring Route 53 to point to the S3 bucket endpoint.

Create a record.
Go to the hosted zone you created earlier in step one and click on create record. Only the NS andSOArecord should be currently visible.

For Record 1

Leave Record name empty and enable Alias
For Route traffic to, choose Alias to S3 website endpoint from the dropdown.
For Choose Region, choose the region where your S3 bucket is created.
Under the Enter S3 endpoint, your bucket endpoint with a domain name should appear. If for some reason it doesn’t, copy your Website endpoint from here based on the region you create your bucket in.
You can turn off Evaluate target health. I did.

Click on Add another record at the bottom and repeat the same steps as before. Except, the record name as www.
Click Create records. You should get a similar window.

et voilà! that’s it.
You may also add an AWS ACM certificate to your website if it has the Not secure tag. The certificate is absolutely free.
You can now verify that your website is running as expected by going to your domain name. It might take a while for this to reflect so some things you might try including reducing the TTL for the records. Check out my website at emmory.online. I know, it needs a fixer upper.

Static Website Hosting with Amazon S3, CloudFront and CloudWatch metrics in 5 minutes or less

~\Chirchir — Sun, 24 Sep 2023 21:18:08 +0000

The AWS cloud platform provides an all-in-one managed solution ideal for hosting quick, secure, and reliable static and even dynamic websites. We’re going to use Amazon Simple Storage Service (S3), Amazon’s CDN service- CloudFront and their monitoring service-CloudWatch to deploy and serve a website. But first, an introduction.

What is Amazon S3?

Amazon S3(Simple Storage Service) is an object storage service that allows you to store unlimited objects and connect virtually all services to your bucket to serve, store and retrieve content over the internet. S3 provides a managed and scalable object storage solution for all data types from files to multimedia content and for this case, static website hosting.

What is CloudFront?

CloudFront is an AWS Content Delivery Network (CDN) service that lets users serve content globally with low latency, high transfer speeds and secure connection. CloudFront leverages AWS Edge Locations as part of the global infrastructure to cache and deliver content closer to users across the world so they can experience millisecond latency and smooth performance. also provided by AWS, it enables users to deliver content globally with low latency, high data transfer speed, and securely delivered. With CloudFront, you also enjoy SSL/TLS encryption for your website with the option to push metrics to CloudWatch for even finer control and monitoring of your environments.

The Plan

S3 will store static website files and media content.
A CloudFront distribution will serve the website to users across the world-the website is served through edge locations but the files are held in S3.
CloudWatch will provide a dashboard to monitor the website.

Host the static website on S3

There are tons of website templates online. You can find a template from bootstrapmade.com and customize it to your style needs. If you have a website already, that’s even better.

Create the S3 bucket

We will provision an S3 bucket that will store the website content including the HTML and CSS files and also the media files.

Go to S3 console and choose create bucket.
Click ‘Create Bucket’. Choose a globally unique bucket name and AWS region.
Follow the prompts to create your S3 bucket.
Untick “Block all public access” and acknowledge the change.

Since we want our static website accessible from the internet.
For now, we will enable public access but this is a security concern but we’ll fix it in a few.

That’s it, you don’t need anything else in this menu and can click ‘Create bucket’.
Once the bucket is created, click on its description to open it then choose Upload and upload all the website files.

Once the files are uploaded, go to the bucket homepage, go to properties tab and scroll down to find the “Static website hosting” section and enable it.
Choose "Host a static website".
Choose an Index document and an Error document. You can fill in “index.html” into both.

Since this bucket will be used to host a website, ensure to make you index.html document as the index document part.
Change any additional settings you want then click Save.

Note down endpoint URLs displayed for the bucket in the “Static website hosting” properties panel. (Endpoint URLs look like http://yourbucketname.s3-website-us-east-1.amazonaws.com.)
If you try to open the endpoint URL in your browser, you might get an access denied error, let’s fix that by editing the S3 Bucket Policies.

In the S3 bucket you just created, go over to Permissions. Then Bucket Policy. You need a bucket policy that will allow public website hosted on it. You can use the official AWS policy generator for these purposes, which can be found at: AWS Policy Generator If you choose to use the generator, choose S3 bucket policy as the Type of Policy. Principal will be “*” (without quotes), and Actions will be GetObject. The * here is a wildcard that means access for all requesters. The policy looks like:

{
 "Version": "2012-10-17",
 "Statement": [
  {
   "Sid": "PublicReadGetObject",
   "Effect": "Allow",
   "Principal": "*",
   "Action": [
    "s3:GetObject"
   ],
   "Resource": [
    "arn:aws:s3:::<BUCKET_NAME>/*"
   ]
  }
 ]
}

To find your ARN or Amazon Resource Name, scroll to the top of the window and you can find it written as
arn:aws:s3:::<bucket_name>.

Save to accept the changes and that’s all you need with S3 for now.

If the website works just by hosting on S3, why then do you need CloudFront? “Well, if you reload the endpoint link on your browser, your website has a 'Not Secure' tag. This is a red flag which means that your website is hosted but not secure. CloudFront allows you to serve your website and it’s contents securely.”

Configure CloudFront CDN

We’ll create a CloudFront CDN distribution linked to the S3 bucket so that anyone who accesses the distribution will be viewing the S3 bucket hosted static website securely, with millisecond latency.

Create CloudFront distribution

On the AWS Console search for and open CloudFront.
Click Create Distribution.
Under Origin, for Origin domain, choose the Amazon S3 bucket that you created previously. It should be part of the selection menu.
You should see an Origin settings page with many options and fields.

For the Origin Domain Name, you will need to paste the S3 endpoint URL from earlier. If you don’t have it, open the S3 console in another window, click on your bucket name, then click on Properties and scroll down to Static website hosting. Copy over the highlighted part of the Endpoint URL:

Skip the next parts because they involve a domain name and certificates.
For Bucket policy, select Yes, update the bucket policy.
For the settings under Default Cache Behavior Settings, under Viewer, set Viewer protocol policy to Redirect HTTP to HTTPS and accept the default values for the rest.

If you’d like to know more about cache behavior options, see Cache behavior settings in the Amazon CloudFront developer guide.

In the Web Application Firewall (WAF) section you can choose to either enable or disable AWS WAF security protections. This is a paid service and you can quickly rack up costs outside the free tier limits.
If you have an SSL certificate, you can add it under the Custom SSL Certificate for CloudFront SSL encryption setting.
Click Create Distribution at the very bottom of the page.
Provisioning the Distribution takes 10-20 minutes. Once it is provisioned (Status = Deployed, State = Enabled), you can test it by pasting the URL under Domain Name into your browser. You should see the website you uploaded into S3.

Now if you recall, you still have public access enabled on the S3 bucket, time to fix that. The CloudFront distribution setup should have given you a prompt to change the S3 bucket policy, copy the policy then go to the s3 bucket hosting the website and, in the permissions tab, choose edit button for the bucket policy section and paste the new policy.

{
    "Version": "2008-10-17",
    "Id": "PolicyForCloudFrontPrivateContent",
    "Statement": [
        {
            "Sid": "AllowCloudFrontServicePrincipal",
            "Effect": "Allow",
            "Principal": {
                "Service": "cloudfront.amazonaws.com"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::week20bucket/*",
            "Condition": {
                "StringEquals": {
                    "AWS:SourceArn": "arn:aws:cloudfront::035431961317:distribution/E240YKEWLBC6VJ"
                }
            }
        }
    ]
}

You might geta JSON syntax error, which is easy to fix; remove the old policy and it should all be good. If the error persists, choose confirm changes to get a link to a JSON syntax formatter.
Now go back to the CloudFront distribution and find the distribution link and open it on another browser window, it should now work. You should be able to view your website and its contents with a CloudFront URL that has a secure tag.

Set up CloudWatch Metrics for CloudFront

On the CloudWatch window, click on Alarms then create alarm
Click on Select Metric and type the name of the metric into the search box.
Choose the metric for the service you’re going to monitor (under CloudFront > Per-Distribution Metrics)
Click Select Metric.

Configure your thresholds. The Requests metric measures the number of requests made to your distribution. Major changes in this metric can signal issues in your application, such as errors in clients calling the distribution. The BytesDownloaded metric measures the number of bytes downloaded from your distribution. xxErrorRate is the percentage of responses in the 4xx range. A spike in this metric could suggest a changed API or moved resource resulting in bad requests or auth issues. Set this to 10% average limit. 5xxErrorRate measures the percentage of responses in the 5xx range. If your distribution is backed by servers and this metric spike, you likely have issues affecting your servers’ ability to respond to requests. Set this to 10% average limit.
Click on Additional Settings to choose how many datapoints to alarm on and what to do when data is missing (we recommend ignoring missing data and just keeping the previous state to keep alerts from flapping)
Click Create Alarm. Unfortunately, since CloudWatch only supports creating an alarm on a single metric, you’ll have to repeat the whole process for each service and metric combination. This can get incredibly time consuming and tedious.

And that’s it. You should now have a dashboard that shows all the relevant and custom metrics for your website. You can try reloading the website to see how the metrics dashboard changes.
You have just deployed a website on S3 and made it available globally through CloudFront CDN.