Introduction
In the cloud, there is one rule that never changes: “If it is not logged, it did not happen — and if you cannot monitor it, you cannot protect it.” Many businesses assume that once they move to AWS, Azure, or Google Cloud, logging and monitoring work automatically. This is one of the most costly mistakes in cloud security.
In 2025, the Indonesian Cyber Security Institute (ICSI) reported that 42% of cloud breach victims could not identify how attackers entered their systems because audit logs were disabled, incomplete, or deleted. Another 37% of organizations missed early warning signs of attacks because they only checked logs once a month or had no alerts configured at all.
Furthermore, regulations like Indonesia’s PDP Law No.27/2022, GDPR, and PCI DSS mandate that you keep complete, unaltered records of all activity — and being unable to produce these records results in fines starting from IDR 100 million, even if no breach occurred.
This fully expanded guide explains the difference between logging and monitoring, exactly what you must record, how to build an unbreakable log system, compare the best tools, set up effective alerts, and meet every compliance requirement — with clear tables and step-by-step examples you can implement today.
Core Concepts: Logging vs Monitoring
Many teams use these terms interchangeably, but they have distinct roles that work together:
Table
| Aspect | Logging | Monitoring |
|---|---|---|
| Purpose | Record facts about what happened | Detect anomalies and warn of risks |
| What it does | Stores permanent evidence for audits and investigations | Checks real-time activity against expected patterns |
| Key Question | “Who did what, when, and from where?” | “Is this activity normal or dangerous?” |
| Timeline | Historical — kept for months or years | Real-time — reacts within seconds or minutes |
| Output | Structured data files with timestamps | Alerts, dashboards, and automated actions |
| Compliance | Mandatory — required by law | Highly recommended — often required for certification |
Why You Need Both: Logging without monitoring means you have evidence but no warning. Monitoring without logging means you get alerts but cannot prove what happened or investigate properly.
What You Must Log: Complete List & Requirements
Not all logs are equal — these are the categories you must enable for full protection and compliance:
Table
| Log Type | What It Records | Mandatory For | Minimum Retention |
|---|---|---|---|
| Cloud Audit / Admin Logs | Every action in your cloud console: create/delete resources, change permissions, modify security settings | All regulations — PDP, GDPR, HIPAA, PCI | 12 months |
| Authentication Logs | Login success/failure, MFA attempts, password changes, new device access | Threat detection, breach investigation | 12 months |
| Network Traffic Logs | Allowed/blocked connections, source/destination IP, port, protocol, packet size | Network attacks, DDoS, unauthorized access | 6 months |
| Application & API Logs | User actions, data access, error messages, API calls, input/output | OWASP compliance, app security | 6 months |
| Database Logs | Queries, changes to data, permission access, exports of records | HIPAA, financial data, PDP Law | 12 months |
| Backup & Change Logs | Changes to backup schedules, deletions of snapshots, configuration edits | Ransomware protection, integrity checks | 12 months |
| Security Service Logs | WAF blocks, virus scans, vulnerability scans, policy violations | All security audits | 6 months |
Critical Note: For Indonesia’s PDP Law, any log that contains personal data must be kept for at least 7 years if it relates to privacy incidents — confirm your retention policy with your legal team.
Best Practices for Secure Log Management
Logs are only useful if they are complete, accurate, and cannot be tampered with. Follow these rules strictly:
1. Enable Logs by Default — Never Disable Them
- Turn on every log type available before you deploy any resource
- Never turn off logs to save storage space — log storage costs are extremely low (less than IDR 100,000 per month for most businesses)
- If a log creates too much data, filter it at the analysis stage — do not stop recording it
2. Centralize All Logs in One Place
Storing logs separately on each service makes searching and investigation impossible.
- Send all logs from AWS, Azure, Google Cloud, apps, and networks to one central repository
- This lets you trace an attack that moves between systems in one view
3. Protect Logs From Attackers
Attackers always try to delete logs to hide their tracks — protect your logs better than your production data:
Table
| Protection Rule | Explanation |
|---|---|
| Immutable Storage | Once written, logs cannot be edited, overwritten, or deleted — use WORM (Write Once Read Many) storage |
| Separate Location | Store logs in a different cloud account or region — attackers cannot reach them even if they take over your main system |
| Restricted Access | Only 1–2 senior admins can view logs — no one else can read, modify, or delete them |
| Encrypt Everywhere | Encrypt logs in transit and at rest — use your own encryption keys |
| Versioning Enabled | Keep previous versions of log files in case new entries are corrupted |
4. Standardize Log Format
Use consistent fields for every log entry:
- Timestamp (in UTC)
- Source IP address
- User/account ID
- Action performed
- Resource affected
- Success/failure status
This lets tools search and compare data automatically.
Effective Monitoring: What to Watch & How to Set Alerts
Collecting logs is useless if you do not watch for signs of trouble.
Key Events That Require Immediate Alerts
Configure high-priority notifications for these events — they indicate almost certain risk:
- Root or super-admin account login — especially from a new IP or country
- MFA disabled or authentication settings changed
- Bulk deletion of files, backups, or logs
- More than 5 failed login attempts in 10 minutes
- Security groups or firewalls opened to
0.0.0.0/0 - Changes to encryption keys or access policies
- Unusual bulk download of data (more than 1GB in one session)
- Creation of new admin accounts outside business hours
How to Avoid Alert Fatigue
Too many alerts make teams ignore real dangers — tune your system like this:
Table
| Rule | Action |
|---|---|
| Critical | Send SMS, WhatsApp, and email — respond within 15 minutes |
| High | Send urgent email and Slack — respond within 1 hour |
| Medium | Daily summary report — review within 24 hours |
| Low | Weekly report — review during scheduled maintenance |
Tip: Test alerts weekly to ensure they reach the right people and are not filtered as spam.
Tool Comparison: Native vs Open Source vs Enterprise
Choose tools based on your size and needs — no need to overspend:
Table
| Tool Category | Options | Best For | Cost | Key Strengths |
|---|---|---|---|---|
| Cloud Provider Native | AWS CloudTrail + CloudWatch, Azure Monitor, Google Cloud Logging | Small teams, single-cloud setup | Free + low storage fees | Fully integrated, no extra setup, compliant by default |
| Open Source / Free | Wazuh, ELK Stack (Elasticsearch, Logstash, Kibana), Grafana + Loki | Mid teams, multi-cloud, limited budget | Free self-hosted | Full control, customizable, no subscription fees |
| Enterprise SIEM | Microsoft Sentinel, Splunk, Datadog, Sumo Logic | Enterprise, strict compliance, 24/7 threat hunting | IDR 2–20 million/month | AI-powered anomaly detection, global threat intelligence, managed support |
Recommendation: Start with your cloud provider’s native tools — they cover 90% of your needs for free. Add Wazuh or Grafana later if you need more features.
Step-by-Step Implementation Plan
Follow this roadmap to build a complete monitoring system in 4 weeks:
Table
| Week | Actions |
|---|---|
| Week 1 | Enable all audit logs, network logs, and authentication logs across all services; create a dedicated log storage bucket |
| Week 2 | Configure immutable storage, access restrictions, and encryption for logs; set up centralized log collection |
| Week 3 | Create critical alerts and notification channels; test that alerts are received correctly |
| Week 4 | Build basic dashboards for activity overview; document your process and run a test investigation |
| Ongoing | Review logs weekly, update alert rules monthly, test log integrity quarterly |
Common Mistakes & Fixes
Table
| Mistake | Risk | How to Fix |
|---|---|---|
| Storing logs in the same account as production | Attackers can delete evidence | Move logs to a separate locked account |
| Using default log retention (7–14 days) | Violates compliance rules | Set retention to minimum 6 months / 12 months for audit logs |
| Sending all alerts to one person | Missed alerts if that person is away | Use group channels and rotate on-call staff |
| No test of log access | Cannot find logs during an incident | Practice searching logs regularly |
| Logs in plain text | Exposes sensitive data | Enable server-side encryption for all logs |
Conclusion
Security monitoring and logging are the foundation of all cloud security — without them, you are flying blind. They are also the most affordable protection you can implement: most features are free, and the cost of log storage is tiny compared to the fines and losses from a breach.
Start today by enabling all logs and locking down your log storage. Then build your alerts step by step. Over time, this system will give you proof of compliance, fast incident response, and the confidence that you can see exactly what is happening in your cloud environment at all times.