
If you are looking for a complete **Prometheus and Grafana installation guide on AWS EC2**, this tutorial walks you through the full setup from scratch to production-ready. This stack is ideal for Linux server monitoring because it is lightweight, flexible, and easy to extend for alerting.

In this article, you will set up:

* Prometheus to collect metrics
* Node Exporter for server metrics (CPU, RAM, disk, network)
* Grafana for monitoring dashboard visualization
* Domain + Nginx reverse proxy
* HTTPS with Let's Encrypt
* Basic Auth as an extra security layer

If your instance is not created yet, start with [how to create an AWS EC2 instance](/blog/create-aws-ec2-instance). For web server hardening after the monitoring setup, continue with this [secure Nginx SSL/TLS guide](/blog/secure-nginx-ssl-tls-lets-encrypt-ubuntu).

---

## Table of contents

* Prerequisites for installing Prometheus and Grafana on EC2
* Monitoring architecture overview
* Install Prometheus
* Install Node Exporter
* Connect Prometheus to Node Exporter
* Enable auto-start with systemd
* Install and run Grafana
* Connect Grafana to Prometheus
* Import dashboard Node Exporter
* Set up Grafana domain with Nginx
* Set up HTTPS with Let's Encrypt
* Add Basic Auth
* Recommended Security Group rules for this monitoring stack
* Production best practices
* Quick troubleshooting
* FAQ
* Conclusion

---

## Prerequisites for installing Prometheus and Grafana on EC2

Before you start, make sure:

* Your Ubuntu-based EC2 instance is running
* You have SSH access to the server
* A domain for Grafana is ready (optional, but recommended)
* Your Security Group allows ports `22`, `80`, and `443`

---

## Monitoring architecture overview

```
User → HTTPS → Nginx → Grafana → Prometheus → Node Exporter
```

---

## 1) Install Prometheus on EC2

```bash
cd /opt

wget https://github.com/prometheus/prometheus/releases/download/v3.11.2/prometheus-3.11.2.linux-amd64.tar.gz

tar -xvf prometheus-3.11.2.linux-amd64.tar.gz
mv prometheus-3.11.2.linux-amd64 prometheus
cd prometheus
```

Run:

```bash
./prometheus --config.file=prometheus.yml --web.listen-address="0.0.0.0:9090"
```

Access:

```
http://IP-EC2:9090
```

![Screenshot halaman Prometheus](https://ik.imagekit.io/n1hqrcegw/articles/how-to-install-prometheus-grafana-on-ec2/image-01.webp)
_Screenshot of the Prometheus home page after the service starts successfully._

---

## 2) Install Node Exporter

```bash
cd /opt

wget https://github.com/prometheus/node_exporter/releases/download/v1.11.1/node_exporter-1.11.1.linux-amd64.tar.gz

tar -xvf node_exporter-1.11.1.linux-amd64.tar.gz
mv node_exporter-1.11.1.linux-amd64 node_exporter
cd node_exporter
```

Run:

```bash
./node_exporter --web.listen-address="0.0.0.0:9100"
```

![Screenshot endpoint Node Exporter](https://ik.imagekit.io/n1hqrcegw/articles/how-to-install-prometheus-grafana-on-ec2/image-02.webp)
_Screenshot of the Node Exporter metrics endpoint at `http://IP-EC2:9100/metrics`._

---

## 3) Connect Prometheus to Node Exporter

Edit config:

```bash
nano /opt/prometheus/prometheus.yml
```

Add:

```yaml
scrape_configs:
  - job_name: 'node'
    static_configs:
      - targets: ['localhost:9100']
```

Restart Prometheus:

```bash
pkill prometheus
./prometheus --config.file=prometheus.yml --web.listen-address="0.0.0.0:9090"
```

---

## 4) Enable auto-start with systemd

### Service Prometheus

```bash
nano /etc/systemd/system/prometheus.service
```

```ini
[Unit]
Description=Prometheus
After=network.target

[Service]
ExecStart=/opt/prometheus/prometheus --config.file=/opt/prometheus/prometheus.yml --web.listen-address=0.0.0.0:9090
Restart=always

[Install]
WantedBy=multi-user.target
```

### Node Exporter Service

```bash
nano /etc/systemd/system/node_exporter.service
```

```ini
[Unit]
Description=Node Exporter
After=network.target

[Service]
ExecStart=/opt/node_exporter/node_exporter --web.listen-address=0.0.0.0:9100
Restart=always

[Install]
WantedBy=multi-user.target
```

Enable services:

```bash
systemctl daemon-reload
systemctl enable prometheus
systemctl start prometheus

systemctl enable node_exporter
systemctl start node_exporter
```

![Screenshot status service systemd](https://ik.imagekit.io/n1hqrcegw/articles/how-to-install-prometheus-grafana-on-ec2/image-03.webp)
_Screenshot of `systemctl status prometheus` and `systemctl status node_exporter` checks._

---

## 5) Install Grafana

```bash
apt-get install -y adduser libfontconfig1 musl

wget https://dl.grafana.com/grafana/release/13.0.0/grafana_13.0.0_24384745231_linux_amd64.deb

dpkg -i grafana_13.0.0_24384745231_linux_amd64.deb
apt-get install -f -y
```

Start:

```bash
systemctl start grafana-server
systemctl enable grafana-server
```

Access:

```
http://IP-EC2:3000
```

Login:

```
admin / admin
```

![Screenshot login Grafana](https://ik.imagekit.io/n1hqrcegw/articles/how-to-install-prometheus-grafana-on-ec2/image-04.webp)
_Screenshot of the Grafana login page on port `3000`._

---

## 6) Connect Grafana to Prometheus

In Grafana:

* Settings → Data Sources
* Add → Prometheus
* URL:

```
http://localhost:9090
```

Click **Save & Test**

![Screenshot konfigurasi Data Source Prometheus](https://ik.imagekit.io/n1hqrcegw/articles/how-to-install-prometheus-grafana-on-ec2/image-05.webp)
_Screenshot of Grafana Prometheus Data Source settings (`http://localhost:9090`) and Save & Test result._

---

## 7) Import dashboard Node Exporter

Use dashboard ID:

```
1860
```

👉 Node Exporter Full dashboard

![Screenshot import dashboard Node Exporter](https://ik.imagekit.io/n1hqrcegw/articles/how-to-install-prometheus-grafana-on-ec2/image-06.webp)
_Screenshot of importing dashboard ID `1860` and the final dashboard view._

---

## 8) Set up Grafana domain with Nginx

Example:

```
grafana.studiku.id → IP EC2
```

Install Nginx:

```bash
apt install nginx -y
```

Config:

```nginx
server {
    listen 80;
    server_name grafana.studiku.id;

    location / {
        proxy_pass http://localhost:3000;
    }
}
```

---

## 9) Set up HTTPS with Let's Encrypt

Use Let's Encrypt:

```bash
apt install certbot python3-certbot-nginx -y
certbot --nginx -d grafana.studiku.id
```

---

## 10) Add Basic Auth

```nginx
location / {
    proxy_pass http://localhost:3000;

    auth_basic "Restricted";
    auth_basic_user_file /etc/nginx/.htpasswd;
}
```

Create a user:

```bash
htpasswd -c /etc/nginx/.htpasswd admin
```

---

## 11) Recommended Security Group rules for this monitoring stack

| Port | Notes                  |
| ---- | ---------------------- |
| 22   | SSH (your own IP only) |
| 80   | HTTP                   |
| 443  | HTTPS                  |
| 3000 | ❌ close               |
| 9090 | ❌ close               |
| 9100 | ❌ close               |

---

## Production best practices

* Use HTTPS
* Do not expose Prometheus and Node Exporter publicly
* Add Basic Auth
* Configure monitoring alerts

---

## Quick troubleshooting

### Grafana cannot connect to Prometheus

Make sure the Grafana data source URL is:

```
http://localhost:9090
```

Then verify the Prometheus service is running.

### Dashboard is empty or metrics are missing

Check the `localhost:9100` target on the `Status > Targets` page in Prometheus.

### HTTPS certificate issuance fails

Make sure your domain DNS points to the EC2 public IP and ports `80/443` are open in the Security Group.

---

## FAQ

### Do Prometheus and Grafana need separate servers?

Not required. For low-to-medium traffic, one EC2 instance is usually enough. For higher load, separating components can improve stability.

### Can ports 3000, 9090, and 9100 be publicly exposed?

It is not recommended for production. Access should go through the HTTPS domain behind Nginx only.

### Is Basic Auth still needed if Grafana already has login?

Yes. It adds another protection layer before users even reach the Grafana login page.

---

## Conclusion

With this setup, you get a secure and production-ready **AWS EC2 monitoring stack**:

* Real-time server monitoring
* Professional dashboards
* Secure access via domain and HTTPS
* A production-ready system

---

## Next steps to optimize monitoring

For a more advanced production setup:

* Send alerts to Teams / Telegram
* Add Laravel monitoring (queue, DB)
* Set up log monitoring

---

If your deployment workflow is based on GitHub, you can combine this setup with a safer repository access pattern from [secure git clone GitHub to EC2](/blog/secure-github-clone-to-ec2-with-deploy-keys).



If you are looking for a secure way to **git clone a GitHub repository to EC2** for production, the best approach is to use **read-only SSH deploy keys**. In this guide, the scenario uses **two different repositories on one AWS EC2 instance** (example: **englishnesia** and **studiku**) with a clean and auditable setup.

Since GitHub allows **one deploy key per repository**, you need **two SSH key pairs** and two `Host` aliases in `~/.ssh/config`. With this pattern, Git automatically uses the correct key for each repo, reduces credential leakage risk, and keeps deployments consistent.

You can still manage branches such as **`main`** and **`dev`** in each repository (`fetch`, `checkout`, or `git worktree`). If your instance is not ready yet, start with [how to create an EC2 instance on AWS](/blog/create-aws-ec2-instance).

---

## Table of contents

* Why use deploy keys to clone to EC2?
* What is an SSH deploy key in GitHub for EC2?
* Two repos on one EC2: keys and Host aliases
* Step-by-step: set up keys and clone two repositories
* How to manage `main` and `dev` branches (per repo) + git worktree option
* Production security best practices on EC2
* Conclusion

---

## Why use deploy keys to clone to EC2?

Many setups still use **tokens in URLs**, store **PATs in `.env`**, or rely on **one personal SSH key** for multiple servers. In real production environments, this is risky because:

* A compromised server inherits the GitHub access scope of that credential
* It becomes harder to audit who can pull or push
* A leaked token can affect **multiple repositories**

**Best recommendation:** use a **read-only SSH deploy key per repository** to follow the *least privilege* principle without embedding personal GitHub account credentials on the server.

---

## What is an SSH deploy key in GitHub for EC2?

A **deploy key** is an SSH key pair added in **Settings → Deploy keys** for **one specific repository**.

* It can be **read-only**
* It does not replace user account login for other repositories
* It is ideal for **EC2** servers that only need `git pull` / clone

If you have many repositories and a large team, consider a **GitHub App** or a **CI/CD** pipeline. For cloning a few repositories on EC2 servers, deploy keys are still one of the simplest and safest options.

---

## Two repos on one EC2: keys and Host aliases

| GitHub repo | Key file on EC2 | `Host` alias (example) |
|----------------|-------------------|---------------------------|
| `YOUR_USERNAME/englishnesia` | `~/.ssh/github_englishnesia` | `github.com-englishnesia` |
| `YOUR_USERNAME/studiku` | `~/.ssh/github_studiku` | `github.com-studiku` |

**Important:** the **first** public key must only be registered to **englishnesia**; the **second** public key must only be registered to **studiku**. Do not swap them, or GitHub will reject access / route to the wrong repository.

Both blocks use `HostName github.com` and `User git`; the only differences are **`IdentityFile`** and the **`Host`** alias name so each clone URL uses the right identity:

* `git@github.com-englishnesia:USER/englishnesia.git`
* `git@github.com-studiku:USER/studiku.git`

---

## Step-by-step: set up keys and clone two repositories

### 1. Log in to EC2

```bash
ssh -i external.pem ubuntu@IP-EC2
```

Use a **non-root** user (for example `ubuntu` or `deploy`).

---

### 2. Create an SSH key for the first repo (englishnesia)

```bash
ssh-keygen -t ed25519 -C "deploy-englishnesia" -f ~/.ssh/github_englishnesia -N ""
```

---

### 3. Create an SSH key for the second repo (studiku)

```bash
ssh-keygen -t ed25519 -C "deploy-studiku" -f ~/.ssh/github_studiku -N ""
```

Generated files in `~/.ssh/`:

* `github_englishnesia` + `.pub`
* `github_studiku` + `.pub`

---

### 4. Set file permissions

```bash
chmod 700 ~/.ssh
chmod 600 ~/.ssh/github_englishnesia ~/.ssh/github_studiku
chmod 644 ~/.ssh/github_englishnesia.pub ~/.ssh/github_studiku.pub
```

---

### 5. Add public keys in GitHub (twice, one per repo)

```bash
echo "=== Pubkey untuk repo englishnesia ==="
cat ~/.ssh/github_englishnesia.pub
echo "=== Pubkey untuk repo studiku ==="
cat ~/.ssh/github_studiku.pub
```

For **each** repository: open **Settings → Deploy keys → Add deploy key**, paste the matching public key, and use titles such as `EC2 — englishnesia` and `EC2 — studiku`. Keep it **read-only** unless write access is truly required.

![Screenshot of GitHub Deploy Keys page](https://ik.imagekit.io/n1hqrcegw/articles/secure-git-clone-github-ec2-complete-guide/image-01.webp)
*Screenshot: Add deploy key form in GitHub repository settings.*

---

### 6. Use one `~/.ssh/config` file for two Hosts

```bash
nano ~/.ssh/config
```

```bash
Host github.com-englishnesia
    HostName github.com
    User git
    IdentityFile ~/.ssh/github_englishnesia
    IdentitiesOnly yes

Host github.com-studiku
    HostName github.com
    User git
    IdentityFile ~/.ssh/github_studiku
    IdentitiesOnly yes
```

```bash
chmod 600 ~/.ssh/config
```

`IdentitiesOnly yes` prevents SSH from trying other keys, so connection to repo A does not accidentally use repo B's key.

![Screenshot example of ssh config file](https://ik.imagekit.io/n1hqrcegw/articles/secure-git-clone-github-ec2-complete-guide/image-02.webp)
*Screenshot: `~/.ssh/config` with two Host aliases for two different repositories.*

---

### 7. Test connection (optional)

```bash
ssh -T github.com-englishnesia
ssh -T github.com-studiku
```

---

### 8. Clone both repositories into `/var/www` (replace `YOUR_USERNAME`)

```bash
cd /var/www
git clone --branch main --single-branch git@github.com-englishnesia:YOUR_USERNAME/englishnesia.git englishnesia.id
git clone --branch dev --single-branch git@github.com-studiku:YOUR_USERNAME/studiku.git dev.englishnesia.id
```

With this setup, **englishnesia** is in `/var/www/englishnesia.id` (only `main`), and **studiku** is in `/var/www/dev.englishnesia.id` (only `dev`) based on your project naming convention, without storing PATs on the server.

---

## How to manage `main` and `dev` branches (per repo)

To keep deployments stable, use one working directory per main branch. This pattern makes rollback, auditing, and deployment automation much easier.

```bash
cd /var/www/englishnesia.id
git branch --show-current
# expected output: main
```

```bash
cd /var/www/dev.englishnesia.id
git branch --show-current
# expected output: dev
```

If one folder needs to switch branches later, run `git fetch origin` and then `git checkout <branch>`. For production, it is still safer to stay consistent: `englishnesia.id = main`, `dev.englishnesia.id = dev`.

---

## Production security best practices on EC2

### Restrict SSH access to the instance (Security Group)

Avoid open SSH access from `0.0.0.0/0`; restrict access with static IPs, VPN, or Session Manager whenever possible.

### Dedicated deployment user

```bash
sudo adduser deploy
```

Do not routinely clone as **root**.

### One key pair per repository

For **two repos**, use **two** deploy keys (two key pairs), aligned with GitHub's limitation and a smaller *blast radius*.

### Read-only deploy key

Enable write only if the server must **push** to GitHub.

### Minimize PAT usage on the server

If HTTPS is unavoidable, use a **fine-grained PAT** with minimum scope, but still prioritize SSH + deploy keys for cloning on EC2.

### Safe permissions for projects without file uploads

If your application does not need runtime upload/write access, keep source code **read-only** for the web server:

```bash
sudo chown -R deploy:www-data /var/www/englishnesia.id /var/www/dev.englishnesia.id
sudo find /var/www/englishnesia.id /var/www/dev.englishnesia.id -type d -exec chmod 755 {} \;
sudo find /var/www/englishnesia.id /var/www/dev.englishnesia.id -type f -exec chmod 644 {} \;
```

Key principles:

* Directories `755`, files `644`
* Avoid `777`
* Do not grant write permissions to the web server user unless absolutely necessary
* Sensitive files such as `.env` can be restricted further to `640`

## Conclusion

**The safest way to git clone GitHub repositories to AWS EC2** is: one deploy key per repository, strict SSH file permissions, and clear `Host` alias mapping in `~/.ssh/config`. This approach improves repository security, maintainability, and readiness for `main` and `dev` deployment workflows.

---

## Bonus: quick script — two repos (englishnesia & studiku)

```bash
# Kunci repo 1 & 2
ssh-keygen -t ed25519 -C "deploy-englishnesia" -f ~/.ssh/github_englishnesia -N ""
ssh-keygen -t ed25519 -C "deploy-studiku" -f ~/.ssh/github_studiku -N ""

chmod 700 ~/.ssh
chmod 600 ~/.ssh/github_englishnesia ~/.ssh/github_studiku
chmod 644 ~/.ssh/github_englishnesia.pub ~/.ssh/github_studiku.pub

cat ~/.ssh/github_englishnesia.pub
cat ~/.ssh/github_studiku.pub
# Daftarkan masing-masing di Settings → Deploy keys repo yang sesuai

cat >> ~/.ssh/config <<'EOF'
Host github.com-englishnesia
    HostName github.com
    User git
    IdentityFile ~/.ssh/github_englishnesia
    IdentitiesOnly yes

Host github.com-studiku
    HostName github.com
    User git
    IdentityFile ~/.ssh/github_studiku
    IdentitiesOnly yes
EOF

chmod 600 ~/.ssh/config

ssh -T github.com-englishnesia
ssh -T github.com-studiku

cd /var/www
git clone --branch main --single-branch git@github.com-englishnesia:YOUR_USERNAME/englishnesia.git englishnesia.id
git clone --branch dev --single-branch git@github.com-studiku:YOUR_USERNAME/studiku.git dev.englishnesia.id

# Hardening permission (tanpa fitur upload file)
sudo chown -R deploy:www-data /var/www/englishnesia.id /var/www/dev.englishnesia.id
sudo find /var/www/englishnesia.id /var/www/dev.englishnesia.id -type d -exec chmod 755 {} \;
sudo find /var/www/englishnesia.id /var/www/dev.englishnesia.id -type f -exec chmod 644 {} \;
```

Deployment from repository to VPS can continue with a similar pattern in [deploy Laravel to VPS](/blog/deploy-laravel-to-vps) if your stack uses Laravel.



Amazon Web Services (AWS) provides **Amazon S3** for file storage and **Amazon CloudFront** as a Content Delivery Network (CDN) to accelerate content delivery. Replacing your S3 file URLs with CloudFront URLs is an essential step to ensure your files load faster, more securely, and more professionally.

In this guide, we’ll walk through the complete process—from configuring CloudFront to updating your S3 file URLs.

---

## **Why Should You Replace S3 URLs With CloudFront URLs?**

Before we dive into the setup steps, here are the main reasons why CloudFront is highly recommended over directly serving files from S3:

- **Faster load times** thanks to global edge locations.
- **More stable performance** with content cached close to your users.
- **Stronger security** with Origin Access Control (OAC), HTTPS, and signed URLs.
- **More professional URLs**, like `https://cdn.yourdomain.com/image.jpg`.
- **Lower data transfer costs** when configured correctly.

---

# **Steps to Replace S3 URLs with CloudFront URLs**

---

## **1. Prepare Your S3 Bucket**

Make sure your S3 bucket contains the files you want to deliver through CloudFront.

**Checklist:**

- Ensure the bucket has the correct permissions.
- Upload all required files.
- You can keep **Block Public Access** enabled, because CloudFront will access the bucket using OAC.

---

## **2. Create a CloudFront Distribution (New UI – 5 Steps)**

When you click **Create distribution**, CloudFront now displays a new 5-step wizard:

- Step 1 – Choose a plan
- Step 2 – Get started
- Step 3 – Specify origin
- Step 4 – Enable security
- Step 5 – Review and create

Below is the detailed walkthrough for each step.

---

## **Step 1 – Choose a plan**

You’ll see several plan options:

- **Free – $0/month**
- **Pro – $15/month**
- **Business – $200/month**
- **Premium – $1000/month**

And at the bottom:

- **Pay as you go (Pricing varies with usage)**

For standard CDN usage (websites, apps, static assets), the best option is:

✅ **Pay as you go** — no fixed monthly cost, pay only for what you use.

Click **Next** to continue.

![Step 01](https://ik.imagekit.io/n1hqrcegw/articles/update-s3-urls-to-cloudfront/step-01.webp)

---

## **Step 2 – Get started**

Here you define the basic configuration of your distribution.

### Fields to complete:

1. **Distribution name**
   Use a clear, identifiable name, for example:

   ```
   s3-ferry-example
   ```

2. **Description (optional)**
   You may add a short note, or leave it empty.

3. **Distribution type**
   Choose:

   ✅ **Single website or app**

   (Use Multi-tenant only for SaaS platforms with shared architecture across multiple domains.)

4. **Domain (optional)**
   If you have a Route 53 domain and want to attach a custom CDN domain immediately, you may enter it here.
   If your DNS is hosted elsewhere, you can skip this for now and set it up later using your DNS provider + ACM SSL.

Click **Next**.

![Step 02](https://ik.imagekit.io/n1hqrcegw/articles/update-s3-urls-to-cloudfront/step-02.webp)

---

## **Step 3 – Specify origin**

This is where you connect CloudFront to your S3 bucket.

### 1. Origin type

Select:
✅ **Amazon S3**

### 2. S3 origin

Choose or type your S3 bucket endpoint, for example:

```
ferry-example.s3.ap-southeast-1.amazonaws.com
```

You can also use **Browse S3** to select your bucket.

### 3. Origin path (optional)

If you want CloudFront to serve only a specific folder:

```
/path
```

Examples: `/uploads`, `/assets/images`
Leave this empty to serve the entire bucket.

### 4. Allow private S3 bucket access to CloudFront

This is critical for security.

Check:

✅ **Allow private S3 bucket access to CloudFront – Recommended**

This ensures:

- Your bucket remains **private** (Block Public Access ON)
- CloudFront automatically updates bucket policies so only this distribution can access it

### 5. Origin & cache settings

Default settings are ideal:

- **Origin settings** → ✅ _Use recommended origin settings_
- **Cache settings** → ✅ _Use recommended cache settings tailored to serving S3 content_

Click **Next**.

![Step 03](https://ik.imagekit.io/n1hqrcegw/articles/update-s3-urls-to-cloudfront/step-03.webp)

---

## **Step 4 – Enable security**

This step configures Web Application Firewall (WAF) protections.

You have two choices:

### 1. ✅ **Enable security protections**

Includes:

- Protection against common web vulnerabilities
- Malicious traffic filtering
- IP blocking
- Optional Layer 7 DDoS protection (Recommended)

Best for dynamic apps, APIs, login pages, or any high-traffic service.

### 2. ❌ **Do not enable security protections**

Good option if you're serving **static files only** and want to reduce cost.

### Optional:

- **Use monitor mode** — view what would be blocked before enforcing it.

Click **Next** after choosing.

![Step 04](https://ik.imagekit.io/n1hqrcegw/articles/update-s3-urls-to-cloudfront/step-04.webp)

---

## **Step 5 – Review and create**

CloudFront will display a summary of your configuration:

### General configuration

- Distribution name
- Billing (e.g., Pay-as-you-go)

### Origin

- S3 origin (bucket + region)
- Origin path
- CloudFront access: **Yes**

### Cache settings

- Using recommended S3-optimized cache settings

### Security

- Whether WAF protections are enabled

If everything looks correct:

✅ Click **Create distribution**

![Step 05](https://ik.imagekit.io/n1hqrcegw/articles/update-s3-urls-to-cloudfront/step-05.webp)

Wait a few minutes until the status becomes **Enabled**.

---

# **Conclusion**

Updating your S3 URLs to CloudFront is one of the most effective ways to improve website speed, reliability, and security. The process is simple: create a CloudFront distribution, link it with your S3 bucket, and replace your S3 URLs with your new CloudFront domain.



Amazon S3 (Simple Storage Service) is a popular cloud storage service from AWS that allows users to store and retrieve any amount of data at any time. Whether you're hosting static websites, storing backups, or serving media content, S3 is a reliable and scalable solution.

In this guide, you'll learn how to create an S3 bucket step-by-step using the AWS Console.

---

## Step 1: Log in to AWS Console

Start by logging in to your AWS account via the [AWS Management Console](https://aws.amazon.com/console/).

![image 1](https://ik.imagekit.io/n1hqrcegw/articles/cara-membuat-amazon-s3-bucket-di-aws/gambar-01.webp?updatedAt=1733887150760)

---

## Step 2: Open the Amazon S3 Service

After logging in, search for **S3** in the search bar at the top and click the **S3** service.

![image 2](https://ik.imagekit.io/n1hqrcegw/articles/cara-membuat-amazon-s3-bucket-di-aws/gambar-02.webp?updatedAt=1733887150760)

---

## Step 3: Create a New Bucket

- Click the **Create bucket** button.  
- Enter a unique **Bucket name** (must be globally unique).  
- Under **Object Ownership**, choose **ACLs disabled (recommended)** to simplify permissions.

![image 3](https://ik.imagekit.io/n1hqrcegw/articles/cara-membuat-amazon-s3-bucket-di-aws/gambar-03.webp?updatedAt=1733887150760)

---

## Step 4: Configure Encryption

- Scroll down to the **Default encryption** section.  
- Choose **Amazon S3 managed keys (SSE-S3)**.  
- Enable the **Bucket Key** to reduce the cost of encryption requests.

![image 4](https://ik.imagekit.io/n1hqrcegw/articles/cara-membuat-amazon-s3-bucket-di-aws/gambar-04.webp?updatedAt=1733887150760)

---

## Step 5: Finalize and View Your Bucket

After completing the setup, your new bucket will appear in the S3 bucket list.

![image 5](https://ik.imagekit.io/n1hqrcegw/articles/cara-membuat-amazon-s3-bucket-di-aws/gambar-05.webp?updatedAt=1733887150760)

Click the bucket name to open it and start uploading files, setting permissions, or enabling static website hosting.

![image 6](https://ik.imagekit.io/n1hqrcegw/articles/cara-membuat-amazon-s3-bucket-di-aws/gambar-06.webp?updatedAt=1733887150760)

---

## Conclusion

Setting up an S3 bucket is simple and essential for many AWS-powered applications. With just a few clicks, you can start storing data securely in the cloud. Don't forget to manage access policies and monitor your storage usage for optimal performance and cost.

Need help with setting permissions or enabling static site hosting? Stay tuned for our upcoming guides on advanced S3 configurations!


Enabling HTTPS on your website is crucial for security, SEO, and user trust. Thankfully, Let’s Encrypt offers free SSL/TLS certificates that are easy to set up on an Nginx server. In this tutorial, we’ll walk through how to secure your Nginx server using Let’s Encrypt on Ubuntu.

---

## Step 1: Check Your Website Before SSL

Before adding SSL, your website is likely still served over plain HTTP.

Example:
`http://jadifullstack.id`

![Image 1](https://ik.imagekit.io/n1hqrcegw/articles/cara-mengamankan-nginx-ssl-tls-https-lets-encrypt-ubuntu/gambar-01.webp?updatedAt=1733852578858)

---

## Step 2: Install Certbot and the Nginx Plugin

Make sure your system is up to date:

```bash
sudo apt update
sudo apt install certbot python3-certbot-nginx
```

Certbot is the tool that will communicate with Let’s Encrypt and configure Nginx automatically.

---

## Step 3: Request an SSL Certificate

Run the following command to request and install your SSL certificate:

```bash
sudo certbot --nginx -d jadifullstack.id
```

If successful, you'll see a confirmation message:

> "Successfully received certificate"

![Image 2](https://ik.imagekit.io/n1hqrcegw/articles/cara-mengamankan-nginx-ssl-tls-https-lets-encrypt-ubuntu/gambar-02.webp?updatedAt=1733852578858)

---

## Step 4: Verify HTTPS is Working

After a successful setup, your website will now be accessible via HTTPS.

Example:
`https://jadifullstack.id`

![Image 3](https://ik.imagekit.io/n1hqrcegw/articles/cara-mengamankan-nginx-ssl-tls-https-lets-encrypt-ubuntu/gambar-03.webp?updatedAt=1733852578858)

Check that your browser shows a secure padlock and that HTTP requests are redirected to HTTPS.

---

## Step 5: Enable Auto Renewal

Let’s Encrypt certificates expire every 90 days. Certbot makes it easy to auto-renew them.

You can verify the auto-renewal configuration with this command:

```bash
sudo certbot renew --dry-run
```

To schedule auto-renewal using `cron`, run:

```bash
crontab -e
```

Then add the following line to renew the certificate daily at noon:

```bash
0 12 * * * /usr/bin/certbot renew --quiet
```

![Image 4](https://ik.imagekit.io/n1hqrcegw/articles/cara-mengamankan-nginx-ssl-tls-https-lets-encrypt-ubuntu/gambar-04.webp?updatedAt=1733852578858)

---

## Conclusion

Now your Ubuntu VPS running Nginx is secured with HTTPS using a free SSL certificate from Let’s Encrypt. This simple setup improves trust, SEO ranking, and data protection. Always monitor your certificate expiration or use Certbot's auto-renewal to avoid disruptions.

Want to take it further? Consider setting up a redirect from HTTP to HTTPS or enabling HTTP/2 for better performance!





Amazon Web Services (AWS) offers a wide range of **EC2 instance types**, each designed for specific workloads. If you have ever wondered what those names like **t2.medium**, **m5.large**, **c6i.32xlarge**, or **g5.2xlarge** mean, this guide will help you decode them and choose the best fit for your application.

---

## What Is an EC2 Instance?
An **EC2 instance** is a virtual server running on AWS infrastructure. Each instance type has a specific balance of **CPU, memory, storage, and networking capacity**, optimized for different use cases such as general computing, machine learning, or high-performance databases.

---

## How to Read EC2 Instance Names
An instance name like `c6i.32xlarge` can be broken down into three main parts:

- **Prefix letter(s)** → indicates the **instance family** (e.g., `t`, `m`, `c`, `g`).
- **Generation number** → shows the **version** (e.g., `6` is newer than `5`).
- **Suffix / size** → defines **hardware details** (e.g., `.large`, `.xlarge`, `.metal`).

Example:  
- `c6i.32xlarge` → **Compute Optimized**, **6th generation**, Intel CPU (`i`), **32xlarge size**.

---

## EC2 Instance Families Explained

### 1. General Purpose
- **t Family** – Burstable general purpose (e.g., `t2`, `t3`, `t4g`).  
  Best for: Low-traffic websites, dev/test workloads.  

- **m Family** – Balanced general purpose (e.g., `m5`, `m6i`, `m7g`).  
  Best for: Application servers, small to medium databases, general workloads.

---

### 2. Compute Optimized
- **c Family** – High CPU power compared to memory (e.g., `c5`, `c6i`).  
  Best for: High-performance computing, batch processing, game servers.  

---

### 3. Memory Optimized
- **r Family** – High memory per vCPU (e.g., `r5`, `r6g`).  
  Best for: In-memory caches, big data, real-time analytics.  

- **x Family** – Extra memory (e.g., `x1e`, `x2idn`).  
  Best for: Large in-memory databases like SAP HANA.  

- **z Family** – High frequency CPUs + large memory (e.g., `z1d`).  
  Best for: EDA, financial simulations, latency-sensitive workloads.  

---

### 4. Storage Optimized
- **d Family** – Dense HDD storage (e.g., `d2`).  
  Best for: Data warehouses, Hadoop, distributed storage.  

- **i Family** – High IOPS NVMe SSD (e.g., `i3`, `i4i`).  
  Best for: NoSQL databases, OLTP.  

- **h Family** – High throughput HDD (e.g., `h1`).  
  Best for: Data-intensive workloads with sequential reads/writes.  

---

### 5. Accelerated Computing
- **g Family** – GPU for graphics/ML inference (e.g., `g4dn`, `g5`).  
  Best for: Machine learning inference, 3D rendering, remote workstations.  

- **p Family** – GPU for ML training/HPC (e.g., `p3`, `p4d`).  
  Best for: Deep learning training, scientific computing.  

- **f Family** – FPGA instances (e.g., `f1`).  
  Best for: Custom hardware acceleration.  

- **inf Family** – AWS Inferentia chip (e.g., `inf1`).  
  Best for: AI inference at low cost.  

- **trn Family** – AWS Trainium chip (e.g., `trn1`).  
  Best for: Deep learning training at scale.  

---

## Instance Size Naming
Each instance has multiple sizes, for example:

- `.nano`, `.micro`, `.small` – Very small workloads.  
- `.medium`, `.large` – Moderate workloads.  
- `.xlarge`, `.2xlarge`, `.4xlarge` … `.32xlarge` – Increasing CPU & RAM.  
- `.metal` – Bare metal access (direct hardware).  

Example:  
- `m6i.large` → 2 vCPU, 8 GB RAM.  
- `m6i.32xlarge` → 128 vCPU, 512 GB RAM.  

---

## Choosing the Right Instance
When selecting an EC2 instance, consider:

1. **Workload type** – Is it CPU-bound, memory-intensive, or GPU-dependent?  
2. **Cost efficiency** – Graviton (`g`) instances often provide better price/performance.  
3. **Scalability** – Start small and scale up as demand grows.  
4. **Storage needs** – Do you need high IOPS SSDs (`i` family) or dense HDDs (`d` family)?  

---

## Quick Reference Table

| Family | Optimized For           | Example Instances | Best Use Cases |
|--------|--------------------------|------------------|----------------|
| t      | Burstable General        | t3, t4g          | Dev/test, small apps |
| m      | Balanced General         | m5, m6i, m7g     | Web/app servers, DBs |
| c      | Compute                  | c5, c6i          | HPC, game servers |
| r      | Memory                   | r5, r6g          | In-memory DB, big data |
| x      | Extra Memory             | x1e, x2idn       | SAP HANA, large DBs |
| z      | High Frequency + Memory  | z1d              | Financial sims, EDA |
| d      | Dense Storage            | d2               | Data warehouse |
| i      | High IOPS SSD            | i3, i4i          | NoSQL, OLTP |
| g      | GPU (Graphics/ML)        | g4dn, g5         | ML inference, 3D |
| p      | GPU (Training)           | p3, p4d          | DL training, HPC |
| f      | FPGA                     | f1               | Hardware accel |
| inf    | Inferentia (AI infer.)   | inf1             | AI inference |
| trn    | Trainium (AI training)   | trn1             | AI training |

---

## Final Thoughts
AWS EC2 instance names may look confusing at first, but once you understand the **family, generation, and size**, it becomes easier to choose the right one. Whether you need a **cheap burstable server (t2)**, a **balanced general-purpose option (m5)**, a **compute powerhouse (c6i)**, or a **GPU instance (g5)**, AWS has a type tailored for your workload.




### 🔧 **Service Management (Ubuntu-based systems)**

| Command                             | Description                             |
| ----------------------------------- | --------------------------------------- |
| `sudo systemctl start supervisor`   | Start the Supervisor service            |
| `sudo systemctl stop supervisor`    | Stop the Supervisor service             |
| `sudo systemctl restart supervisor` | Restart Supervisor                      |
| `sudo systemctl status supervisor`  | Check the status of Supervisor          |
| `sudo systemctl enable supervisor`  | Enable Supervisor to run at boot        |
| `sudo systemctl disable supervisor` | Disable Supervisor from running at boot |

---

### ⚙️ **Supervisor CLI Commands**

These use the `supervisorctl` command:

| Command                                | Description                                          |
| -------------------------------------- | ---------------------------------------------------- |
| `sudo supervisorctl`                   | Enter Supervisor interactive mode                    |
| `sudo supervisorctl status`            | View the status of all managed processes             |
| `sudo supervisorctl start <program>`   | Start a specific program                             |
| `sudo supervisorctl stop <program>`    | Stop a specific program                              |
| `sudo supervisorctl restart <program>` | Restart a specific program                           |
| `sudo supervisorctl reread`            | Reread config files (does **not** apply changes yet) |
| `sudo supervisorctl update`            | Apply changes after `reread` (add/remove programs)   |
| `sudo supervisorctl reload`            | Restart Supervisor and all managed processes         |
| `sudo supervisorctl shutdown`          | Gracefully shut down Supervisor daemon               |

---

### 📁 **Supervisor Config Locations (Ubuntu)**

| Path                               | Description                                        |
| ---------------------------------- | -------------------------------------------------- |
| `/etc/supervisor/supervisord.conf` | Main Supervisor config file                        |
| `/etc/supervisor/conf.d/`          | Directory to store individual program config files |

---

### 🛠️ **Example Workflow After Adding a New Program**

```bash
sudo supervisorctl reread
sudo supervisorctl update
sudo supervisorctl start your_program_name
```




### 🚀 **Basic Process Management**

| **Command**                                            | **Description**                                    |
| ------------------------------------------------------ | -------------------------------------------------- |
| `pm2 start app.js`                                     | Start a Node.js application                        |
| `pm2 start app.js --name my-app`                       | Start the app with a custom process name           |
| `pm2 list`                                             | List all running processes managed by PM2          |
| `pm2 show <id or name>` or `pm2 describe <id or name>` | Show detailed information about a specific process |
| `pm2 restart <id or name>`                             | Restart a specific process                         |
| `pm2 reload <id or name>`                              | Gracefully reload a process (zero downtime)        |
| `pm2 stop <id or name>`                                | Stop a specific process                            |
| `pm2 delete <id or name>`                              | Delete a process from the PM2 process list         |
| `pm2 delete all`                                       | Remove all processes from PM2 management           |


---

### 🔁 **Startup & Auto-Restart**

| Command         | Description                                              |
| --------------- | -------------------------------------------------------- |
| `pm2 startup`   | Generate and configure PM2 to launch on system boot      |
| `pm2 save`      | Save current process list for automatic reload on reboot |
| `pm2 resurrect` | Restore processes saved via `pm2 save`                   |

---

### 📈 **Monitoring & Logs**

| **Command**             | **Description**                                     |
| ----------------------- | --------------------------------------------------- |
| `pm2 monit`             | Launch PM2's real-time process monitoring dashboard |
| `pm2 logs`              | Show logs for all processes                         |
| `pm2 logs <id or name>` | Show logs for a specific process                    |
| `pm2 flush`             | Clear all logs                                      |
| `pm2 reloadLogs`        | Reload logs in real-time                            |

---

### 🛠️ **Miscellaneous**

| **Command**                      | **Description**                                   |
| -------------------------------- | ------------------------------------------------- |
| `pm2 env <id or name>`           | Show environment variables for a specific process |
| `pm2 reload ecosystem.config.js` | Reload all apps defined in an ecosystem file      |
| `pm2 start ecosystem.config.js`  | Start all apps from an ecosystem file             |





A complete and beginner-friendly guide to install **Certbot Let’s Encrypt SSL** on **Ubuntu servers with NGINX**, enabling free **HTTPS encryption** with **automatic certificate renewal**.

---

## 📦 Installing Certbot on Ubuntu 16.04

For users running Ubuntu 16.04, execute the following commands:

```bash
apt-get update
sudo apt-get install certbot
sudo apt-get install python-certbot-nginx
```

---

## 📦 Installing Certbot on Ubuntu 18.04 and Later

For Ubuntu 18.04 or any newer version, run the following:

```bash
apt-get update
sudo apt-get install certbot
sudo apt-get install python3-certbot-nginx
```

---

## 🌐 Obtain a Let’s Encrypt SSL Certificate for NGINX

Once Certbot is installed, use this command to **automatically configure HTTPS for your domain**:

```bash
sudo certbot --nginx -d example.com
```

Replace `example.com` with your actual domain name.

---

## 🔁 Automatically Renew Let’s Encrypt SSL Certificates

To ensure your SSL certificates are **renewed automatically**, add a cron job as follows:

### Edit Crontab

```bash
crontab -e
```

### Add the Following Line

```bash
0 12 * * * /usr/bin/certbot renew --quiet
```

This command runs the renewal process **daily at 12:00 PM**.

---

## ✅ Conclusion

Your website is now secured with **free HTTPS using Let’s Encrypt**, and the SSL certificate will automatically renew without manual intervention.



### 🔧 **Service Management**

Use `sudo` if you're not logged in as root.

| Command                        | Description                                       |
| ------------------------------ | ------------------------------------------------- |
| `sudo systemctl start nginx`   | Start the Nginx service                           |
| `sudo systemctl stop nginx`    | Stop the Nginx service                            |
| `sudo systemctl restart nginx` | Restart Nginx and reload all configs              |
| `sudo systemctl reload nginx`  | Reload config without dropping active connections |
| `sudo systemctl status nginx`  | Check the current status of Nginx                 |
| `sudo systemctl enable nginx`  | Enable Nginx to start at boot                     |
| `sudo systemctl disable nginx` | Disable Nginx from auto-starting at boot          |

---

### ⚙️ **Configuration & Testing**

| Command                | Description                                 |
| ---------------------- | ------------------------------------------- |
| `sudo nginx -t`        | Test Nginx configuration for syntax errors  |
| `sudo nginx -s reload` | Reload Nginx via CLI                        |
| `sudo nginx -s stop`   | Stop Nginx via CLI                          |
| `sudo nginx -s quit`   | Gracefully shut down Nginx                  |
| `nginx -v`             | Show Nginx version                          |
| `nginx -V`             | Show version with build options and modules |

---

### 📁 **Default Configuration Paths (Ubuntu)**

| Path                          | Description                                                    |
| ----------------------------- | -------------------------------------------------------------- |
| `/etc/nginx/nginx.conf`       | Main Nginx config file                                         |
| `/etc/nginx/sites-available/` | Directory for available virtual host configs                   |
| `/etc/nginx/sites-enabled/`   | Directory for enabled sites (symlinked from `sites-available`) |
| `/var/www/html/`              | Default web root directory                                     |

---

### 🛠️ **Extra Tips**

* After editing the config:

  ```bash
  sudo nginx -t && sudo systemctl reload nginx
  ```

* To view logs:

  ```bash
  tail -f /var/log/nginx/access.log
  tail -f /var/log/nginx/error.log
  ```


Ferry Dermawan

Blog

Shorts