AWS permissions reference

This page is reference-only. Use it while creating the IAM policy for vScope in Amazon Web Services (AWS), or while troubleshooting missing AWS data.

vScope only needs read (Describe/List/Get) actions — it never needs write or delete permissions on your AWS account.

What the AWS credential collects

The AWS credential in vScope collects:

• EC2 instances (Virtual Machines)
• EBS volumes (Disks)
• Security Groups
• Lambda functions
• RDS databases
• Load Balancers (Application/Network Load Balancers via ELBv2)
• S3 buckets

It does not collect IAM users or groups as inventory — unlike vScope’s LDAP, Azure RM, or G Suite credentials, the AWS credential has no user-directory target. However, Test Credential does run an IAM check as part of validating the connection (see Credential validation below), so iam:GetUser is still required even though no user data is collected.

Core read-only policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:DescribeAccountAttributes",
        "ec2:DescribeInstances",
        "ec2:DescribeVolumes",
        "ec2:DescribeSecurityGroups",
        "ec2:DescribeRegions",
        "ec2:DescribeTags",
        "lambda:ListFunctions",
        "lambda:GetFunction",
        "rds:DescribeDBInstances",
        "rds:DescribeDBClusters",
        "elasticloadbalancing:DescribeLoadBalancers",
        "elasticloadbalancing:DescribeTargetGroups",
        "elasticloadbalancing:DescribeTags",
        "s3:ListAllMyBuckets",
        "s3:GetBucketLocation",
        "s3:GetBucketTagging",
        "iam:GetUser"
      ],
      "Resource": "*"
    }
  ]
}

Note

Application and Network Load Balancers use the elasticloadbalancing: IAM action prefix regardless of API version — there is no separate elasticloadbalancingv2: namespace.

Confirmed against a live instance

The full policy above — including ec2:DescribeAccountAttributes and iam:GetUser for credential validation — was tested against a real vScope instance’s Test Credential check, which reported EC2, S3, IAM, Lambda, ELB, and RDS all OK. If a discovery is still missing data with this policy attached, check CloudTrail (Event history, filtered to the credential’s access key) for AccessDenied errors and add the missing action here.

Optional: CloudWatch utilization metrics

Enabling Use CloudWatch on the AWS credential (off by default) collects storage/utilization metrics for S3 buckets and databases, and may incur additional AWS costs. It requires these actions, copied from vScope’s own permission notice for that setting:

{
  "Effect": "Allow",
  "Action": [
    "cloudwatch:GetMetricData",
    "cloudwatch:ListMetrics",
    "cloudwatch:GetMetricStatistics"
  ],
  "Resource": "*"
}

Credential validation

Test Credential checks each service separately and reports a per-service OK/FAILED result: EC2, S3, IAM, Lambda, ELB, and RDS (plus CloudWatch, if enabled). Each check needs its own action, independent of whether that service’s data is actually collected:

Service check	Action required	Notes
EC2	ec2:DescribeAccountAttributes
IAM	iam:GetUser	Validation only — vScope doesn’t collect IAM user data.
CloudWatch	cloudwatch:ListMetrics	Only checked if Use CloudWatch is enabled.

All three are included in the core policy above (CloudWatch’s in the optional block below). Missing any one of them fails that service’s check specifically — the others can still pass.