CoverOps on AWS
The cloud most of our customers run on, and the one CoverOps covers most deeply: read-only by default, keyless, and the only cloud where an approved fix can be applied for you, with a rollback.
The access you give
An IAM role in your account, trusted with an External ID.
- Read-only by default: Describe, List and Get calls on inventory, utilisation and cost. No action that changes anything, and none that reads bucket or database contents
- The role trusts only CoverOps's AWS principal, and only with the External ID unique to your organisation
- Optional write access, which you add per resource: stop, start and resize instances, snapshot and delete volumes, stop and start RDS, only on resources you tag coverops:managed=true
- One-click CloudFormation, a Terraform module or a CLI script, all generated by the console; AWS Organizations: connect the management account once and add member accounts from a list
Keyless: CoverOps assumes your role for each scan and gets short-lived credentials that expire on their own. No access key is stored.
What it reads
- EC2 instances, EBS volumes and snapshots, Elastic IPs, NAT gateways, reserved instances and images
- RDS instances and clusters, S3 buckets (names, location, tags, lifecycle rules), load balancers and target groups, Lambda functions, EKS clusters, Auto Scaling groups
- CloudWatch utilisation, and Cost Explorer for the billed cost, forecasts, Savings Plans and reservation coverage
Never read: your application data, database contents or the files in your storage.
Where the rupee figures come from
Your billed cost from Cost Explorer where the role can read it; otherwise public on-demand prices, always labelled as an estimate.
What it finds
- Idle and oversized instances and databases, with the size one step down and what it saves
- Unattached volumes, old snapshots, unused Elastic IPs and idle NAT gateways
- Dev and test servers running all night, gp2 disks that should be gp3, large S3 buckets with no lifecycle rule, cross-zone data transfer
- What AWS itself recommends you commit to, set against what you already hold
What it changes
With the write access you granted, a fix is raised as a proposal. A named person in your team approves it; CoverOps checks the resource again, keeps a snapshot, applies the change, and you can roll it back. Without write access every finding comes with the exact CLI or Terraform change for your team to run.
How to connect
- Sign up and open Cloud accounts → Connect AWS
- Launch the read-only role with one click (your External ID is filled in), or use the Terraform or CLI version
- Paste the role ARN, press Verify access to see each permission checked, then Connect: the first scan starts
How to end it
Delete the CoverOpsAccess role (or the CloudFormation stack). The next scan fails and CoverOps can do nothing more in your account. Your workloads keep running: none of them ever ran on CoverOps. More in revoking access and the security overview.
Other clouds: Azure · Google Cloud · DigitalOcean · Oracle Cloud