IDS and IPS
Intrusion detection systems (IDS)
Section titled “Intrusion detection systems (IDS)”An IDS observes and reports. It inspects traffic and host activity, compares what it sees against signatures and behavioural baselines, and raises an alert — but it does not stand in the path of the traffic and does not stop anything.
- Passive: a copy of the traffic, or host telemetry from an agent
- Detects authentication failures, reconnaissance, known attack signatures and anomalous behaviour
- Cannot itself become an outage, because a failure means lost visibility rather than lost traffic
Intrusion prevention systems (IPS)
Section titled “Intrusion prevention systems (IPS)”An IPS sits inline and acts. It applies the same detection logic but can drop a packet, reset a connection or add a source to a block list in real time.
- Inline: every packet passes through it, so it is both a control and a potential bottleneck and single point of failure
- Signature-based and behavioural detection with automated response
- A false positive blocks legitimate traffic, which is why an IPS is usually run in detection mode first and switched to prevention once the rules are tuned
On AWS, AWS Network Firewall provides managed IPS capability using the Suricata engine, with firewall endpoints in dedicated subnets and traffic steered to them by route tables. Third-party appliances from the AWS Marketplace are the other common route, usually deployed behind a Gateway Load Balancer.
Deployment in a VPC
Section titled “Deployment in a VPC”A conventional appliance deployment places the IDS/IPS in a public or inspection subnet, with route tables directing north-south traffic through it before it reaches the application subnets. The application tier sits in private subnets behind a load balancer, and the data tier in private subnets of its own. Alerts from the appliance publish to an Amazon SNS topic, which notifies the operators.
Host-based agents complement the network view. They see what the network cannot — file integrity, process execution, local privilege changes — and they still work when traffic is encrypted end to end. On AWS, GuardDuty Runtime Monitoring provides this for EC2 instances, EKS clusters and ECS on Fargate without a third-party agent.
Log collection
Section titled “Log collection”Findings are only useful if they reach somewhere durable and searchable.
- Amazon CloudWatch Logs for operational and application logs
- Amazon S3 for long-term, cheap retention, with Object Lock where tamper-evidence matters
- A third-party SIEM — Splunk, Elastic and others — where correlation across non-AWS sources is needed
- Amazon Security Lake to normalise AWS and third-party sources into a single OCSF-formatted lake
CloudWatch and CloudTrail
Section titled “CloudWatch and CloudTrail”These two are frequently confused, and the distinction is simple: CloudTrail records who did what, CloudWatch records how things are behaving.
| Amazon CloudWatch | AWS CloudTrail | |
|---|---|---|
| Records | Metrics, logs and events from AWS services and applications | API activity: the caller, the action, the source address and the time |
| Question it answers | Is the system healthy? | Who made this change? |
| Multi-account | Cross-account observability | Organisation trails covering every member account |
| Storage | CloudWatch Logs log groups, with a configurable retention period per group | Delivered to Amazon S3, and optionally to CloudWatch Logs |
| Metric retention | Data points are aggregated over time and retained for up to 15 months | Retention is whatever the S3 lifecycle policy says |
| Alarming | Native alarms on metrics and log metric filters | No native alarming; send events to CloudWatch Logs or EventBridge and alarm there |
Practice
Section titled “Practice”Log aggregation. Send logs from every account to a dedicated logging account, with tight access controls and no delete permission for the accounts that produce them. AWS Control Tower creates exactly this as the log archive account. Enable organisation-wide CloudTrail so a new account is covered from the moment it is created.
Alarming. Alarm on the events that indicate loss of visibility or loss of control — CloudTrail being disabled, a root user sign-in, a change to an authentication configuration, a mass deletion — rather than on volume. Route them through Amazon SNS to the channel someone actually reads, and test that the channel works.
Response. Decide in advance which findings are automated and which need a human. Isolating an instance and revoking a session are safe to automate; deleting resources is not.
Review. Re-tune signatures and thresholds on a schedule. An IDS whose alerts are all ignored is worse than none, because it consumes the attention that would otherwise notice the real event.