Read-only design is not just a security posture. It is a go-to-market advantage for finance-led adoption.
The access model shapes the sales cycle
Cloud cost tools often struggle when they ask for broad permissions too early. Finance may sponsor the initiative, but IT and security own the access decision. A read-only model lowers the initial barrier.
The message is simple: CostDefender observes cost, usage, inventory, tags, and metrics. It does not terminate resources, modify infrastructure, or store customer secret keys.
External ID is table stakes
A customer-created cross-account role should require a tenant-specific external ID. This protects the customer from confused-deputy risk and gives security teams a clear control to review.
Each tenant should have a unique external ID, scoped role ARN, connection status, and audit trail of role assumption activity.
Read-only still needs discipline
Read-only does not mean casual. The platform should minimize permissions, avoid logging sensitive data, encrypt tenant data, and provide clear documentation of what is collected and why.
Enterprise trust comes from precision. The permission model should be easy to explain and easy to inspect.
The customer keeps operational control
CostDefender should recommend, quantify, assign, and verify. The customer should implement. That boundary protects production environments and makes adoption easier for finance teams that need insight before they ask engineering to change systems.
The result is a cleaner enterprise motion: deep visibility first, customer-controlled action second.
CostDefender connects to your AWS environment with a customer-created read-only role — no write permissions, no stored credentials, no access to change anything. See the security model →