In this post, I’ll walk you through:

• Creating your own KMS key

• Using that key to encrypt files uploaded to S3

• Enforcing encryption via bucket policies

Key Concepts in AWS KMS

• Symmetric Key – A single key is used for both encrypting and decrypting data.

• Asymmetric Key – Uses a key pair: a public key to encrypt and a private key to decrypt.

• AWS-Managed Key – Automatically created and managed by AWS.

• Customer-Managed Key (CMK) – A key you create, configure, and control.

• Key Rotation – Periodically changes the key's internal material to improve security.

For encrypting S3 files, a symmetric CMK is the most common and practical option.

Create a Customer-Managed KMS Key

Search for “KMS” in the AWS Console, click Key Management Service, then Customer-managed keys > Create key.

Keep the default settings to generate a symmetric key with AWS-provided key material. On the next screen, give your key an alias and optionally add a description to help identify it later.

Continue with the default administrative permissions, which define who can manage the key but not use it for encryption. Then, set the usage permissions to decide who can perform cryptographic operations like encrypting and decrypting data.

Finally, review the policy details, click Finish, and make sure your key appears in the list with the status “Enabled.” The key is now ready to be used for securing S3 objects with server-side encryption.

Creating an S3 Bucket with Default SSE-KMS Encryption

To ensure all objects stored in our S3 bucket are encrypted with our own AWS KMS Customer Managed Key (CMK), we can configure default server-side encryption during bucket creation.

This way, every object uploaded to the bucket will be automatically encrypted without requiring users to explicitly select an encryption method during upload.

Navigate to the Amazon S3 Console and click Create bucket. Enter a unique bucket name and select a region.

Scroll down to the Default encryption section and configure the following:

• Encryption type:
  ✅ Select Server-side encryption with AWS Key Management Service keys (SSE-KMS).

• AWS KMS key:
  ✅ Choose your Customer Managed Key (CMK) from the dropdown.
  (You can also click "Create a KMS key" if you don’t have one yet.)

• Bucket Key:
  ✅ Enable Bucket Key to reduce AWS KMS request costs.

Then, click Create bucket at the bottom of the page.

Verify Encryption

Go to your S3 bucket in the console and click Upload → Add Files. There's no need to configure encryption, it's handled automatically!

Enforcing SSE-KMS using Bucket Policy (Optional)

Even with default encryption, it’s good security practice to enforce SSE-KMS through a bucket policy, especially if others upload via SDK, CLI, or APIs.

In the S3 bucket console, click the Permissions tab followed by Bucket Policy to open the Bucket policy editor.

Insert the following bucket policy into the editor:

{
    "Version": "2012-10-17",
    "Id": "RequireSSEKMS",
    "Statement": [
        {
            "Sid": "DenyUploadIfNotSSEKMSEncrypted",
            "Effect": "Deny",
            "Principal": "*",
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::<your-bucket-name>/*”,
            "Condition": {
                "StringNotEquals": {
                    "s3:x-amz-server-side-encryption-aws-kms-key-id": "arn:aws:kms:<region>:<account_id>:key/<key-id>"
                }
            }
        }
    ]
}

Replace <Your_Bucket_Name> and <region>:<account_id>:key/<key-id> with your actual name.

Attempt to upload a file by changing the encryption configuring. The upload should fail.

Retry the upload, this time without changing the encryption configuration. The upload should succeed.

These steps are configuring an S3 bucket policy to require SSE-KMS encryption for any new objects uploaded to the bucket. This ensures that all data stored in the bucket is encrypted according to your specified requirements.

Conclusion

In this article, we explored the process of encrypting S3 objects using SSE-KMS, from creating a Customer-Managed Key to enforcing encryption policies. By implementing these practices, you can significantly enhance the security of your data stored in AWS S3.

⚠️ Disclaimer: This is a minimal, all-in-one installation intended for development and testing purposes only. Do not use this setup in production environments.

What is DevStack?

DevStack is a series of extensible scripts used to quickly bring up a complete OpenStack environment for development or testing purposes. It’s not recommended for production use, but it's perfect for labs and learning.

Why Use DevStack?

DevStack is a great way to:

• Learn OpenStack hands-on

• Test and experiment with OpenStack components

• Set up a local cloud lab quickly

But again, it’s not designed for production workloads, so test it as your cloud playground.

My System Info

Before diving in, I’ve already installed a VM on my local machine. Here’s the OS I used:

Setup Steps

1. Update the system

Make sure your packages are up to date:

sudo apt-get update -y

2. Clone my DevStack setup repo

I've uploaded a custom DevStack configuration script to GitHub. Feel free to clone and use it.

git clone https://github.com/linnlattoo-cloud/devstack.git
cd devstack

3. Make the setup script executable

chmod +x devstack_setup.sh

4. Optional: Customize your setup

You can change passwords for:

• Database

• admin

• service

• RabbitMQ

Just edit the local.conf file by using vim editor or nano inside the repo before starting the install.

5. Run the setup script

This will download and install OpenStack and take 20–30 minutes.

./devstack_setup.sh

Accessing OpenStack

Once the setup is done, you can log in to the OpenStack dashboard (Horizon) (http://your-server(vm)-ip/dashboard) using the admin user and the admin password you defined in local.conf.

Cleaning Up

Need to remove everything? Just run:

./clean.sh

This will clean up your DevStack environment so you can start fresh if needed.

That’s it! DevStack is a fantastic way to explore OpenStack locally without complex setups. Feel free to fork my GitHub repo if you find this useful.

Thanks for reading! 🙌

Let’s get started!

Prerequisites

• An Azure Account: Sign up here

• Azure CLI: Install Guide

• kubectl: Install Guide

Creating Kubernetes cluster

Visit Azure portal and log in with your Azure account. On the top search bar, type Kubernetes services and select it. Click the "+ Create" button and choose "Create Kubernetes cluster".

Configure the basic settings according to your needs. The image below shows an example configuration for demo purposes only.

Once your AKS cluster is ready, follow the connection instructions provided under the "Connect" section in the Azure Portal to configure kubectl access.

Note: In the screenshot, I skipped the az login step because I was already logged in.

az login
az account set --subcription <subcription-id>
az aks get-credentials --resource-group <resource-group-name> --name <k8s-cluster-name> --overwrite-existing

To verify your connection to the cluster, run:

kubectl get svc

You should see the default Kubernetes services listed, confirming the connection.

Below is the architecture, along with the deployment and service configuration files used in this demo.

Disclaimer: These files are originally created by KodeKloud. I'm using them solely for demonstration purposes. You can fork the original files from their public repository.

I made a small modification:
Changed the service type to LoadBalancer for both vote-service and result-service (the frontends) to allow external access.

Let’s Deploy

As you can see in the screenshot, I have these manifest files (vote-deployment.yaml, vote-service.yaml, result-deployment.yaml, result-service.yaml, db-deployment.yaml, db-service.yaml, redis-deployment.yaml, redis-service.yaml, worker-deployment.yaml).

To deploy the applications to your AKS cluster, use the kubectl apply command, specifying the -f flag followed by the name of each manifest file:

kubectl apply -f vote-deployment.yaml
kubectl apply -f vote-service.yaml
kubectl apply -f result-deployment.yaml
kubectl apply -f result-service.yaml
kubectl apply -f db-deployment.yaml
kubectl apply -f db-service.yaml
kubectl apply -f redis-deployment.yaml
kubectl apply -f redis-service.yaml
kubectl apply -f worker-deployment.yaml

As shown in the screenshot, each kubectl apply command will create the corresponding deployment and service in your AKS cluster.

To verify that the deployments and services have been created successfully, you can use the kubectl get deployments,svc command:

kubectl get deployments,svc

The output, as seen in the screenshot, will display the list of deployments and services along with their current status, the number of ready replicas, their age, and for services, their type, cluster IP, external IP, and exposed ports.

Similarly, the services (service/vote, service/result, service/db, service/redis) will be listed with their respective details in Azure portal. Notice that the vote and result services are of type LoadBalancer, which means Azure Kubernetes Service has provisioned external load balancers to make these applications accessible from outside the cluster. You can see their external IPs listed in the "EXTERNAL-IP" column.

You can now access the voting application and the results application using the external IPs provided for the vote and result services, respectively, in your web browser.

Congratulations! You have successfully deployed a multi-tier application to your Azure Kubernetes Service cluster using kubectl. This demonstrates the basic steps involved in deploying and managing applications on AKS.

Don’t forget to delete the resources to avoid extra charges.

Thanks for reading!

Let’s Encrypt?

Let’s Encrypt is a free and trusted Certificate Authority (CA) that provides SSL/TLS certificates. Using their service with Certbot (the official tool for managing certificates) makes SSL setup almost effortless - especially when paired with Nginx.

Here’s what I had set up before starting:

• A VM running Ubuntu 22.04 on Azure

• Nginx installed and running

• Ports 80 (HTTP) and 443 (HTTPS) open

• A domain name with an A record pointing to the VM’s public IP

This ensures that your domain resolves to your server and that Let's Encrypt can validate domain ownership.

Step-by-Step Setup

Install Certbot and the Nginx Plugin

First, install Certbot and its Nginx integration plugin:

sudo apt install certbot python3-certbot-nginx

Edit Nginx Server Block

Open your site’s Nginx config:

sudo vi /etc/nginx/sites-available/example.com

In the server block, make sure to add:

server_name example.com;

Nginx needs to know which domain this block is for. This is how Certbot identifies which site to secure.

Test Nginx Config

Check for any syntax errors:

sudo nginx -t

Apply your changes:

sudo systemctl reload nginx

Obtain and Install SSL Certificate

Now, let’s request the SSL certificate and configure Nginx in one command:

sudo certbot --nginx -d example.com

If this is your first time running certbot, you will be prompted to enter an email address and agree to the terms of service.

This command will:

• Verify your domain ownership

• Download and install the SSL certificate

• Automatically configure your Nginx site for HTTPS

Verifying Everything Works

Certbot sets up an automatic renewal timer. Verify that it's running:

sudo systemctl status certbot.timer

Let’s Encrypt certificates expire every 90 days, so automated renewal is critical.

Test Renewal

Do a dry-run of the renewal process to ensure it's working:

sudo certbot renew --dry-run

This makes sure your renewal process will succeed before it really matters.

Here we go!

Conclusion

Securing your website or app with HTTPS is essential for encrypting user data, enhancing trust, and boosting SEO. Let’s Encrypt offers free SSL/TLS certificates via Certbot, simplifying setup with Nginx. The step-by-step guide includes installing Certbot and the Nginx plugin, editing the Nginx server block with your domain, and using Certbot to obtain and install an SSL certificate. Automated renewal ensures certificates stay valid, with verification and renewal testing processes included.

Prerequisites

Before we begin, I’ve already launched three EC2 instances (Ubuntu 22.04) for this demo:

• instance-01 (Main Prometheus + Grafana Server)

• instance-02 (Node Exporter)

• instance-03 (Node Exporter)

All instances follow the same initial setup.

Step 1: Initial Setup on All Instances

SSH into each EC2 instance and run the following:

sudo suapt update -y
git clone https://github.com/linnlattoo-cloud/prometheus_grafana.git
cd prometheus_grafana
chmod +x *.sh

This prepares the environment by cloning the necessary scripts and ensuring all .sh files are executable.

Step 2: Configure instance-01 (Main Monitoring Server)

On instance-01, execute the installation scripts in order:

./01…
./02…
./03…
./04…

Once done, you can now access the dashboards:

• Prometheus: http://<instance-01-ip>:9090

• Grafana: http://<instance-01-ip>:3000

🔐 Default Grafana credentials:

• Username: admin

• Password: admin

Step 3: Configure instance-02 and instance-03 (Node Exporters)

For the other two instances, just set up Node Exporter by running 03…sh file:

./03…

This installs Node Exporter so they can be monitored by Prometheus.

Step 4: Connect All Targets in Prometheus

Back in instance-01, open the Prometheus configuration file:

sudo vi /etc/prometheus/prometheus.yml

Under the scrape_configs section, add all three instances like this:

- job_name: 'remote_collector' 
  scrape_interval: 10s 
  static_configs: 
    - targets: ['instance-01-ip:9100', 'instance-02-ip:9100', 'instance-03-ip:9100']

Then, restart Prometheus to apply changes and Navigate to http://<instance-01-ip>:9090/targets to verify all your targets are listed and UP.

Step 5: Set Up Grafana Dashboard

Head over to your Grafana dashboard:

• Click Connections > Add new connection

• Choose Prometheus and set the URL to http://<instance-01-ip>:9090

• Save and test the connection

Now for the fun part—dashboards!

• Go to Dashboards > Import

• Upload the JSON file provided in the GitHub repo

• Click Load

• Select the Prometheus data source and click Import

Boom! Your monitoring dashboard is live.

That’s it! In just a few simple steps, you’ve got a monitoring setup with Prometheus and Grafana across multiple instances. This stack is powerful for monitoring or demo purposes.
Feel free to fork the GitHub repo and customize your dashboard or explore alerting features next!

Amazon Elastic File System (EFS) is a fully managed, scalable, and shared file storage solution provided by AWS. It allows multiple EC2 instances to access the same file system simultaneously, making it ideal for shared workloads or distributed applications.

In this guide, I will walk through the steps to implement EFS with two Amazon Linux EC2 instances, highlighting its setup and benefits.

Implementation

First, I’ll create two EC2 security groups, each configured to allow SSH access for their respective EC2 instances.

Next, I’ll create another security group with NFS access allowed for the previously created security groups.

Now, we have all the required security groups.

Next, navigate to EFS, and I’ll create an NFS file system.

Enter the name, select the VPC, and click “Customize.”

I’ll uncheck automatic backups, encryption at rest, and lifecycle management since this is a demo. Then, we’ll select Bursting.

Next, we’ll create mount targets by selecting the NFS security group we created earlier for each availability zone (AZ).

Finally, review the settings and create the NFS file system.

Next, we’ll create two EC2 instances with a Linux operating system. In this demo, I’ll launch instance_1 in ap-southeast-1a and instance_2 in ap-southeast-1b. During the creation process, make sure to select the correct VPC, subnets, and the existing security group we created earlier.

In the “Configure storage” section, click “Edit” under File systems.

Select the EFS we created earlier and uncheck “Automatically create and attach security groups.”

Now, we have our EC2 instances set up.

Testing

I created sample.txt under /mnt/efs/fs1/ on instance_1. We can also access that file on instance_2.

Conclusion

By following these steps, you’ve successfully implemented Amazon EFS with two Amazon Linux EC2 instances. This setup allows you to share data seamlessly between instances and scale your applications without worrying about storage limitations.

Happy cloud computing!

Step 1: Enabling CloudWatch Billing Alerts in the Billing Console

Our journey begins at the AWS Management Console, the control center of your AWS environment. Here’s how you can enable billing alerts:

• Sign In: Open the AWS Management Console.
• Navigate to the billing dashboard. In the top navigation bar, click on your account name and select Billing and Cost Management.

• Billing Preferences: On the left-hand side, you’ll see a menu. Click on billing preferences.

• Enable Alerts: Look for the alert preferences and edit them.

• Update: Don’t forget to hit the Update button to apply your changes.

With billing alerts enabled, you’ve taken the first step towards cost management mastery. Now, let’s set up a CloudWatch billing alarm to notify you when your costs exceed a certain threshold.

Step 2: Creating a CloudWatch Billing Alarm

Before creating the billing alarm, make sure to set the region to US East (North Virginia).

• Open the CloudWatch Console: Navigate to the CloudWatch console.
• Create Alarm: In the navigation pane on the left, click on Alarms, then choose Create Alarm.

• Select Metric: Click on Select Metric to start defining what you want to monitor.

• Billing Metrics: Under the Browse tab, find and click on Billing.

• Choose Metric: Select the total estimated charge. You’ll need to pick the currency your account is billed in, like USD.

• Configure Metric: Click Select Metric to move to the configuration page.

Step 3: Configuring Alarm Conditions

• Set Period: Choose how often you want the alarm to evaluate your spending. A common choice is every 6 hours.
• Threshold Type: Select Static.
• Set Condition: Define the threshold that will trigger the alarm. For example, if you want to be alerted when your spending equals or exceeds $50, choose Greater/Equal and enter $50.

Step 4: Setting Up Actions

Actions define what happens when an alarm state is triggered. Typically, this involves sending a notification via Amazon SNS:

• Add Notification: Under Actions, select In alarm, then choose Add notification.
• SNS Topic: If you have an existing Amazon SNS topic, select an existing Amazon SNS topic. If not, create a new one. This is where notifications will be sent. In this guide, I’ll create a new Amazon SNS topic.

• Name your topic: Give your topic name and enter the email that will receive the notification, and then create a topic. If you want to enter 2 or more emails, you can separate with comma “,”. For example, user1@example.com and user2@example.com.

After creating a new Amazon SNS topic, it will select that topic automatically.

• Configure Notification: Add the necessary details and click Next.

Step 5: Naming and Reviewing Your Alarm

• Name Your Alarm: Give your alarm a descriptive name and add a brief description if needed.
• Review: Double-check all the settings.
• Create Alarm: Click Create Alarm to finalize the process.

Step 6: Amazon SNS Subscription Confirmation

This is the final step. You’ll get an email from AWS and then confirm your subscription using the link.

And there you have it! You’ve successfully set up a billing alarm on Amazon CloudWatch. This proactive measure will help you stay informed about your AWS spending and avoid any budget overruns.

By following these steps, you’re not just enabling billing alerts; you’re taking control of your AWS environment. So, next time you log into your AWS account, you can do so with the confidence that you’re on top of your costs.

Happy cloud computing!

Feel free to share your thoughts or any additional tips in the comments below. If you found this guide helpful, don’t forget to clap and share it with others who might benefit from it!

First, we need to create Amazon EC2 instance.

Here is a sample instance. You can configure it depending on your needs.

After creating instance, connect to the instance.

Now, enter these commands

• sudo apt update -y
• sudo apt install git -y

After installing git, go to the GitHub runners and click “New self-hosted runner”

Choose Linux x64, this can be different upon your instance OS and architecture.

You’ll see command lines to download and configure the runner in instance.

You just need to copy and run the command lines in the instance.

Now, let’s check the GitHub runner. We got the runner but its status is offline.

Go to the instance and run these commands

• sudo ./svc.sh install
• sudo ./svc.sh start

Check again the runner.

We got our self-hosted runner.

Now, I’ll continue to show how to use that runner in the GitHub Actions yml. It’s just that you need to type the runner labels in runs-on to use the self-hosted runner. Here is an example

Now, I’ll continue to show how to remove the runner.

Before we remove the runner, we need to stop and uninstall the runner service in the instance.

Run these commands

• sudo ./svc.sh stop
• sudo ./svc.sh uninstall

Now, go to the GitHub runner option and click “remove runner”

You just need to copy and run the remove command.

Check in the GitHub runner. It’ll be gone.

This guideline will create a self-hosted GitHub Actions runner on an AWS EC2 instance, allowing you to run CI/CD jobs directly on your own infrastructure. I hope you enjoy!

First, navigate to S3 and create an S3 bucket.

Enter a unique bucket name. The bucket name must be globally unique.

Uncheck “Block all public access” and check the acknowledge

Bucket Versioning is your choice. Read more about Bucket Versioning “https://docs.aws.amazon.com/AmazonS3/latest/userguide/versioning-workflows.html”

Other settings are default.

This is my sample static webpage.

Now, let’s upload that file to S3.

• Click on the “Upload” button.

• Add the files or folders of your static website.

• Click “Upload” to start uploading the files.

Let’s configure the Bucket for Static Website Hosting

• In your bucket, go to the “Properties” tab.

• Scroll down to the “Static website hosting” section and Click “Edit”.

• Select “Enable” for Static website hosting. If you uploaded with file, just specify the index document (e.g., ‘index.html’) or if you uploaded with folder, specity the index document in the folder (e.g., ‘your-folder-name/index.html’).
• Optionally, you can also specify an error document (e.g., ‘error.html’). And then Click “Save changes”.

You’ll see your Bucket website endpoint. It is the URL for your website. Let’s check the URL.

It’s not an error. You need to set permission of your bucket.

• Go to the “Permissions” tab of your bucket.

• Under “Bucket policy”, click on “Edit”.

• Click on “Policy generator”.
• Copy your Bucket ARN.

• Select “S3 Bucket Policy”
• Effect — “Allow”
• Principal — “*”
• Actions — “GetObject”
• Enter your Bucket ARN with “/*”- “e.g,. your-arn/*”
• And then click “Add Statement” and “Generate Policy”

Copy the Policy JSON Document and Paste in S3 Policy Box.

And then Save the Policy.

Let’s check again the URL.

Thank you for following along with my tutorial on deploying a static website using Amazon S3. I hope that this guide has provided you with clear and actionable steps to get your website up and running.

You can choose the one that matches with you operating system.

After completing downloaded, install the Outline Manager.

In the Outline Manager, you can choose the cloud provider where you want to host the Outline VPN Server. For now, I continue with Amazon Lightsail.

Now, go to Amazon Lightsail and create instance.

You can choose the Region where you want to host your server.

You can choose the Operating System. I continue with Ubuntu. Note that please choose Operating System (OS) only.

Choose your plan that meet with your need. And then create the instance.

After creating instance, go to Networking section and create and attach the static ip.

In that Networking section, a little bit scroll down, you’ll see IPv4 Firewall rule and create “All TCP allow” rule.

Now, go to Connect section and click “Connect using SSH”

Run “sudo apt-get update -y”

And then copy and run the command from Outline Manager.

After completed installation, copy and paste the green part to the Outline Manager.

Now, we have Outline VPN Server.

Let’s create a key by clicking “Add new key”. Enter the key name as you prefer.

Now. let’s connect the vpn.

Before you connect, you need to install the Outline VPN client in your device. You can download from the above link.

Get the Outline Access Key in the share button.

You can connect the VPN by just copy and paste the access key or you can share the access key if you want to connect in other devices.

I recommend you should use one access key for one device.

Now, let’s check our ip. You can check in “https://ipleak.net"

My result is Singapore because I hosted the server in Singapore region. Your result may be different depends on the region where you hosted the server.

Okay, That’s all. How easy. I hope you can deploy your own VPN Server! Thank you!