Skip to content
all notes

Tech · · 5 min read · 29 views

Aku Dah Ada Domain, So Apa Benda Aku Boleh Explore Dengan AWS Secara Free?

Aku jadikan domain sendiri sebagai AWS playground untuk belajar cloud, deployment, security dan CI/CD tanpa kacau production website. This is technically just my notes, but I asked ChatGPT to turn them into a story, so why not share it here too? Hehehe

Aku dah ada domain sendiri, suraiyaanr.com. Jadi daripada sekadar biarkan domain tu jadi portfolio website, aku terfikir:

“Eh, kalau aku nak belajar AWS, apa sebenarnya yang aku boleh buat dengan domain aku ni?”

Jawapan pendeknya: banyak.

Dan aku rasa daripada terus fikir nak migrate production website ke AWS, lagi baik aku jadikan domain sendiri sebagai lab untuk belajar cloud deployment.

Basically, aku boleh buat satu playground khas untuk test benda-benda AWS tanpa kacau website utama.

Contohnya:

suraiyaanr.com
      │
      └── AWS Playground
              │
              ├── EC2
              ├── Route 53
              ├── S3
              ├── CloudFront
              ├── IAM
              ├── ACM
              └── CloudWatch

AWS pun ada Free Tier / credit untuk account baru, bergantung pada kelayakan dan jenis account. Jadi memang sesuai untuk buat exploration macam ni dulu sebelum fikir pasal production.

Cuma satu benda penting:

Free bukan bermaksud semua benda dalam AWS free.

AWS ada banyak service yang boleh generate cost kalau salah setup. Jadi sebelum main tekan apa-apa, kena faham dulu apa yang kita create dan macam mana billing dia bekerja.


Sebelum Main AWS — Secure Dulu

Okay, ini sebenarnya aku rasa patut jadi Step 0.

Sebab bila kita belajar AWS, kita bukan sekadar belajar:

“Macam mana nak create EC2?”

Kita juga kena belajar:

“Macam mana nak pastikan orang lain tak boleh create 50 EC2 guna account aku?” 😭

AWS account ada satu identity yang dipanggil root user. Root user mempunyai access penuh kepada account, jadi AWS memang recommend supaya root user tidak digunakan untuk kerja harian.

1. Enable MFA untuk root

First thing yang aku akan buat:

Enable MFA.

Kalau boleh, AWS sekarang recommend phishing-resistant MFA seperti passkey atau security key. Virtual authenticator app pun disokong.

Mental model dia:

Password
   +
MFA
   ↓
AWS Account

Jangan rasa:

“Aku account kecil je, siapa nak hack?”

Cloud account kecil pun boleh jadi target sebab attacker bukan semestinya nak website kita.

Kadang-kadang yang dia nak ialah gunakan cloud resources kita untuk benda lain, dan kita yang dapat bil. 💀


2. Jangan guna root untuk kerja harian

Root user tu macam:

GOD MODE

Jadi jangan login root setiap kali nak create EC2, S3 bucket atau tengok setting.

AWS sendiri recommend root user digunakan hanya untuk task tertentu yang memang memerlukan root credentials.

Untuk kerja biasa, gunakan identity lain yang appropriate.

Untuk setup yang lebih proper, AWS sekarang recommend IAM Identity Center untuk human users dan penggunaan temporary credentials.


3. Jangan create Root Access Key

Ini satu lagi yang penting.

Jangan buat access key untuk root user.

Access key basically bagi application/CLI peluang untuk call AWS API.

Kalau credential tu bocor, memang masalah.

AWS secara jelas recommend supaya root access keys tidak dibuat dan workload menggunakan temporary credentials / IAM roles bila boleh.

Mental model:

❌ Root
   ↓
   access key
   ↓
   GitHub / laptop / app

✅ IAM Role
   ↓
   temporary credentials
   ↓
   AWS resource

4. Guna Least Privilege

Ini antara konsep AWS yang paling penting untuk aku faham:

Give only the permissions that are actually needed.

Contohnya kalau satu application cuma perlu baca file dari S3, jangan bagi dia:

s3:*

kalau tak perlu.

Lebih baik:

GetObject

untuk bucket/object yang diperlukan sahaja.

AWS panggil konsep ni least privilege — grant hanya permission yang diperlukan untuk sesuatu task dan bukan lebih daripada itu.

Awal-awal belajar mungkin rasa renyah.

Tapi lama-lama aku akan mula fikir:

“Application ni sebenarnya perlukan permission apa?”

Dan itu memang cara fikir yang penting bila bekerja dengan cloud.


5. Jangan simpan AWS credentials dalam GitHub

Yang ni aku memang kena ingat.

Kalau ada:

.env
config.php
credentials.json

atau apa-apa file yang mengandungi AWS secret:

Jangan commit ke Git.

Contoh yang sangat bahaya:

AWS_ACCESS_KEY_ID=AKIA...
AWS_SECRET_ACCESS_KEY=xxxxxxxx

kemudian:

git add .
git commit -m "deploy"
git push

💀

GitHub bukan tempat simpan secret secara plain text.

Untuk deployment yang lebih proper, gunakan IAM roles / temporary credentials atau secret-management mechanism yang sesuai.


6. Security Group — Jangan buka semua port

Bila create EC2 nanti, aku akan jumpa benda yang dipanggil Security Group.

Anggap dia macam firewall.

Contohnya untuk web server:

Internet
   │
   ├── 80  → HTTP
   ├── 443 → HTTPS
   │
   └── 22  → SSH

Tapi jangan simply buat:

0.0.0.0/0

untuk semua port.

Kalau web server perlukan HTTP/HTTPS, buka yang diperlukan sahaja.

Untuk SSH pula, lagi bagus restrict access daripada buka SSH kepada seluruh internet kalau architecture/setup aku membenarkan.


7. Set AWS Budget dari awal

Okay, ini bukan security dalam maksud cybersecurity, tapi bagi aku ia adalah security juga:

security untuk wallet. 😂

Aku akan set:

AWS
 ↓
Budgets
 ↓
Alert
 ↓
Email

Contohnya:

“Kalau spending dah mencecah amount tertentu, email aku.”

AWS sendiri memasukkan AWS Budgets dan Cost Anomaly Detection dalam recommended account-security baseline untuk membantu detect unexpected spending.

Untuk account belajar, benda ni wajib aku buat awal-awal.


8. Enable logging & monitoring

Bila dah mula explore lebih banyak service, aku nak tahu:

“Siapa buat perubahan dekat AWS account aku?”

Dekat sinilah CloudTrail penting.

CloudTrail merekod activity/API events dalam AWS. AWS notes bahawa console menyediakan event history terhad, tetapi untuk rekod berterusan, kita perlu create a trail.

Mental model:

AWS Activity
     ↓
CloudTrail
     ↓
Logs
     ↓
“Apa benda yang berlaku?”

Lepas tu boleh explore pula:

CloudWatch

untuk metrics, logs dan alarms.


9. Jangan terus expose S3 kepada public

Bila belajar S3 nanti, satu benda yang aku kena biasakan:

Private by default.

Jangan buat:

S3 Bucket
   ↓
Public
   ↓
Anyone can access

semata-mata sebab nak test.

AWS security baseline juga secara khusus mengesyorkan supaya public access kepada private S3 buckets dicegah.

Kalau memang ada file yang perlu public, faham dulu kenapa file tu public dan apa access mechanism yang digunakan.


So, security checklist aku

Sebelum aku start main EC2, checklist aku:

☐ MFA untuk root
☐ Jangan guna root untuk kerja harian
☐ Jangan create root access keys
☐ Setup proper IAM / Identity Center access
☐ Gunakan least privilege
☐ Jangan commit AWS secrets ke Git
☐ Security Group jangan buka semua port
☐ Setup AWS Budget / spending alert
☐ Enable / understand CloudTrail
☐ S3 jangan public sesuka hati

Ini nampak macam banyak.

Tapi sebenarnya aku lagi suka belajar AWS macam ni.

Bukan:

Create EC2
↓
Deploy Laravel
↓
Done

Tapi:

Secure account
      ↓
IAM
      ↓
EC2
      ↓
Network
      ↓
Laravel
      ↓
Monitoring
      ↓
CI/CD

Security bukan benda yang ditampal dekat hujung project.

Kita build dengan security dari awal.


Lepas dah secure, baru masuk EC2

Barulah aku proceed dengan:

AWS Account
   ↓
Security
   ↓
IAM
   ↓
EC2
   ↓
Ubuntu
   ↓
SSH
   ↓
Nginx
   ↓
Laravel

Lepas tu baru sambung domain:

aws.suraiyaanr.com
        ↓
      EC2
        ↓
     Laravel

Then boleh naik level:

S3
 ↓
CloudFront
 ↓
ACM / HTTPS
 ↓
CloudWatch
 ↓
GitHub Actions
 ↓
CI/CD

Jadi AWS playground aku bukan sekadar tempat untuk “try AWS”.

Aku boleh jadikan dia satu mini project yang gradually ajar aku:

Linux → networking → cloud → security → deployment → CI/CD → monitoring.

Dan itu jauh lebih menarik daripada sekadar tengok 15 video AWS dan akhirnya lupa apa beza EC2 dengan S3. 😂

–SA

Enjoyed something I wrote? buy me a coffee (opens in a new tab)

psst, the labels are clickable

3,724 visitors