Detect Runtime Threats in Fargate Workloads with GuardDuty
Published on · Updated on
Corrected GuardDuty Fargate support and deployment details, added prerequisites and coverage checks, and clarified finding delivery and detection limits.
Amazon GuardDuty Runtime Monitoring can detect suspicious process, file, and network activity in supported Amazon ECS tasks on AWS Fargate. For Fargate, GuardDuty manages a security agent that is added as a sidecar when a task starts. You do not install a host agent because Fargate does not provide access to the underlying host.
This guide covers ECS on Fargate. GuardDuty does not support EKS clusters running on Fargate. The feature is a detection control: it creates findings for investigation, but it does not by itself block a process, isolate a task, or fix a compromised image.
- Runtime Monitoring supports Linux Fargate tasks on platform version
1.4.0or later, orLATEST. AWS's verified configurations include x86-64 (AMD64) and ARM64 (Graviton); Windows tasks are not supported. - Enable Runtime Monitoring and automated agent configuration for ECS. Existing tasks must be relaunched or their service redeployed before GuardDuty can add the sidecar.
- Check GuardDuty runtime coverage after rollout. A running application task can remain healthy even when its GuardDuty sidecar is missing or unhealthy.
Requirements for Runtime Threat Detection in Fargate
How Fargate's Model Affects Security
Fargate isolates each task in its own virtual environment and does not expose the host operating system to customers. Containers in the same task share the task's CPU, memory, ephemeral storage, and network namespace. This allows a security sidecar to observe activity in its task, but it also means the sidecar uses resources allocated to that task.
Fargate supports the Linux CAP_SYS_PTRACE capability for some observability and security tools, but it does not support privileged containers. A third-party tool must document that its specific agent works with ECS on Fargate and its required capabilities. See AWS's Fargate security considerations.
AWS-Native Solutions for Runtime Threat Detection
Amazon GuardDuty ECS Runtime Monitoring
GuardDuty Runtime Monitoring supports ECS tasks on Fargate, not ECS Managed Instances or EKS on Fargate. For this Fargate integration, GuardDuty manages the agent automatically; manual agent installation is not available. For each new task in a monitored cluster, GuardDuty attaches a sidecar that collects runtime events from the task's containers.
The agent observes operating-system activity such as process execution, file access, and network connections, then sends runtime events to the GuardDuty service for analysis. GuardDuty creates findings when it detects suspicious behavior. The raw runtime events are not exposed to customers as a log stream. Findings can include process and resource context, but GuardDuty omits full command-line arguments because they may contain sensitive data. See AWS's description of GuardDuty Runtime Monitoring and its runtime finding details.
For image deployment, the task execution role needs the ECR permissions that let ECS pull the GuardDuty sidecar image. The image layers are stored in Amazon S3, so tasks in restricted subnets also need a working path to ECR and S3. GuardDuty establishes the agent's connection to its service when automated agent configuration is enabled; this is separate from the network access needed to download the image. Review the current Fargate prerequisites and agent connectivity options for IAM, network, platform, and task CPU and memory requirements.
GuardDuty adds its sidecar when a task starts because running Fargate tasks cannot be modified in place. A task already running when Runtime Monitoring is enabled is not covered until it is stopped and started again. For an ECS service, make a new service deployment after enabling the feature.
Runtime Findings and Related Signals
Runtime findings answer a different question from image scanning, API auditing, or service metrics. Use the signals together when an incident requires both workload behavior and AWS account context.
| Signal | Useful for | What it does not replace |
|---|---|---|
| GuardDuty Runtime Monitoring | Findings about suspicious operating-system activity in monitored tasks. | A complete application log, raw runtime-event archive, or automatic containment action. |
| CloudTrail | Auditing AWS API activity, such as changes to IAM or ECS configuration. | Process and file activity inside a running container. |
| VPC Flow Logs | Network-flow metadata for investigating traffic paths and patterns. | Process-level attribution or GuardDuty runtime findings. |
| CloudWatch ECS metrics and application logs | Service health, resource use, and application output that you configure to collect. | The GuardDuty runtime event feed, which is analyzed by GuardDuty. |
GuardDuty automatically publishes findings to Amazon EventBridge. Create a rule and target to route selected findings to notifications, a response workflow, or a SIEM. If you also enable AWS Security Hub CSPM in the same account and Region, GuardDuty findings flow to its findings view. Routing an alert is not the same as containing a task: make response actions explicit, narrowly scoped, and tested.
Third-Party Tools for Runtime Threat Detection
A third-party runtime product can be useful when it supplies a required policy set, workflow, or cross-cloud view. Fargate does not expose a host for a traditional host agent, so confirm that the vendor supports its documented ECS-on-Fargate deployment model before selecting a product. A sidecar design may require Linux capabilities such as CAP_SYS_PTRACE, additional image pulls, task CPU or memory, and outbound connectivity.
Compare the Deployment Requirements
Before a production rollout, check the vendor's current documentation for:
- Supported ECS launch type, Fargate platform version, operating system, and CPU architecture.
- Whether its agent runs as a sidecar, which Linux capabilities and IAM permissions it needs, and whether privileged mode is required.
- How it behaves if the agent cannot start or loses connectivity, and whether a failure can prevent the application task from starting.
- How agent resource use affects the task's CPU, memory, and cost, and where telemetry is stored or processed.
A vendor's general statement that its product supports containers does not establish that it supports Fargate. Test the documented deployment in a representative non-production service and verify coverage, application behavior, and alert delivery before relying on it.
Best Practices for Runtime Threat Detection Implementation
Enable GuardDuty and Deploy the Sidecar
- Check the platform. Confirm the task uses Linux Fargate platform version
1.4.0or later, orLATEST, and check the OS distribution, kernel, and CPU architecture against AWS's verified configurations. Windows Fargate tasks are unsupported. - Choose the clusters to monitor. Enable GuardDuty Runtime Monitoring and automated agent configuration for ECS in each Region where you run the workload. By default, automated configuration covers ECS clusters in the account; use the documented
GuardDutyManagedtag to exclude a cluster or opt in specific clusters when account-level automation is off. Set scope before rollout and control who can change that tag. - Check image-pull access. Confirm the task execution role can pull the GuardDuty image from ECR. For private subnets, configure the documented ECR endpoints and S3 access required for image layers, including outbound security group access where applicable.
- Check policy constraints. In a multi-account organization, confirm applicable SCPs do not deny
guardduty:SendSecurityTelemetry. Check that the task execution role's attached policy and permissions boundary do not block this action, as required by AWS. This is a check of effective policy constraints, not a reason to add a broad permission grant. - Relaunch tasks. Restart standalone tasks or deploy the ECS service again so new tasks start with the GuardDuty sidecar. Existing running tasks do not receive it in place.
- Verify runtime coverage. In GuardDuty, review Runtime Monitoring coverage for the ECS cluster and investigate unhealthy resources. Coverage is assessed at the Fargate task level. A task can continue running when the sidecar cannot start, so ECS service health alone does not prove that threat monitoring is active.
Use AWS's guides for enabling Runtime Monitoring, deploying the Fargate agent, and checking ECS runtime coverage for current console steps and troubleshooting.
Route and Investigate Findings
GuardDuty findings arrive in the GuardDuty console and are automatically published to EventBridge. Create an EventBridge rule with a target for the finding types and severities your team must act on. Test the routing path with a sample finding; that confirms the notification or response integration, but does not test the runtime sensor's detection coverage.
When Security Hub CSPM is enabled alongside GuardDuty in the same account and Region, the integration sends GuardDuty findings to Security Hub CSPM. Keep ownership of investigation and response clear: a finding can signal a compromised task, while containment, credential rotation, and workload replacement require your response process.
GuardDuty and CloudWatch serve different purposes here. CloudWatch does not receive GuardDuty's raw runtime events. Use GuardDuty findings for threat investigation and configure CloudWatch for task metrics or application logs you need to operate the service. The ECS on Fargate CloudWatch metrics guide explains service and task-level resource measurements that can help you assess workload behavior during rollout.
Check Coverage, Resource Use, and Cost
Monitor GuardDuty runtime coverage continuously, especially after changing task definitions, cluster tags, task roles, or network rules. A healthy coverage status indicates that GuardDuty can receive runtime events for the covered resource; an unhealthy status means it cannot monitor that resource or generate its Runtime Monitoring findings.
Containers in a Fargate task share the task's allocated resources. Review the CPU and memory combinations supported for the GuardDuty sidecar, then observe ECS service and task metrics after rollout. If you need task-level detail for resource outliers, use the documented CloudWatch Container Insights options rather than assuming a service average describes every task.
Estimate both GuardDuty Runtime Monitoring usage and any Fargate resource changes with current regional pricing. GuardDuty offers a 30-day trial for Runtime Monitoring per AWS account; use observed usage and the AWS Pricing Calculator to estimate ongoing cost rather than relying on the trial.
Conclusion
For supported Linux ECS tasks on Fargate, GuardDuty Runtime Monitoring provides managed runtime detection through a sidecar that is attached when tasks start. Configure it with the right task execution role and image-pull network access, relaunch tasks, and verify GuardDuty coverage rather than inferring it from service health. Route findings through EventBridge or Security Hub CSPM, and treat investigation and containment as separate response steps.