Limiting Agent Access in an AWS Account

AWS DevOps Agent uses IAM roles to discover and describe AWS resources during incident investigations and preventative evaluations. You can control the level of access the agent has by configuring IAM policies attached to these roles. The application topology doesn't show everything the agent has access to—IAM policies are the only way to truly limit what AWS service APIs and resources the agent can access.

Understanding IAM roles for AWS DevOps Agent

AWS DevOps Agent uses IAM roles to access resources in two types of accounts:

• Primary account role – Grants the agent access to resources in the AWS account where you create the Agent Space.

• Secondary account roles – Grants the agent access to resources in additional AWS accounts that you connect to the Agent Space.

For either type of account, you can restrict which AWS services the agent can access, limit access to specific resources within those services, and control which regions the agent can operate in.

Choosing your resource boundaries

When limiting resource access, you need to include enough permissions for the agent to successfully investigate application incidents. This includes:

• All resources for in-scope applications that the agent should monitor and investigate

• All supporting infrastructure that those applications depend on

Supporting infrastructure may include:

• Networking components (VPCs, subnets, load balancers, API gateways)

• Data stores (databases, caches, object storage)

• Compute resources (EC2 instances, Lambda functions, containers)

• Monitoring and logging services (CloudWatch, CloudTrail)

• Identity and access management resources needed to understand permissions

If you restrict access too narrowly, the agent may not be able to identify root causes that originate in supporting infrastructure outside your defined boundaries.

Understanding topology and access limitations

The application topology may display resources that the agent cannot fully access during investigations. This can occur when the Agent Space is configured to discover tagged resources from AWS Resource Explorer, and Resource Explorer has permission to discover resources that the role assigned to the agent does not have permission to access. In these cases, the resources will appear in the topology visualization, but the agent will not be able to retrieve detailed information about them during investigations. To ensure the agent can investigate all resources shown in the topology, verify that the IAM role assigned to the Agent Space has appropriate permissions for all discovered resources.

Restricting service access

You can limit which AWS services the agent can access by modifying the IAM policies attached to the agent's roles. When creating custom policies, follow these best practices:

• Grant only read-only permissions – The agent needs to read resource configurations, metrics, and logs during investigations. Avoid granting permissions that allow the agent to modify or delete resources.

• Limit to necessary services – Include only the AWS services that contain resources relevant to your applications. For example, if your application doesn't use Amazon RDS, don't include RDS permissions in the policy.

• Use specific actions instead of wildcards – Instead of granting service:* permissions, specify individual actions like cloudwatch:GetMetricData or ec2:DescribeInstances.

Example policy restricting to specific services:

json

{
  "Version": "2012-10-17",		 	 	 		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "cloudwatch:GetMetricData",
        "cloudwatch:GetMetricStatistics",
        "cloudwatch:DescribeAlarms",
        "logs:GetLogEvents",
        "logs:FilterLogEvents",
        "ec2:DescribeInstances",
        "lambda:GetFunction",
        "lambda:GetFunctionConfiguration"
      ],
      "Resource": "*"
    }
  ]
}

Restricting resource access

To limit the agent to specific resources within a service, use resource-level permissions in your IAM policies. This allows you to grant access only to resources that match specific patterns. Using resource ARN patterns:

{
  "Version": "2012-10-17",		 	 	 		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "lambda:GetFunction",
        "lambda:GetFunctionConfiguration"
      ],
      "Resource": "arn:aws:lambda:*:*:function:production-*"
    }
  ]
}

This example limits the agent to accessing only Lambda functions with names that begin with "production-". Using tag-based restrictions:

{
  "Version": "2012-10-17",		 	 	 		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:DescribeInstances",
        "ec2:DescribeInstanceStatus"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:ResourceTag/Environment": "production"
        }
      }
    }
  ]
}

This example limits the agent to accessing only EC2 instances tagged with Environment=production.

Restricting regional access

To limit which AWS regions the agent can access, use the aws:RequestedRegion condition key in your IAM policies:

{
  "Version": "2012-10-17",		 	 	 		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:Describe*",
        "lambda:Get*",
        "cloudwatch:Get*"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:RequestedRegion": [
            "us-east-1",
            "us-west-2"
          ]
        }
      }
    }
  ]
}

This example limits the agent to accessing resources only in the us-east-1 and us-west-2 regions.

Creating custom IAM policies

When you create an Agent Space or add secondary accounts, you have the option to create a custom IAM role using a policy template. This allows you to implement the principle of least privilege. When creating an Agent Space From the DevOps Agent console in the AWS Management Console...

• Choose Create a new DevOps Agent role using a policy document and follow the instructions

When editing an Agent Space From the DevOps Agent console in the AWS Management Console...

• Select the Capabilities tab

• Select the secondary account you want to edit from the Cloud section and click Edit

• Chose Create a new DevOps Agent policy using a template and follow the instructions

Custom policy best practices

• Grant only read-only permissions – Avoid permissions that allow resource modification or deletion

• Use resource-level permissions when possible – Restrict access to specific resources using ARN patterns or tags

• Regularly review and audit permissions – Periodically review the agent's IAM policies to ensure they still align with your security requirements