In this project based on a real-world scenario, I acted as a Cloud Specialist to implement a solution to handle incoming traffic accessing the main page of an application available in 2 regions: Finland and United States.

The prerequisites established were to create a 100% Serverless architecture with high global availability, present in two distinct continents so that, in case a Failover is needed from one continent to the other, the application in Production running on the Cloud Run service and stored in Containers is always available.

In addition, to distribute traffic intelligently and based on the proximity and location of the end user, once the client requests access he will be directed to the home page that is geographically closest.

Using the gcloud CLI, the application has been implemented as a docker image. The Google Cloud Run service will then automatically push the docker images to a new Artifact Registry in Google Cloud. Although the images are hosted in a US region, they are available for use in any region worldwide. We can proceed now to deploy the primary instance of the application

The application is now running in containers in both EU and US regions. Each one is associated with its own URL.

Primary — https://appkidsflixfinland-910998002388.eu-north2.run.app

Secondary — https://appkidsflixusa-910998002388.us-central1.run.app

The application is a media site similar to Netflix, called KidsFlix. It will provide content tailored for children based in different regions.

With both instances up and running. Next step is to deploy a load balancer to handle the incoming requests. The load balancer should redirect requests to the instance closest to the client. This way, requests are served with the lowest latency possible. The routing should be based on geographical proximity to the load balancer.

The load balancer is set up to serve requests. To properly test this out, there are two general options

Single user — One person can use a proxy of some sort to forward requests in such a way that the load balancer will redirect it to the specific region.

Multiple users — Different people that are within each region can initiate requests to the load balancer.

This article will reference the results for the first one.

A VPN tunnel was used to forward the request to the EU region to simulate a client in that area, so that the primary instance would be served back to the client. Browsers like Opera, provide this capability out of the box. See below:

Here you can see that from the US, I was able to reach the instance in Europe.

To test access to the other instance, it is just a matter of disabling the VPN connection. Since I am already located in the US, the request was forwarded to the US instance.

This article was a demonstration of the Google Cloud Run service. A simple web application was containerized and deployed in two separate regions. A load balancer was deployed to provide routing of requests to the two instances. Due to the nature of the application, the routing was designed to forward requests based on geographical location. The application contains content tailored for users that reside in the configured regions.

For other use cases, load balancers are used to provide fault tolerance in the event that the primary instance becomes unresponsive. There are different operating modes for the failover

• Active-Active — Both instances are up and running
• Active-Standby — Primary instance is running and serving requests, while the standby instance is online, but is not open to requests

This was a project showcasing the ability to deploy an application through a managed service with Google Cloud Run. Additionally, it leveraged a multi-region deployment with the use of an application load balancer. The Google Cloud Run service will create a docker image, and host it in an registry automatically, preparing it for deployment.

This project demonstrated extended use of gcloud CLI, which performs the same steps that could be done in the Google Cloud console. This method of configuration lends itself to automation, which can provide the ability to deploy multiple instances of this application stack with consistency. Additionally, the code can be added to version control, to help with on-going maintenance.

Lastly, this project showcased the load balancing service. This enabled the ability to respond to requests based on geographical location. For this use case, its main purpose was to redirect users to content tailored for them. For others, it can provide fault tolerance with a similar configuration.

In this project based on a real-world scenario, I acted as a Cloud Expert in the deployment of a Web Application to automate the HR onboarding process. By filling out a form, the user is created in the Training Portal in a fully automated way.

To deploy this solution, I used a Moodle image available on GCP Marketplace, where the REST API had been enabled, running on Compute Engine, front-end on Cloud Storage, and the back-end on Cloud Run.

I deployed the back-end using Python Flask using Cloud Functions, 100% Serverless. Then, I deployed the front-end using HTML/CSS/JS/BS on Cloud Storage to store the static files of the Web Application.

This is the second portion of the Moodle project. As a base, it currently has a home page that all employees will see, and one course. In this section, you will see further customization of the Moodle app to add a backend implemented as a serverless function, along with a separate frontend that will be accessed by a course administrator. As a reminder, in this scenario, the Moodle application will be used as a training system at a company.

We’ll start with the backend. It will be a new webservice in Moodle

Next, a protocol is selected to enable API access

The webservice is set up to be integrated with a serverless function.

As a best practice, it is proper to set a webservice to be controlled by designated user account. This prevents unauthorized access by malicious actors and protect the backend of the Moodle application.

As with any user account, a password is set to secure it. For production environments, there are two schools of thought;

• Set an expiration date for the access key. This is for security purposes to prevent malware from retaining access to production resources. Risk is that production workloads can be disrupted if someone forgets to rotate the token
• Not setting an expiration, and having an external tool or other automation perform the token rotation. This usually means a secondary account would be created to perform the token rotation on the first. This would spread the risk of compromise across two accounts, and add maintenance overhead.

I went with the expiration route, as this is what I’ve done in the past.

The webservice was successfully created. To validate it, an API call was triggered from the GCP Cloud Shell using curl against the endpoint.

With this in place, now we can proceed to implement the next component of the backend. A serverless function to call the same endpoint that was just validated, using a python script.

The serverless function was created successfully, moodleusercreate. As of this writing, this service got migrated to the Cloud Run service. This is function considered to be Generation 2 (aka ‘Gen 2’). Legacy functions that were created before the move are Generation 1 (aka ‘Gen 1’). Logs show the function being deployed.

The function is assigned a URL that will be used to pass an incoming request, and process the operation defined the python code. In this case, the code is going to call the API endpoint to create a new user.

You now see a successful trigger of the function. This was done via the GCP cloud shell, using the curl command. The logs show how the function was called, and what the response was (200 — success). In the cloud shell the response was a human-readable message. In this case, since the operation was obvious, creating a new user, this would have been enough to confirm the API worked properly. The logs show additional detail, in this case, the data that was added to the database

In the image above, you see a portion of the python code that makes up the core of the serverless function. The main pieces to take note of here is the following:

• Python function that takes in a person’s name and email address as parameters
• Python code retrieves the environment variables from GCP to retrieve the access token and IP address to establish a connection to the server
• Python code triggers the serverless function, and passes the inputs to the API endpoint (user name and email)

With the serverless function fully established, the next step is to add the secondary frontend for use by the HR administrator. The main purpose is to enable an HR admin to register new hires to the training system. This way, the user has access to training materials necessary to get fully onboarded.

At this point, the frontend service is fully configured. This is essentially a static website based on a cloud storage bucket. This website will integrate with the Moodle application. Trainees would log in (once they’ve been registered) and select courses to complete. This front end would trigger the same serverless function that was set up in the previous section.

Now, the system is fully implemented:

1. Moodle application deployed from the Marketplace
2. Moodle application customized with company logos, course added, and backend services
3. Moodle application integrated with a GCP serverless function
4. Moodle application extended with another integration to cloud storage bucket

This is an example of a cloud-native application that provides a training portal to a company to assist in onboarding new employees. For what was implemented here, courses administrator would create courses that employees can use, and an HR administrator is able to register users in a frontend. Once they confirm their access, the employees would log in to the portal would browse the course library and complete the sections relevant to their role.

To expand the scenario further, course administrators would maintain, and update courses on the Moodle app to ensure that the content stays relevant and useful for the trainees.

In another real-world based project, I acted as a Cloud Specialist to implement a corporate training portal for employees. Moodle was the platform chosen to provide the training, and it’s one of the most popular e-Learning platforms among companies and universities around the world.

We used the Deployment Manager and a Moodle image, available on GCP Marketplace, using the resources of a Compute Engine. To store the training files, in order to comply with high availability (HA) issues, we used the Cloud Storage bucket service.

It all starts in the Marketplace. This is an area where you can get third party application packages, or standalone OS images with specific customizations. Some examples are:

• Wordpress
• Apache Web Server
• RedHat Linux
• SUSE OpenLeap
• NVIDIA Enterprise Workstation

Many of what you will find in the Marketplace is free to use, but there’s also plenty licensed content. The license information will be described in the Pricing tab.

This example uses a paid application package called Moodle, a popular online courseware platform. This is an example of the traditional LAMP stack, Linux Apache MySql and PHP.

The specific image that will be used for this project will leverage a GCP service called Deployment Manager. It is a system that uses infrastructure as code to deploy resources in the cloud environment.

Separately, if you are doing something like this for the first time in your account, bear in mind that a billing account is required (few simple steps). A prompt will appear to provide a place where that can be created. Additionally, an API will also need to be enabled for the Deployment Manager service (one step).

By clicking the Launch button, the deployment process kicks off. Under the hood, a template is being deployed that sets up a compute instance that includes the Moodle application stack. This will be initialized in the Deployment Manager service.

As of this writing, this service will be deprecated in March of 2026. The replacement service is called Infrastructure Manager.

Once the application is deployed, the details tab will contain the information necessary to configure the application. Some of the settings include

• Server IP address
• Database credentials
• Application administrator credentials
• Application URL
• Instance Size
• etc

Before proceeding to customize the application, some of the content needs to be staged. A storage bucket is created and set up to enable the Moodle application to connect to it and load content to the web frontend.

The storage bucket is ready to host the media content. The storage bucket enables public access so that Moodle users are able to see the content that is configured for the course that will be configured shortly. Files have been staged, and also exposed for public consumption. In GCP, the ‘allUsers’ option will enable public access to the objects in a storage bucket.

To set up the course the following steps were completed:

1. Add a new course
2. Customized the course to have the following (Site administration → Courses → Add a new course)
   - Title of ‘Introduction’
   - Use the iLearn logo
   - Display a greeting video animation
   - Provide a download link to a PDF document
3. Add a new home page (Site administration → General → Site home → Site home settings)
   - Site Name ‘Corporate Training Portal’
   - Short name ‘iLearn’
   - Site home summary ‘iLearn — Corporate Training Portal’

Step 2 involved setting references to the files stored in the storage bucket (2.3 and 2.4).

This was a walkthrough of a deployment of marketplace content in a Google Cloud project. This scenario leverages several cloud services like Compute Engine, Storage buckets, and the Deployment Manager (soon to be replaced by Infrastructure Manager). This application will be extended to use Cloud Functions, and other GCP tools to enable the ability to use automation to perform routine tasks, like onboarding new users to the Moodle platform.

Stay tuned for the next part of the two-part series. Thank you

In this real-world based project, I acted as a Cloud Specialist and used IAM services to create a Service Account. This service account allowed communication via scripts within the architecture through Cloud SDK and Python Scripts.

To have it deployed, I had to:

• Set up a Python environment on your local machine.
• Install and configure the Google Cloud SDK.
• Create and manage IAM service accounts.
• Automate storage operations using Python scripts.

1. Python Installation

Python is a versatile programming language widely used for scripting and automation tasks. I am using a Mac mini for this project, so I used brew to install the packages

brew install python

I had version 3.14 and pip 25. I then set up a virtual environment for use with the script that I will be staging shortly

2. Google Cloud SDK

Installed the gcloud CLI on my machine. Reference: https://docs.cloud.google.com/sdk/docs/install-sdk#mac

3. Create IAM Service Account

4. Stage Python Script

This script requires the use of the storage library from the GCP repository. This will be installed

pip3 install –upgrade google-cloud-storage

5. Execute Python Script

Running the python script successfully retrieves the list of buckets that exist in the cloud account.

Conclusion

This was a walkthrough of the GCP IAM Service. In this article, a service account was created to perform an automated task. This involved setting up a Python environment, installed necessary tools and libraries, created an IAM service account, download its key, and executed a sample script to interact with Google Cloud Storage. This process forms the foundation for automating various tasks on Google Cloud using Python.

This script will now enable more advanced automation workflows, such as uploading, downloading, and managing Cloud Storage objects programmatically. By adding additional permissions, other services can be leveraged with this python script

In this real-world based project, I acted as a Cloud Specialist in a project to migrate application and database into an intercontinental (US → Australia Region) in a fully private way using Google Cloud infrastructure.

The application being migrated is a patient registration application of a large US clinic. It is a 2-tier application stack with a NodeJS frontend and a MySQL database for the backend. This migration will leverage the private network backbone of GCP together with the Storage service; specifically, VM snapshots.

The objective was to create disk snapshots, new disks in Australia region, provision new instances, and achieve a successful migration in a secure and fast manner.

Baseline

The database server is fully prepared:

1. Virtual machine deployed
2. MySQL database installed
3. MySQL database configured

— Application user created

— Permissions configured for application user

— Database schema created

— Table created

4. Validate user permissions

5. Validate database schema

The application server is fully prepared:

1. Virtual machine deployed
2. NodeJS installed
3. Application package staged
4. Application configured
5. NodeJS dependencies installed (npm)
6. Security scan performed
7. Start the application
8. Confirm application initialized properly

At this point the server is listening on port 3000. It is ready to receive traffic. However, due to the fact that it is not using the traditional web ports (HTTP / HTTPS), traffic will not reach the server due to GCP firewall rules. By default, only HTTP/S is allowed. A custom firewall rule would need to be set up to enable traffic to the NodeJS frontend.

At this point, the 2-tier application is fully operational. This is the basis for the migration that will be done to relocate the infrastructure to a different region.

Pre-flight steps

The migration will be done by leveraging snapshots of the VMs. They will be copied to the Australia region, where they will be attached to VMs that are deployed to that region.

Migration

New disks are created in the Australia region. They are based on the snapshots created in the US region

The servers are successfully deployed in the Australia region:

1. Disks cloned from US to Australia
2. Servers deployed and attached to disks
3. Confirmed disks have the expected contents

New environment deployed

Migration successful

Application configuration was updated to use the new server’s private IP address in Australia. Upon launching the application, we observed that the same patient records were accessible as those from the US region instance, demonstrating a method for migrating servers using the private networking capabilities of GCP. The advent of virtualization allows this process to be completed within hours, rather than weeks or months required for physical server migrations. This procedure can be incorporated into a disaster recovery strategy and leverages Infrastructure as Code (IaC) to reliably establish a failover site when necessary. Terraform manages GCP infrastructure components such as VPC networks, virtual machines, and disks, while Ansible handles the installation and configuration of essential software like NodeJS and MySQL.

In another project based on a real-world scenario, I acted as a Cloud Specialist in a company that used Google Cloud and AWS services in separate architectures.

The company decided to interconnect the two environments, in a completely private way, using the Virtual Private Gateway, Customer Gateway, Cloud Routers, Cloud VPN, among other services.

However, they needed it in production in a week. So, once GCP and AWS accounts were created, to save time, I decided to deploy it in a 100% automated way using Terraform.

To get things started, a new service account was created, with a service account key. This will be needed to create the network infrastructure later on.

A new IAM user will also be set up in AWS as well, with the accompanying Access Key

Both sets of credentials were staged in the gcloud CLI where helper scripts were deployed to set up the following:

• GCP project assignment — see the yellow text in the screenshot above
• Terraform scripts to deploy resources both in GCP and AWS

Next, is to prepare an SSH key. Since we are interconnecting servers in two different cloud environments, it will be necessary to generate the key on one end, import the public key on the other, and vice versa. The general steps will be outlined below:

1. Generate SSH key in GCP
2. Import the public key from step 1 to the ‘Key Pairs’ list in AWS EC2
3. Generate an SSH key in AWS
4. Import the public key from step 4 to the Compute Engine Metadata page in GCP

Quick sidebar here. The image above shows all the files that are associated with Terraform. All of it could have been included in the single file main.tf. However, it would have been a very large file, and would have been difficult to maintain. It is best practice to split out the code to multiple files to make it easier to manage variables, and other infrastructure components. When the code is modular, it makes it easier to make changes to one portion of the code without impacting the core pieces.

For this project, the components of interest are the networking piece, because they define the VPN tunnels that will implement the interconnect between GCP and AWS, aws_networking.tf. An excerpt is included below:

One more thing: you will also notice that the state file is also present in this folder, terraform.tfstate. For this type of scenario, it is ok implement the initial deployment with the state file on the local machine. However, in a real-life scenario, it’s likely that there would be several DevOps engineers that would be managing the infrastructure in AWS moving forward, therefore, after initial validation is complete, the state file should be moved to an S3 bucket. This way, the state of the infrastructure is properly tracked and managed to prevent conflicts. I only mention this here since this scenario deals with AWS, and remote state management is only supported in AWS due to specific features AWS S3 provides (object lock, versioning, etc). For the other cloud providers, the Terraform Cloud service can provide the same functionality.

Back to the main thread. With the pre-flight check complete, now we can proceed to run the terraform script.

At this point, all of the foundation is in place, and we can now proceed to validate the communication between the two environments.

Here, a ping is initiated from the VM in GCP, to the VM in AWS. The operation is successful.

Although the VM-to-VM communication is successful, it’s important to perform other types oof tests. GCP has a service that provides other types of network probes, which provide more details, Network Intelligence.

This was a walkthrough of an interconnect deployment of a GCP Project to an AWS account. A VPN was deployed to link the two environments together using Terraform. This enables a speedy and consistent deployment for different regions. The terraform script is configurable and can be adjusted as needs change. This leverages several cloud services to implement the interconnect:

• IAM
• Network
• Compute

Terraform did the heavy lifting, and was supported by BASH scripts. This is an example where multiple scripting solutions work together to implement a business need to enable the deployment of cloud infrastructure in multiple sites.

In another project based in a real-world scenario, I worked as Cloud Engineer using DevOps, where I created and implemented an e-Commerce website on AWS in less than 2 hours and in an automated way using Terraform and Ansible (Infrastructure as Code — IaC).

I provisioned the infrastructure in an automated way using Terraform and Ansible to automate the configuration management process, software installation and package management of the EC2 instance. I also used Magento, PHP, MySQL, and Redis to complete this project.

E-Commerce Account Creation

Went to marketplace.magento.com and created a new account. Saved and secured the API key for later use.

AWS — Infrastructure Creation

Used Terraform to deploy a new EC2 instance on an existing VPC with a security group allowing ingress on HTTP and SSH. EC2 instance has a public IP address and a tag with a name to help make it easy to spot in the server list, ecommerce1.

At this point, the server is ready for the deployment of several dependencies required to host the ecommerce site. Ansible is a great tool to manage large batches of configuration settings, which we’ll walk through here. This is going to be a LAMP stack with the Magento application

LAMP:

• Linux — Amazon Linux — Ubuntu 22.04
• Apache 2.4
• MySQL 8.0
• PHP 8.2

Additional packages

• OpenSearch
• Composer

IaC — Ansible

As you can see, the Ansible playbook did not complete successfully. Most the roles that were in place were executed successfully, it was only the last two that failed

After troubleshooting, it appears that the required packages were no longer available in the AWS AMI. I pivoted over to an Ubuntu AMI, and performed the deployment manually.

The application was properly deployed and initialized successfully. As is common with these types of deployments, the cache needs to be flushed immediately upon deployment. It will be flushed several times as configuration changes are applied.

E-Commerce Store Configuration

With the base in place, now the E-Commerce site can be customized to bring it to life. The home page has been configured with basic text and headers.

Now, we have a fully functional e-Commerce site. From here, some additional testing can be done to get it ready for live traffic

• UAT
• Stress testing
• Security measures
• etc

This would involve several groups of users

• Program Managers
• Prospective customers (Proof of Concept, Proof of Value)
• Relevant stakeholders (Project Managers, Sales, etc)
• etc

Some of this can be automated as well, with tools like Selenium, that simulate user traffic. Depending on the project, the backend can also be stress tested as well (database). The level of testing would be determined based on many factors, like seasonal demand, geographical location of the target users, etc.

Since this ended up being a manual deployment, the idea is to capture the steps and create a new ansible role. Since the original role was based on Amazon Linux (a RedHat / CentOS derivative), an entirely new set of Ansible code would need to be created for Ubuntu. This will then be re-usable moving forward. Whenever there’s a breaking change with the underlying OS image, the deployment process would become manual again to determine another successful deployment procedure.

Terraform can handle basic application installations, however due to the level of configuration required for the LAMP stack, it’s better to capture all of that in Ansible.

In this project based on a real-world scenario, I acted as a Cloud Architect and created an executive presentation of infrastructure costs for a SAP migration project from On-Premises to AWS.

SAP workloads were running in a corporate DataCenter with the environment divided into Production, Quality Assurance — QA and Development/Test layers.

My mission was to estimate the costs of migration to AWS, considering that this infrastructure will be running on AWS for at least the next 3 years.

I used a calculator tool that is provided by AWS. It’s on a public-facing page that anyone can use to build a detailed estimate. This does not require an AWS account.

AWS Pricing Calculator

However, if you happen to have an AWS account, you can login to get a more tailored estimate.

The list above shows all the infrastructure that will be used. Note that this includes testing and production environments. Additionally, we have the Enterprise support plan listed; this will be necessary to have the proper level of support from AWS for any major issues that may come up.

An estimate will be generated for each of the components

• EC2 instances
• Elastic Load Balancers
• Databases
• Storage
• Support Plan

An aggregated estimate will be created as a result, as you’ll see shortly.

EC2

What is important to consider here is that the tool is able to provide projections on the breakeven point of the expenses. This is a very important metric that stakeholders will be looking for when it comes to getting a proper approximation of ROI.

Since the requirement is to maintain this infrastructure for 3 years, we are leveraging the best option available, the Savings Plan. It provides the opportunity to defer operational expenses to the go-live phase (Payment Options — ‘No upfront’). All the initial testing and validation can be completed with no immediate financial impact.

Storage — EBS

Load Balancing

Database

Full Estimate

With the estimate complete, I proceeded to export it, so that I can create a Powerpoint slide deck.

To make this data presentable to executives, it must be presented in a graphical way to provide a quick glance at all the costs, relative to the budgeted amount. It enables me to be concise, speak to key points, and provide opportunities for discussion on any items that may be of interest:

• AWS Support plan
• Sizing for dev and staging environments
• etc

This was a walkthrough of the AWS Price Calculator, which demonstrates the capability to generate a detailed pricing estimate for an infrastructure deployment used to prepare an executive presentation. The tool is open to the public and free to use. One of the main highlights of the tool is the breakeven projections, which help in helping submit requests for approval to the Finance department, as well as help decision makers when looking at the cost-benefit analysis. Estimates from the tool can be further tailored when an administrator is logged in to the AWS console.

In this project based on a real-world scenario, I acted as DevSecOps Engineer, and I deployed a set of EC2 instances and infrastructure in an automated way using Terraform (infrastructure as code — IaC). Also, it was necessary to install a specific security agent on all these instances in an automated fashion as well.

Here, you can see two new virtual servers have been deployed to an existing AWS VPC, along with a security group configured to allow ingress on port 22 (SSH).

Once I provisioned the infrastructure, AWS System Manager and its component Command Run were used to install the security agents in an automated way. I used the Amazon Simple Notification Service — SNS to send an email informing the whole process status.

To continue the process, an IAM role was created to enable the ability to enable the System Manager service to send notifications to an SNS topic.

Then, a new subscription was created in the Simple Notification Service (SNS) to associate a topic to an email address.

Some details were redacted, as this is an active AWS account used for production use cases.

With these things in place, a new configuration can be set up in Systems Manager.

It took about 15 minutes to show all green for the configuration associations to take place. This enabled me to proceed to the next step, which is to deploy the security agents.

I selected the two servers, and kicked off a command to install the agent.

After letting the job run for some time, I checked my email, and found notifications for the successful deployment of the servers

The image above shows an overview of a job that was triggered. You see the commands that were run, and the servers it was applied to. Job completed successfully on all targets.

Here, I’m taking a closer look at one of the servers, and checking the logs. This was additional confirmation that the deployment of the agents was successful.

With all of the validation completed, it was time to spin down the deployment.

The command terraform destroy proceeds to shut down and terminate the EC2 instances, removes the security group. By default, this command removes all resources that have been defined in the configuration file. In this case, it was just three resources, the underlying VPC, subnets and other networking infrastructure will persist for future use.

There are other options to selectively remove resources, and those are done under specific circumstances (dev environment where different people are working on specific parts of the infrastructure: web, db, middleware, etc). This way, certain things can be retained so as to not disrupt other user’s work.

This was a walkthrough of automation using Terraform along with cloud-native services like Systems Manager to deploy servers with agents. The SNS service was used as a way to provide external notifications for the status of the deployment. In this case, security agents we deployed to the servers. In other cases, other agents can be deployed; monitoring, queue manager, or other types. Terraform enables the use of configuration files to define cloud infrastructure that makes it possible to track via version control, and execute consistent deployments in the cloud. For simpler use cases like the one covered here, some bootstrap commands can be included in the Terraform configuration. For more elaborate ones, tools like Ansible or Puppet may be more appropriate. Terraform can be used in conjunction with Ansible. An example of this will be covered in another post.

In this project based on a real-world scenario, I was responsible for implementing an application that needs to support the high demand of a large number of users accessing it simultaneously.

This application has been used in a large conference that had more than 10,000 people, in-person and online, with participants from all over the world. This event was broadcast online and in person and 10 vouchers were drawn for 3 Cloud certifications. At that moment, more than 10,000 people in the audience registered their e-mails to guarantee their participation in the raffle.

In AWS, several services were used: Elastic Beanstalk to deploy the web application, DynamoDB to store emails, CloudFront to cache static and dynamic files in an Edge Location close to the user.

Starting with DynamoDB, the table was set up, so that it could be ready to receive write requests from the Beantstalk application.

Next, was the Beanstalk instance. This part took multiple attempts, as I’ll explain shortly.

Here you see the underlying EC2 instance up and running. This is where the application will be deployed.

Image above shows the issue of the first attempt to deploy the instance. I had selected all available subnets (public and private in multiple Availability Zones — AZs). I rolled this deployment back, and tried again…

I had selected just private subnets this time around. This, still, was not a proper configuration. So therefore, I rolled back again, and deployed a new instance.

Based on the errors reported in the previous attempts, I made different selections (1 public subnet in one AZ, and the private subnet in another AZ).

With the instance up and running I proceeded to perform validation.

For brevity, I have skipped a few steps to update the IAM role to enable the Beanstalk service to write to the DynamoDB . Above you can see that a new user has been successfully registered in the app, and a new entry exists in the DynamoDB table.

Now, we’ll take things a step further to host the application behind a CloudFront distribution. As, shown in the architecture diagram at the start of this article, this will enable users in different parts of the world to get access to the site. Additionally, this will enable us add additional layers of security by leveraging Web Application Firewall (WAF) and protections against Distributed Denial of Service (DDoS) attacks.

This distribution uses the load balancer from the Elastic Beanstalk instance as an origin. CloudFront distributions can also use S3 buckets as an origin to create a static website.

Navigating to the distribution domain name URL, we’re able to see the application again

Notice that the site is now secured with HTTPS

As you can see, more users have been successfully registered.

After this, I performed some load tests using the stress utility, to see how CloudFront would handle failover, triggering a scaling event, etc. I was able to see that in the monitoring page for the target group in the Load Balancing page, as well as Instances page for the Beanstalk application.

Biggest takeaway from this project was the load balancing configuration. Even though I picked multiple subnets (public/private), they needed to be in different Availability Zones. This helped to reinforce the fact that AZs are separate sites in one region. So in the event of a outage in one AZ (power failure, network disconnect, etc), the other one can step in to provide continuity.