Can Falco run on EKS Fargate, or do I need another runtime monitor?

Falco generally isn’t a good fit for EKS Fargate. Its usual kmod and eBPF drivers need host or kernel access, while Fargate doesn’t allow the privileged containers and DaemonSets normally used to provide that access. Since pdig is archived, I wouldn’t start a new deployment with it. If you need Falco, run the workloads on EC2-backed managed nodes and deploy Falco there. For Fargate, you may need to rely on audit logs, network controls, or a different monitoring product.

The key distinction is how the sensor collects events. Falco’s standard drivers depend on host or kernel visibility, which Fargate intentionally abstracts away. A sidecar-based Defender-style product can work because it runs inside the task, but it provides a different level of coverage. So serverless runtime monitoring hasn’t become impossible; Falco’s traditional collection model just doesn’t map cleanly to Fargate. I’d avoid pdig for new projects and compare a supported sidecar solution with AWS logging and detection services.

Some commercial tools can monitor Fargate because they inject a sidecar into each task and share the process namespace. That can capture process launches, network connections, and selected file activity without requiring host-level kernel access. It isn’t equivalent to Falco’s deeper syscall visibility, though, so the right choice depends on your threat model. For AWS-native monitoring, it’s also worth checking the current GuardDuty EKS runtime-monitoring documentation; Fargate support and deployment details have changed over time.