Skip to main content

​
Part 1: AWS Data Ingestion

Set up an AWS IAM user so ConfigView can pull your AWS infrastructure data into the dashboard. For security, ConfigView requires strictly read-only permissions to aggregate your configurations. We recommend creating a custom policy rather than using the broad AWS-managed ReadOnlyAccess policy to adhere to the principle of least privilege.

​
Step 1: Create a Custom IAM Policy

  1. Log in to the AWS Management Console as an administrator.
  2. Navigate to the IAM (Identity and Access Management) console.
  3. In the left navigation pane, choose Policies, then click Create policy.
  4. Switch to the JSON tab and paste the following policy. This grants exactly what ConfigView needs to sync your AWS resources and dynamically discover your active regions:
Two actions in this policy require additional one-time setup in the AWS console (no IAM change):
  • Cost Explorer must be enabled (Billing → Cost Explorer → Enable) for the ce:* actions to return data.
  • Hourly and Resource Level Data must be enabled (Billing → Cost Explorer → Settings) for ce:GetCostAndUsageWithResources to return non-empty results. This is a paid Cost Explorer feature and takes ~24 hours to populate after enabling.
  • Compute Optimizer must be opted in at the account level (free) for compute-optimizer:GetEC2InstanceRecommendations to return recommendations.

​
Per-script permission reference

If you prefer to grant only what individual scripts need, each endpoint requires the following actions:
  1. Click Next to review.
  2. Name the policy ConfigView-ReadOnly-Integration and add a description (e.g., “Allows ConfigView to read AWS resource metadata”).
  3. Click Create policy.

​
Step 2: Create an IAM User and Attach the Policy

  1. In the IAM console, go to Users and click Create user.
  2. Enter a user name (e.g., configview-svc). Do not check the box for AWS Management Console access. Click Next.
  3. Choose Attach policies directly.
  4. Search for the ConfigView-ReadOnly-Integration policy you just created, select it, and click Next.
  5. Click Create user.

​
Step 3: Generate Access Keys

  1. Click on the newly created configview-svc user.
  2. Go to the Security credentials tab.
  3. Scroll down to the Access keys section and click Create access key.
  4. Select Third-party service (or Other).
  5. Add an optional description tag and click Create access key.
  6. Important: Copy the Access Key ID and Secret Access Key immediately. You will not be able to view the Secret Access Key again.

​
Step 4: Add the Credentials to ConfigView

  1. Go to your ConfigView admin dashboard: https://{companyname}.configview.com/admin/secret/
  2. Click Add Secret and create the following entries based on your newly generated keys:
    • AWS_ACCESS_KEY_ID: Your Access Key ID
    • AWS_SECRET_ACCESS_KEY: Your Secret Access Key
    • AWS_DEFAULT_REGION: Your primary AWS region (e.g., us-east-1). This is used as the starting point for global resource discovery.
  3. Click Save.

​
Step 5: Enable the AWS Integration

  1. Go to: https://{companyname}.configview.com/admin/cron/
  2. Locate AWS in the list of available integrations (folders).
  3. Select the resource scripts you want to run (e.g., VPCs, CloudTrail, etc.).
  4. Click Save.
When you save, ConfigView creates the database tables, schedules every selected script at the default run time (top of the page — change once, applies to every new script), and triggers a one-shot first run so data starts appearing within minutes. You can still override any individual script’s schedule below.
Default run time is stored in UTC. The picker at the top of /admin/cron/ shows it in your browser’s local time. Per-script overrides are independent of the default.

​
Step 6: Verify Connection

  1. Go to: https://{companyname}.configview.com/admin/status/
  2. Run the AWS health check or trigger a manual sync.
  3. Ensure the scripts report success.
If a sync fails, double-check that your Access Keys were copied correctly and that the custom IAM policy was properly attached to the user.

​
Integration Lifecycle (Checking and Unchecking)

ConfigView handles your database schema, scheduling, and secrets automatically based on your integration selections:
  • When you check an integration: ConfigView runs the background createdb scripts to construct the required MySQL tables, registers every script at the default run time (so you don’t have to set 50 schedules by hand), fires one immediate first run so data populates without waiting, and safely stores your secrets in Google Secret Manager.
  • When you uncheck an integration: ConfigView triggers the associated dropdb scripts, which safely drops the tables and deletes the synced data to free up database resources. It also automatically removes the associated secrets from Secret Manager.
  • When new scripts ship in a future ConfigView update: They automatically pick up your configured default run time. No re-click required.

​
Available Data Tables

Once the scripts complete successfully, the corresponding AWS resource tables will be populated in your database. Example tables include:
  • aws_ec2: EC2 instance inventory across all active regions.
  • aws_vpc: Virtual network configurations across all active regions.
  • aws_cloudtrail: Audit trail configurations across all active regions.
  • aws_cost_daily: Daily unblended/amortized cost grouped by service and usage type (last 30 days).
  • aws_ebs_unattached: EBS volumes in available state (unattached waste), with estimated monthly cost.
  • aws_eip_unused: Elastic IPs with no association (each unattached EIP incurs charges).
  • aws_snapshots_aged: EBS snapshots older than 90 days, flagged when their source volume no longer exists.
  • aws_s3_storage_stats: Per-bucket size, object count, storage-class breakdown, lifecycle presence, versioning, encryption.
  • aws_compute_recommendations: AWS Compute Optimizer rightsizing recommendations with estimated monthly savings.
  • aws_idle_rds: RDS instances with 7-day CPU and connection metrics, flagged idle when both fall below thresholds.
  • aws_cost_by_resource: Daily cost grouped by resource ID for the last 14 days (requires Hourly and Resource Level Data in Cost Explorer).
  • aws_elb: Application, Network, Gateway, and Classic load balancers across all active regions (DNS name, VPC, scheme, AZs, security groups, tags).
  • aws_elb_cost: Daily Cost Explorer slice for Elastic Load Balancing grouped by usage type and region (last 30 days).
  • aws_ecs: ECS clusters across all active regions with nested service and task descriptions in JSON.
  • aws_ecs_cost: Daily Cost Explorer slice for Amazon Elastic Container Service grouped by usage type and region (last 30 days).
  • aws_lambda: Lambda functions across all active regions (runtime, handler, memory, timeout, architectures, VPC config, env, tags).
  • aws_lambda_cost: Daily Cost Explorer slice for AWS Lambda grouped by usage type and region (last 30 days).
  • aws_guardduty: Active GuardDuty findings across all detectors and regions (severity, type, affected resource, archived flag).
  • aws_guardduty_cost: Daily Cost Explorer slice for Amazon GuardDuty grouped by usage type and region (last 30 days).
  • aws_route53: Public and private hosted zones with full record-set list and tags (Route 53 is a global service — single fetch, no region iteration).
  • aws_route53_cost: Daily Cost Explorer slice for Amazon Route 53 grouped by usage type and region (last 30 days).
  • aws_sqs: SQS queues across all active regions with message counts, visibility timeout, and queue attributes.
  • aws_redshift: Redshift clusters with node type/count, status, encryption, VPC, and master username.
  • aws_cloudfront: CloudFront distributions (global) with origins, aliases, price class, HTTP version, IPv6 status.
  • aws_dynamodb: DynamoDB tables with item count, size in bytes, billing mode, and provisioned capacity.
  • aws_sns: SNS topics with subscription counts and KMS encryption key.
  • aws_cloudwatch: CloudWatch metric alarms with state, threshold, comparison operator, evaluation periods, and configured actions.
  • aws_detective: Detective behavior graphs with member-account counts.
  • aws_glue: Glue databases, jobs, and crawlers in one table keyed by resource_type.
  • aws_transfer: Transfer Family servers (SFTP/FTPS/FTP) with endpoint type, identity provider, and user count.
  • aws_ecr: ECR repositories with image count, total size in bytes, tag mutability, and scan-on-push setting.
  • aws_eum: End User Messaging phone numbers (origination IDs) with country code, type, and monthly leasing price.
  • aws_cognito: Cognito user pools and identity pools in one table keyed by pool_type.
  • aws_ses: SES verified identities with verification status, DKIM state, configuration set, and account-level 24-hour send quotas.
  • aws_kms: KMS keys with alias, state, usage, key manager (AWS/CUSTOMER), origin, and rotation status. Tags included.
  • aws_config: AWS Config recorders + delivery channels per region with rule counts.
  • aws_securityhub: Active Security Hub findings with severity label/normalized score, compliance status, workflow status, and affected resource.
  • aws_macie: Macie sensitive-data findings with severity, category, S3 resource, and count.
  • aws_apigateway: REST, HTTP, and WebSocket APIs in one table keyed by api_type.
  • aws_kinesis: Kinesis Data Streams with shard count, retention period, stream mode (ON_DEMAND/PROVISIONED), encryption, and creation timestamp.
  • aws_waf: WAFv2 Web ACLs (REGIONAL + CLOUDFRONT) with rule count, capacity, default action, associated resources, and full rule definitions.
  • aws_secretsmanager: Secret metadata only (NOT secret values) — name, KMS key, rotation schedule, last-rotated/changed/accessed dates.
  • aws_iam_users: IAM users with MFA status, console-password facts, access-key counts, group membership, and a computed is_admin flag. Includes the root account as <root_account>.
  • aws_iam_roles: IAM roles with the trust policy summarised into trusted_principals/trust_type, plus is_sso_role, is_service_linked, last-used date, and is_admin.
  • aws_iam_groups: IAM groups with their member list and is_admin.
  • aws_iam_policy_attachments: One row per policy attachment, flattened across users, groups, and roles — including the rows a user inherits through a group. grants_admin marks the attachments that confer blanket admin.
  • aws_iam_access_keys: Access keys with status, age, and last-used service/region. user_is_admin flags keys belonging to admin users.
  • aws_sso_assignments: AWS IAM Identity Center (SSO) account assignments — permission set, target account, and the resolved user or group — with grants_admin.
  • aws_sqs_cost through aws_secretsmanager_cost: Daily Cost Explorer slices for each service above, same shared schema (see note below).
Each aws_<service>_cost table shares a consistent schema: usage_date, service_name, usage_type, region, operation, amortized_cost_usd, unblended_cost_usd, usage_quantity, usage_unit, raw, run_at. This lets you UNION across services for cross-cutting cost analysis.

​
Who counts as an “admin”

AWS has no is_admin field, so ConfigView computes one. A principal is marked is_admin when it holds a policy that allows every action on every resource with no condition — the shape of the AWS managed AdministratorAccess policy, or any customer-managed or inline policy that grants the same thing under a different name. Three deliberate choices are worth knowing about, because they decide who appears on the list:
  • Conditioned grants do not count. A grant of * on * that only applies with MFA present, or from one IP range, is a real control. Counting it as plain admin would pad the list with people who are not unrestricted admins, and a list nobody trusts gets ignored.
  • Group inheritance counts. Most accounts grant admin to a group rather than to a user. aws_iam_users.admin_via names the group and the policy behind it, and aws_iam_policy_attachments carries a row per inherited attachment so you can see the whole path.
  • “Could become admin” is tracked separately. Holding IAMFullAccess or an equivalent iam:* grant means a principal can attach AdministratorAccess to itself. Those are flagged is_privileged, not is_admin, and surface through the AWS principals that can make themselves admin saved query.
If your organisation uses AWS IAM Identity Center (SSO), aws_iam_users will often be nearly empty — real admin access lives in aws_sso_assignments instead, and the IAM users that remain are usually service accounts. The AWS admins (every path into the account) saved query unions both, plus admin-granting IAM roles, so it answers the question regardless of which model you use.Two parts of this degrade gracefully rather than failing the sync:
  • Identity Center is enabled in exactly one region per organisation. The collector probes every region to find it, and exits cleanly reporting “no Identity Center instance” if you do not use SSO at all.
  • organizations:ListAccounts only answers for the management account. Without it, assignments are still collected and correct — they are just labelled by account number instead of account name.
Start from these saved queries in Admin > Queries: AWS admins (every path into the account), AWS — why each principal has admin, AWS admins without MFA, and AWS root account — MFA and usage. Note: ConfigView automatically discovers and polls all active AWS regions during sync operations. All tables include a run_at column to power historical tracking and drift detection.