Recently I went out of storage for my homelab so I bought an used NAS (Synology DS214 play) to have some more capacities for [Proxmox](https://www.proxmox.com/de/ "Proxmox") Backups and OpenStreetMap. I still had a 1TB hdd lying around at home, which I now use for proxmox backups. 

To have some redundancy (and to learn something new) I decieded to copy the Proxmox backups to the cloud, in particular to an Azure Storage Account with [AzCopy](https://learn.microsoft.com/en-us/azure/storage/common/storage-use-azcopy-v10) and in the following I will describe with more details how I was able to do it.

Overall this article will cover the following informations:
- Creating an Azure Storage Account
- Getting started with AzCopy
- Creating a bash-script to copy the Proxmox backups to an Azure Storage Container

## Creating an Azure Storage Account

First off all you need an active Azure subscription and an storage account to be able to store your backups. In the [Azure Portal](https://portal.azure.com "Azure Portal") you can search for the service "Storage Accounts" which you will need.

![azure storage account.png](/uploads/azure_storage_account_e81efc2682.png)

In the service "Storage Accounts" you can create a new storage account. For the storage account you will need 
- an active azure subscription,
- a ressource group (create one if you don't have one it, e.g. RG-HOMELAB),
- a storage account name,
- selecting a region and 
- selecting redundancy (e.g. LRS;)
- Access tier "cold" (See Advanced)

![storage account_basics.png](/uploads/storage_account_basics_e82f1d8a4d.png)
![storage account_advanced.png](/uploads/storage_account_advanced_02f6609c40.png)

You can keep all the other settings as default. After your Storage Account has been deployed you can add a lifecycle rule from "Lifecycle Management" which will move files from the "cold" access tier to the archive storage. 

![storage lifecycle management.png](/uploads/storage_lifecycle_management_e113a6efb8.png)

For example I created a rule which moves all new files after one day to the archive storage tier.

![storage lifecycle lifecycle rule.png](/uploads/storage_lifecycle_lifecycle_rule_85a074cae0.png)

![storage lifecycle lifecycle rule 2.png](/uploads/storage_lifecycle_lifecycle_rule_2_5486e872ee.png)

By storing files in archive storage instead of in the regular "cold" access tier you can actually save about 82%. But keep in mind that accessing data in the Archive storage is more expensive than in the cold (or any other) storage tier.

Also you could create another rule which will for example will delete all all blobs which were created 365 days ago.

![storage pricing.png](/uploads/storage_pricing_8998b65a68.png)

Please have a look at [https://azure.microsoft.com/en-us/pricing/details/storage/blobs/](https://azure.microsoft.com/en-us/pricing/details/storage/blobs/ "Azure Storage Pricing") for uptodate Azure Storage pricing.

After the storage account has been configured you will need to create a Container where the actual files will be stored.
Go to  "Data storage" -> "Containers" and create a Container.
![create storage container.png](/uploads/create_storage_container_8ee34fe39e.png)
Again name it however you want.

Due to the fact that the current version of AzCopy V10 does not support Azure AD authorization in cron jobs I used an SAS token to be able to upload files to the container. You can create a SAS token in the container at "Shared access tokens".

![storage shared access token.png](/uploads/storage_shared_access_token_1646ebf346.png)

For the Shared access token you will need to select the permissions for Add/Create/Write and select an expiry date for security reasons. Then you can generate the SAS token and URL. Copy that **Blob SAS URL** because you will need it for the upload script.

## Getting started with AzCopy

> AzCopy is a command-line utility that you can use to copy blobs or files to or from a storage account. This article helps you download AzCopy, connect to your storage account, and then transfer data. (https://learn.microsoft.com/en-us/azure/storage/common/storage-use-azcopy-v10)

To get AzCopy for Linux you have to download a tar file and decompress the tar file anywhere you like. You can then just use AzCopy because it's an executable file, so nothing has to be installed.

```bash
#Download AzCopy
cd ~
wget https://aka.ms/downloadazcopy-v10-linux
 
#Expand Archive
tar -xvf downloadazcopy-v10-linux
 
#(Optional) Remove existing AzCopy version
rm /usr/bin/azcopy
 
#Move AzCopy to the destination you want to store it
cp ./azcopy_linux_amd64_*/azcopy /usr/bin/

# Remove Azcopy from home
rm -r downloadazcopy-v10-linux
rm -r azcopy_linux_amd64_10.16.2/

```

By adding the azcopy file location as system path you can just type azcopy from any directory on your system.
You can add it to your system path with:

```bash
nano ~/.profile
```
and then adding these lines:

```bash
export PATH=/usr/bin/azcopy:$PATH
```

Lastly, update your system variables:

```bash
source ~/.profile
```

## Creating a bash-script to synchronize the Proxmox backup directory to an Azure Storage Container

The only piece missing now is the script which will upload the the Proxmox backup files to the previously created azure storage container after the backup task has finished. 
For copying the backups to Azure we will use azcopy **copy** because acopy uses less memory and incurs lower billing costs because a copy operation does not need to index the source or destination before moving files in comparison to azcopy **sync**.
Azcopy also compares file names and last modified timestamp to only upload new or changed files to the storage container, which overall will reduce bandwidth usage and it will work perfectly with the previously created lifecycle rule.

For automatically starting the upload after the backup has finished  we can use a hook script for vzdump. Therefore you need to add the following line to the end of the "/etc/vzdump.conf" file.
```bash
script: /etc/your-custom-script.sh
```
Afterwards you can create the script which will upload the files with:
```bash
cd ~
mkdir scripts
cd scripts
nano upload-backups-to-azure.sh
```
Then copy paste the following content into the file and replace the content for src with the location of your dumps. Note that there is "/*" at the end of src so that only the files inside the directory will be copied. Also replace token with the **Blob SAS URL**.

```bash
#!/bin/bash
# Script to upload Proxmox backups to Azure Storage

src="/mnt/pve/xyz/dump/*"
token="Blob SAS URL"

dobackup(){
  echo "Uploading Proxmox backups from $src to Azure..."
  azcopy copy "$src" "$token" --overwrite=false
  echo "Finished Uploading!"
}

if [ "$1" == "job-end" ]; then
  dobackup
fi

exit 0
```

Close the file and make it executable for the user with:

```bash
chmod +x ~/scripts/upload-backups-to-azure.sh
```

Now the next time your backup task has finished the files will be automatically uploaded to your Azure storage container.
Due to the  hook script you can check the status of the copy process in the proxmox ui.

How to copy your Proxmox backups with AzCopy to Azure Storage Containers

With Google Cloud (Build) you can automate your whole workflow from building your Gatsby site up to deploying your site to Firebase hosting.

**What will you need?**

+ [Firebase Hosting](https://firebase.google.com/products/hosting "Firebase Hosting")
+ [Cloud Build](/cloud-google/cloud-build "Cloud Build")
+ [Cloud Scheduler](/cloud-google/scheduler "Cloud Scheduler") (optional)

## Firebase Hosting

To set up Firebase you will need an Google Cloud Account which has billing enabled and at least one project.
You can add the Firebase SDK with:

```
npm install --save firebase
```

and configure it with

```
firebase init
```

In the process you can setup a new project which will create a new ```.firebaserc``` file if it doesn't exist yet and enable **Hosting**.

![Firebase_init_1.png](/uploads/Firebase_init_1_c3dd56b33d.png)

As public directory you have to set your **public** folder. After you have set your public folder you can reject all oncoming messages.

![Firebase_init_2.png](/uploads/Firebase_init_2_224ab0a007.png)

> You can also have a look at the [Google Firebase Docs](https://firebase.google.com/docs/cli#install-cli-windows "Google Firebase Docs") for setting up Firebase.

In the end it will also create a **firebase.json** where you can copy/paste the following to optimize your hosting for a Gatsby site.

```js
{
  "hosting": {
    "public": "public",
    "ignore": [
      "firebase.json", 
      "**/.*", 
      "**/node_modules/**"],
    "headers": [
      {
        "source": "**/*",
        "headers": [
          {
            "key": "cache-control",
            "value": "cache-control: public, max-age=0, must-revalidate"
          }
        ]
      },
      {
        "source": "static/**",
        "headers": [
          {
            "key": "cache-control",
            "value": "public, max-age=31536000, immutable"
          }
        ]
      },
      {
        "source": "**/*.@(css|js)",
        "headers": [
          {
            "key": "cache-control",
            "value": "public, max-age=31536000, immutable"
          }
        ]
      },
      {
        "source": "sw.js",
        "headers": [
          {
            "key": "cache-control",
            "value": "cache-control: public, max-age=0, must-revalidate"
          }
        ]
      },
      {
        "source": "page-data/**",
        "headers": [
          {
            "key": "cache-control",
            "value": "cache-control: public, max-age=0, must-revalidate"
          }
        ]
      }
    ],
  }
}
```
When you have build your Gatsy site and **public** folder is present you can upload it to your Firebase Hosting with:

```
firebase deploy
```

If you want to use your custom domain (for example gis-netzwerk.com) you have to go to Hosting in the Firebase console where you will find DNS-records to point your domain to your Firebase Hosting.
You can also create a second domain (for example www.gis-netzwerk.com) to redirect automatically to your root domain.

In your project settings you can find your Firebase configurations which look like:

```js
const firebaseConfig = {
  apiKey: "apiKey",
  authDomain: "{.firebaseapp.com",
  databaseURL: "https:// projectId.firebaseio.com",
  projectId: " projectId",
  storageBucket: " projectId.appspot.com",
  messagingSenderId: "1",
  appId: "2",
  measurementId: "G-123"
};
```

You probably want to save these as environment variables.

## Cloud Build

To create a CI-/CD-Pipeline you have to activate Cloud Build for your account. The console itself is quite clear in comparison to AWS CodeBuild.
You will see Dashboard which is displaying some basic informations, the history of your Cloud Builds, Triggers and Options.

You just will have to create a new trigger which will trigger a new build everytime new content is pushed to your linked GitHub repository..

First of all you have to connect your repository. After that you can create the trigger.

![Cloud-Build_Trigger-settings.png](/uploads/Cloud_Build_Trigger_settings_c6be399330.png "Cloud-Build_Trigger-settings.png")

Important options are:
+ Event: **Push to branch**
+ Branch: **^master$** (or whatever branch you want to build)
+ Cloud Build Configuration file: **cloudbuild.yaml**

After that you can create all environment variables as **Substitution variables**.
You will notice that all variables have to start with an underscore.
Because of that we will need a small workaround in the cloudbuild.yaml configuration file.

For now you can just create your substitions variables and add the underscore to your default variable names.

To be able to deploy via firebase you will need to authorize Firebase with a '$_TOKEN'.
You can retrive this token on your local machine with_
```
firebase login:ci
```

A new page will be opened in your prefered browser where you will have to login with your Google account to get the token.
Once you have the token you can also add it as substition variable.
```
_TOKEN : {TOKEN VALUE}
```

If you have created all substitution variables you can check again if they are inserted correct and create the new trigger.

### Cloudbuild.yaml

Cloud build needs the cloudbuild.yaml to know what it should do.
If you have inserted the path like above mentioned you will need a cloudbuild.yaml in your root directory.

You can copy the following into it:
```js
steps: 
# Install dependencies
  - name: node:10.16.0
    id: Installing dependencies...
    entrypoint: npm
    args: ["install"] 
    waitFor: ["-"] # Begin immediately

# Install Firebase   
  - name: node:10.16.0 
    id: Installing Firebase...
    entrypoint: npm 
    args: ["install", "firebase-tools"]
    waitFor:
      - Install dependencies...

# Create file with env-variables
  - name: node:10.16.0
    id: Creating Envirnonment variables...
    entrypoint: npm
    args: ["run", "create-env"]
    env:
    - "CLIENT_EMAIL=${_CLIENT_EMAIL}"
    - "PRIVATE_KEY=${_PRIVATE_KEY}"
    - "MAIL_CHIMP=${_MAIL_CHIMP}"
    - "GA_ID=${_GA_ID}"
    - "GA_VIEW_ID=${_GA_VIEW_ID}"
    - "IG_TOKEN=${_IG_TOKEN}"
    - "FIREBASE_API_KEY=${_FIREBASE_API_KEY}"
    - "FIREBASE_APP_ID=${_FIREBASE_APP_ID}"
    - "FIREBASE_AUTH_DOMAIN=${_FIREBASE_AUTH_DOMAIN}"
    - "FIREBASE_DB_URL=${_FIREBASE_DB_URL}"
    - "FIREBASE_MEASUREMENT_ID=${_FIREBASE_MEASUREMENT_ID}"
    - "FIREBASE_MESSAGE_SENDER_ID=${_FIREBASE_MESSAGE_SENDER_ID}"
    - "FIREBASE_PROJECT_ID=${_FIREBASE_PROJECT_ID}"
    - "FIREBASE_STORAGE_BUCKET=${_FIREBASE_STORAGE_BUCKET}"
    - "GATSBY_EXPERIMENTAL_PAGE_BUILD_ON_DATA_CHANGES=true"
    waitFor: ["-"] # Begin immediately

# Gatsby build
  - name: node:10.16.0
    id: Building Gatsby site...
    entrypoint: npm
    args: ["run", "build"]
    waitFor:
      - Installing dependencies...
      - Creating Envirnonment variables...

# Deploy
  - name: node:10.16.0 
    id: Deploying to Firebase...
    entrypoint: "./node_modules/.bin/firebase" 
    args: ["deploy", "--project", "$PROJECT_ID", "--token", "$_TOKEN"]
    waitFor:
      - Installing Firebase...
      - Building Gatsby site...
    
timeout: 30m0s
```
The cloudbuild.yaml is basically divided into six parts which will
+ Install dependencies,
+ Install Firebase,
+ Create file with env-variables,
+ Build the Gatsby site and
+ Deploy it to Firebase

As you can see you will create a file with the environment variables which will map the substitutions variables with your "default" variables.
Everything else should be pretty self-explanatory.

> Cloud Build will timeout the build by default after 10 minutes. So if your build is gonna take longer you will have to set up a custom timeout like in the cloudbuild.yaml above. You can also set a timeout for each step.

Another import point is that you will have to add the Plugin for Google Analytics Reporting Api as dynamic plugin like for example the following because otherwise you will get errors during your build.
```js
if (
  process.env.CLIENT_EMAIL &&
  process.env.PRIVATE_KEY &&
  process.env.GA_VIEW_ID
) {
  const startDate = new Date()
  startDate.setMonth(startDate.getMonth() - 3)
  dynamicPlugins.push(
    /*{
      resolve: `gatsby-plugin-guess-js`,
      options: {
        GAViewID: process.env.GA_VIEW_ID,
        jwt: {
          client_email: process.env.CLIENT_EMAIL,
          private_key: process.env.PRIVATE_KEY.replace(/\\n/g, "\n"),
        },
        period: {
          startDate,
          endDate: new Date(),
        },
      }
    },*/
    {
      resolve: `gatsby-source-google-analytics-reporting-api`,
      options: {
        email: process.env.CLIENT_EMAIL,
        key: process.env.PRIVATE_KEY.replace(/\\n/g, "\n"),
        viewId: process.env.GA_VIEW_ID,
        startDate: `2009-01-01`,
      }
    }
  )
}

module.exports = {
  plugins: [
    plugins...
  ].concat(dynamicPlugins),
};

Due to the fact that Code Build uses Linux machines small and capital letters are important (Windows doesnt care).
That means if you import a component like
```js
import MyComponent from "../Mycomponent"
```
and the actual folder name is ```MyComponent``` your build will fail.

## Speeding up your builds

+ **Image optimization**

If you aren't using preoptimized images yet you should consider to crop, resize images etc. **before** you will build the site because it can basically save a lot of time (depending on the amount of images).

Before i optimized my images a build on Google Cloud took about ~ 1800 sec.
After i optimized all my images for posts with Python ([Image optimization with Python](/articles/scaling-and-cropping-images-using-python "Image optimization with Python")) the build time went down to ~ 620 sec. So actually just a third.

## Set Cloud Scheduler (optional)

With Cloud Scheduler you can trigger a build automatically after a specific time.
The first 3 jobs a month a free and after that you have to pay $0.10 for every job after that.

(You can also use Cloud Scheduler with your default trigger (Push to branch) or without).

The trigger you created before has an ID and with a POST request you can start the trigger anytime you want.
To get the ID of the trigger you have to open the Cloud Shell, type ```gcloud beta builds triggers list``` and search for **id**. Copy that.

The URL for the POST request looks like (without []):
```
https://cloudbuild.googleapis.com/v1/projects/[PROJECT_ID]/triggers/[TRIGGER_ID]:run
```
Now you have to create a new job in Cloud Schedule.

![Cloud-Scheduler-Settings.png](/uploads/Cloud_Scheduler_Settings_1d117b6db6.png)

```
0 3 * * *
```
will trigger a build every day at 3 am MESZ. 

The URL for the POST request looks like (without []):
```
https://cloudbuild.googleapis.com/v1/projects/[PROJECT_ID]/triggers/[TRIGGER_ID]:run
```

In Text you will need
```json
{
  "branchName": "master"
}
```
and you will authorize the job with your service account.



Build and deploy your Gatsby site with Google Cloud Build to Firebase

With the free [contingent for AWS](https://aws.amazon.com/en/free/free-tier/ "contingent for AWS") you always get an active [AWS code pipeline](https://aws.amazon.com/codepipeline/?did=ft_card&trk=ft_card "AWS Codepipeline") per month and [100 minutes AWS codebuild](https://aws.amazon.com/codebuild/?did=ft_card&trk=ft_card "100 minutes AWS codebuild" ) per month.

So you can set up a continuous integration and continuous delivery pipeline for free or with more than 100 build minutes a month for relatively little money, which triggers a build with every push to a GitHub repository whoch will be automatically deployed to S3 and optionally also invalidate CloudFront Cache.

## CodeBuild

First of all you need a new build project in CodeBuild.
In the project configuration you can assign a name for it and select GitHub as the source provider under **Source**.

Depending on whether the repository is public or not, you then select "Public Repository" and enter the repository URL or you link your GitHub account and give CodeBuild the necessary rights to access the repository.

An environment image must now be selected under **Environment**. For GatsbyJS this would be a "managed image" and the operating system "Amazon Linux 2". "Standard" is selected as the runtime (s) and "aws / codebuild / amazonlinux2-x86_64-standard: 2.0" as the image.

![codebuild_umgebung.png](/uploads/codebuild_umgebung_e32ebcd3d2.png)

Now a new service role can be created automatically (which is required) so that CodeBuild has the necessary rights for the AWS account.

> This service role can also be assigned rights for CodePipeline, so that this service role can be used for CodeBuild and CodePipeline.
If environment variables are used, these can be specified under "Additional configuration" in the environment. You can also make sure that "3GB RAM, 2vCPUs" is really selected, since only this option is included in the free contingent.

**Buildspec** now uses a buildspec file in YAML format. For a Gatsby site this should somehow look like the following:
```sh
version: 0.2
phases:
    install:
        runtime-versions:
            nodejs: 12
        commands:
            - 'touch .npmignore'
            - 'npm install -g gatsby'
    pre_build:
        commands:
            - 'npm install'
    build:
        commands:
            - 'npm run build'
    post_build:
        commands:       
            - 'find public -type f -regex ".*\.$htm\|html\|txt\|text\|js\|css\|json$$" -exec gzip -f -k {} \' ## sofern cloudfront nicht automatisch die dateien komprimiert
artifacts:
    base-directory: public
    files:
        - '**/*'
    discard-paths: no
cache:
    paths:
        - '.cache/*'
        - 'public/*'
```

The buildspec.yml file only needs to be placed in the root directory so that CodeBuild can find it.
In addition, the build script must of course still be available in "package.json".

```js
"build": "gatsby build",
```

The default settings can be retained under **Artifacts**.
With CloudWatch you have the possibility to save logs for CodeBuild in an S3 bucket.

> There may be additional costs!

If all settings have now been entered correctly, the build project can be created.
The only thing missing now is the code pipeline that triggers a build and deployed it in the S3 bucket.

## CodePipeline

For this you switch to CodePipeline and create a new pipeline in which a name and a service role are selected first.

At Source you can now log in with a GitHub account and link the respective repository with a branch.
You now have two options to trigger a build.

+ GitHub-Webhooks and
+ AWS CodePipeline

Then you choose the build provider "AWS CodeBuild" and the previously created project or (if you have not already done this) create a new project.

After a build, the public/ folder can also be automatically deployed to an S3 bucket with AWS CodeDeploy.
_Alternatively_ you can also skip this step and [gatsby-plugin-s3](https://github.com/jarizhttps://www.gatsbyjs.com-plugin-s3 "gatsby-plugin-s3"), which also optimizes caching.

```ssh
npm i gatsby-plugin-s3
```
bzw.
```bash
yarn add gatsby-plugin-s3
```

Now the configuration in gatsby-config.js and the deployment script are missing

```js
plugins: [
  {
      resolve: `gatsby-plugin-s3`,
      options: {
          bucketName: 'my-website-bucket'
      },
  },
]
```
```js
"scripts": {
    ...
    "deploy": "gatsby-plugin-s3 deploy --yes"
}
```
The deployment script "npm run deploy" must then of course be added to the buildspec file under post-build commands.
The CodePipeline should now look something like this:

![CodePipeline.png](/uploads/Code_Pipeline_b8acf52436.png)

Experience shows that a build for around 100 pages takes around 10 minutes if you have some pictures per page.

Every time CodePipeline detects a push to the GitHub repository, a build is automatically triggered and made available on an S3 bucket.

With ```aws cloudfront create-invalidation --distribution-id DISTRIBUTION_ID --paths / * ``` the CloudFront cache can also be invalidated.

GatsbyJS with CI/CD Pipeline via Codebuild 

With [AWS](https://aws.amazon.com/ "AWS") (and in particular the [free AWS contingent](https://aws.amazon.com/en/free/ "free AWS account")) you have the option of a static website with a custom domain for a few Hosting cents a month including CDN via CloudFront and CI / CD integration.

Before I switched completely to AWS, I had a common shared hosting option that cost me around € 72 a year. With this option I had
+ 250 GB SSD storage space,
+ free unlimited traffic,
+ 6 domains included,
+ 250 GB SSD mail storage space,
+ 25 MySQL databases,
+ and, and, and.

On the whole, much more than I need to run my static [GatsbyJS](https://www.gatsbyjs.com/) website.

So why shouldn't I only use and pay for resources that I ultimately need and also get some cloud computing experience?

## Creating S3-Buckets 

The basis for hosting on AWS is formed by [S3 Buckets](https://s3.console.aws.amazon.com/s3/home "S3 Buckets"). 
Buckets are "containers" on the web where you can save files.
In order for redirects from subdomains such as **www.mxd.codes** to **mxd.codes** to work, you need a bucket for each domain.

First of all, you create an S3 bucket for the root domain. In my case, the bucket name is the domain name mxd.codes and you select a region (for example EU (Frankfurt)).
The default settings can be kept under Options, unless you want to save different versions or access protocols.
So that everyone can access the website content later, remove the tick that is present by default at "Block *any* public access", check the bucket settings again and finally create it.

In each bucket you can or should enter a bucket policy that further defines access.
To do this, click on the name of the bucket and go to "Permissions" -> "Bucket Policy".

The following guideline must then be saved for public access.
```json
{
    "Version": "2008-10-17",
    "Statement": [
        {
            "Sid": "AllowPublicRead",
            "Effect": "Allow",
            "Principal": {
                "AWS": "*"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::mxd.codes/*"
        }
    ]
}
```
**"mxd.codes" has to be replace with your bucket name!**

If everything was done correctly, the permissions should now look something like this:

![S3 Bucket Richtlinie](/uploads/bucket_richtline_d32ff17da6.png)

In the bucket settings you have to activate the "hosting a static website" and specify an index document and an error document.
For GatsbyJS that would be **index.html** and **404.html**.

![S3 Bucket Hosting](/uploads/bucket_hosting_6f40697460.png)

Now the S3 bucket for the subdomain **www.mxd.codes** is still missing.
So create a new bucket with the name of the subdomain **www.mxd.codes** with public access and add the bucket policy.

In the settings for "hosting a static website" you use "redirect requests" and enter the target bucket **mxd.codes** and you can enter **https** as a protocol, because later on the content of the static website is delivered via CloudFront, which can be encrypted with SSL certificates.

![S3 Bucket Redirect](/uploads/bucket_redirect_740544f6d5.png)

The buckets are now created and correctly configured for the operation of a static website including redirect.


## CloudFront Distributions

With the free AWS contingent, 50 GB of data transfer can be burned per month in Cloudflare.

With a page size of generous 4 MB, this is enough for 12,500 page views per month and should therefore be more than sufficient for a website with average traffic. So why not take a free CDN with you?

If the costs incurred after the free year should deter someone, you still have the option to switch to another CDN provider such as [CloudFlare](https://www.cloudflare.com "CloudFlare").

At [CloudFront](https://console.aws.amazon.com/cloudfront/ "CloudFront") you have to create a web distribution for **each** bucket.
As the origin domain name, a bucket can **not** be selected from the dropdown list, but the end point of the bucket from S3 must be copied.

![Cloudfront Origin](/uploads/cloudfront_origin_f1e2731789.png)

In the distribution for the bucket **mxd.codes**, for example "mxd.codes.s3-website.eu-central-1.amazonaws.com" is specified as origin.
"Origin ID" will then be filled in automatically. In "Viewer Protocol Policy" **Redirect HTTP to HTTPS** is selected because users should only be able to access the website via HTTPS.  "Compress Objects Automatically" **Yes** can be selected, so that CloudFront will zip all files automatically.
Under "Alternate Domain Names (CNAMES)" you have to specify the bucket for the root domain for the distribution for the root domain. For example mxd.codes

At "SSL-Certifacte" you can now create for the two domains **mxd.codes** and **www.mxd.codes** two free Amazon SSL certificate via the [Certificate Manager (ACM )](https:/https://aws.amazon.com.amazon.com/en/certificate-manager/ "Certificate Manager (ACM)"). To do this, add your two domains in ACM.

![ACM Domain](/uploads/acm_domain_ee3a548091.png)

You can now have this validated using a DNS or email method. If you have included your domain in Route 53, you can do it more or less automatically by simply following the instructions.

Back in the CloudFront Distribution Creation you only have to specify a "Default Root Object". -> index.html
If you don't do this, CloudFront always shows an "Access Denied" message in XML format when you access your domain (atleast that was my case).

Finally, the distribution must of course still be activated under "Distribution State".

First distribution finished. The same procedure now for the subdomain **www.mxd.codes** with the corresponding "Origin Domain Name" (**Bucket end point!**)

_This can take up to 20 minutes_
(If you want to clear your CloudFront cache and have already installed AWS CLI, you can do this with the following command:

```shell
aws cloudfront create-invalidation --distribution-id DEINE_DISTRIBUTION ID --paths "/*"
```

In the meantime, you can create the redirects for Cloudfront in Route 53.

## Route 53 DNS settings

In [Route 53]("Route 53") you need a hosted zone (= 0.50€ per month). Then A (and provided that in the CLoudFrontDistribution IPv6 is
activated (which it is by default), as well as an AAAA) data record can be created.

That means you basically need 4 "alias" data sets:
+ mxd.codes A "CloudFront URL for root domain"
+ mxd.codes AAAA "CloudFront URL for root domain"
+ www.mxd.codes A "CloudFront URL for subdomain"
+ www.mxd.codes AAAA "CloudFront URL for subdomain"

Exceptionally, you can select the CDN url from the dropdown list.
With "Routing Guideline" and "Assess the state of the target" you can leave the default settings, unless you want to experiment.

Now if you wait a little you should be redirect from
+ http://wwww.mxd.codes,
+ https://wwww.mxd.codes,
+ wwww.mxd.codes,
+ http://mxd.codes and
+ mxd.codes
to **https://mxd.codes** .


Cloud

How to copy your Proxmox backups with AzCopy to Azure Storage Containers
Max DietrichMax Dietrich

Build and deploy your Gatsby site with Google Cloud Build to Firebase
Max DietrichMax Dietrich

GatsbyJS with CI/CD Pipeline via Codebuild
Max DietrichMax Dietrich

Host a static website with your own domain, AWS S3 and CloudFront
Max DietrichMax Dietrich

Cloud

How to copy your Proxmox backups with AzCopy to Azure Storage ContainersMax DietrichMax Dietrich

Build and deploy your Gatsby site with Google Cloud Build to FirebaseMax DietrichMax Dietrich

GatsbyJS with CI/CD Pipeline via Codebuild Max DietrichMax Dietrich

Host a static website with your own domain, AWS S3 and CloudFrontMax DietrichMax Dietrich

How to copy your Proxmox backups with AzCopy to Azure Storage Containers
Max DietrichMax Dietrich

Build and deploy your Gatsby site with Google Cloud Build to Firebase
Max DietrichMax Dietrich

GatsbyJS with CI/CD Pipeline via Codebuild
Max DietrichMax Dietrich

Host a static website with your own domain, AWS S3 and CloudFront
Max DietrichMax Dietrich