Refine Documentation

The fastest path is the Refine connector stack — one CloudFormation stack, launched from inside Refine, that creates the FOCUS 1.2 billing export, its S3 bucket, and a read-only IAM role in your account. If you already export FOCUS data, skip to the existing-export path below.

Quick setup (recommended)

1. In Refine, open Settings → AWS Accounts → Add Account (the welcome screen’s Connect your AWS account button lands here too) and choose Quick setup.
2. Click Launch the connector stack. The AWS console opens with the template pre-loaded — it runs in us-east-1 (required for Cost & Usage Data Exports). Tick the IAM acknowledgement and create the stack (~2 minutes).
3. Open the stack’s Outputs tab and paste into the form:BucketName → Source Bucket, RoleArn → Role ARN. That is everything — the External ID was already carried into the stack by the launch link. No access keys are created and none leave your account: the stack creates a read-only IAM role that only Refine’s AWS account can assume, and only when it presents your External ID.
4. Save. AWS delivers the first export within about a day; Refine picks it up automatically and notifies you.

Already exporting FOCUS?

Choose I have a FOCUS export in the same form and point Refine at that bucket, with a read-only IAM role Refine can assume — it needs read on that bucket plus billing and security-audit read (that is what the cost and security views run on), savingsplans:DescribeSavingsPlans for when each Savings Plan ends, and cloudwatch:GetMetricData to confirm that a database or cache the bill looks idle for really is. The easiest way to make that role is the same connector stack with ExistingBucketName set to your bucket: it then creates only the role and touches nothing you already have. Re-connecting an account that used the older access-key setup? Use this path. Running the full stack again fails with “Cannot create duplicate export name”, because the export it made the first time is still there. Building the role by hand instead? Its name must start with Refine, and its trust policy must name arn:aws:iam::941275879372:root under the External ID shown on the form.

What access does Refine get?

A read-only IAM role: account-wide billing, security-audit, Savings Plans and CloudWatch-metrics read, plus read access to the export bucket only — no write or admin permissions. Refine never asks for, receives or stores an AWS access key. It assumes the role for an hour at a time, and only by presenting the External ID your stack was created with, so the role cannot be used by anyone else who learns its ARN. To revoke access at any time, delete the role in your AWS console — Refine immediately loses the ability to read, with nothing left over to expire.

The bill analyzer accepts CSV, XLSX, and PDF exports for a one-shot savings report — no signup required.

1. Visit the free bill analyzer.
2. In the AWS billing console, go to Billing → Bills and download the CSV (or the invoice as PDF).
3. Drag-and-drop the file onto the upload widget.
4. Analysis completes in under 60 seconds. The report includes service breakdown, top-5 savings recommendations, and anomaly flags.

The uploaded bill is deleted 3 days after upload. See data retention.

The dashboard surfaces four widgets that do most of the work:

• Optimization Score — single 0–100 number for cost efficiency. Methodology disclosed.
• Security Score — single 0–100 number for posture. Pairs with Optimization Score on the dashboard.
• AI Narrative Summary — plain-English summary of where money is going.
• Top Cost Drivers — services ranked by spend with month-over-month change.

The customer-hierarchy switcher in the header re-scopes everything to a specific customer or account.

Invite team members under Settings → Users & Roles. Roles available:

• Admin — full access including billing and IAM role management
• Member — read/write on dashboards, recommendations, and reports
• Viewer — read-only across all surfaces
• Report-only — receives scheduled reports; no dashboard access (useful for customer-side contacts on MSP hierarchies)

SSO (SAML / OIDC) is on the Enterprise roadmap. Today, authentication is Amazon Cognito with email + password and optional MFA.

The Cost Analysis surface breaks spend down by service, region, account, and tag. Drill from total spend to specific line items without leaving the page. Full details on the Cost Optimization page.

Service-level and resource-level recommendations come from CUR (AWS Cost and Usage Report) plus Refine's analysis engine. Recommendations are ranked by projected dollar savings — start from the top.

Each recommendation includes:

• The change in plain English
• Projected monthly savings (low / expected / high)
• The exact AWS API call to make

Marking a recommendation Resolved does not by itself count as a saving. Refine snapshots what the resource cost over the 30 days before the fix, then measures the same resource again 14 and 30 days after it, in your own billing data (FOCUS/CUR).

• Realized — the cost fell by at least 80% of the estimate
• Partially realized — some of it landed; the shortfall is shown in dollars and percent
• Not realized — the cost did not materially fall
• Pending verification — not enough time has passed to measure yet, so there is nothing honest to report

The 14-day result is marked provisional because AWS revises recent billing data; the 30-day measurement is the one that stands. A deleted resource loses its cost line entirely, which counts as the full baseline coming off the bill. Realized savings are capped at the amount projected: if a cost fell further than estimated, the excess is reported but not claimed, because it cannot be attributed to the recommendation. Export the monthly ROI report from the Recommendations page to see every figure per resource.

Forecasting projects month-end spend using trend-aware analysis (a 28-day usage level and an eight-week weekday profile, calibrated for seasonal patterns and step changes). Active Reserved Instances and Savings Plans are deducted so projections reflect net cost. See Forecasting & Budgets.

AI budget scopes

A budget under /budgets is scoped to an account, an organization, a tag, a service, a region, a project, a team or a custom filter — and, on Growth and above, to AI spend specifically. The three AI scopes use the same pace, threshold and forecast alerts as every other budget; only the filter differs:

• All AI services — every service the AI Spend page counts (see AI Spend), so an AI pilot has a ceiling before it has an invoice.
• One Bedrock model — a model key exactly as the model view on AI Spend groups it: a Marketplace-billed model such as Claude Haiku 4.5 (Amazon Bedrock Edition), or a first-party model such as Titan embeddings identified by its model id.
• One inference profile — a single application inference profile ARN, which is how one team’s Bedrock traffic gets its own line (see Allocating Bedrock spend to teams).

The model and profile pickers list only what your accounts have actually used, so a budget cannot be set on a key that will never match. For a model or profile budget the detail page also shows the monthly input and output tokens behind the dollars, so “why did we hit 80%” is answerable on the page. Budgets are in dollars; token-denominated budgets are not offered.

Tag Governance surfaces untagged resources, allocation gap trend, drift detection, and required-tag tracking. Refine does not apply tags itself — that is a write operation outside the baseline read-only role — but the Remediation tab generates a ready-to-run AWS CLI script or Terraform patch for the resources you select, which you run with your own credentials. See Tag Governance.

The AI Spend page (/ai-spend, in the Cost group of the sidebar) shows how much of your AWS bill goes to AI services, where it goes, how it is trending and what this month will land at. It reads the same monthly billing export every other cost page reads — nothing extra to connect and no new permission.

What is counted

A line is AI spend when its service is on Refine’s AI service list: Amazon Bedrock and the Marketplace-billed Bedrock models, Kiro, Amazon Q Developer, SageMaker, Rekognition, Comprehend, Textract, Translate and the rest of the AWS AI family. The list is maintained in one place and applied to every AI view, so a service cannot count on one screen and not another. The page states its own boundary above the total:

“Spend billed to AWS AI services. GPU and accelerator compute is billed to EC2 and counted separately as AI workload compute; storage and networking supporting AI workloads are billed to S3 and networking and are counted in neither figure.”

Views

One matrix, four ways to slice it: by service, by model (Bedrock rows grouped on the model, whether it bills as its own Marketplace service or as a model id under Amazon Bedrock), by connected AWS account and by region. Switching the view transposes the same money, so the grand total never changes with the toggle. The 12-month trend stacks the top entries of the active view; smaller lines roll into Other.

This month versus complete months

The KPI strip shows month-to-date spend and a projected month-end figure. The current month is held apart from complete months everywhere: the trend, the month-over-month change and the 12-month total are built from complete months only, and a line with no prior month reads new rather than an infinite percentage.

Gross basis

Figures are gross, before credits. An account whose AI usage is covered by credits still shows what the usage cost, not $0.00 — the point is to see the consumption. Tax lines billed against an AI service are included in the dollar total.

What each plan sees

The page, its KPI strip and the four views are on every plan, including Free. The deeper sections — tokens, the inference-profile table, the allocation finding, seat names, AI budget scopes and AI alert settings — are part of AI monitoring on Growth and above. On Free those sections stay in place and say what they would show.

An account with no AI usage sees that stated plainly, with the number of connected accounts examined — not an empty table. A load that fails says so and offers a retry; it never renders as $0.

The Tokens section of AI Spend turns Bedrock billing lines into tokens: input and output tokens per model, the output/input ratio, the effective cost per million tokens, how the model mix is shifting month to month, and whether prompt caching and batch inference are in use.

Where the numbers come from

• Units are normalised. AWS bills some models per 1000 Tokens and others per 1M tokens; every quantity is converted to plain tokens before anything is added up or compared.
• Direction, tier, cache and batch come from the billing meter. Each line carries a SKU meter such as …InputTokenCount-Units or …OutputTokenCount_Global-Units. Refine reads it for the direction (input / output), the routing tier (regional, cross-region, global), cache reads and writes, and batch inference. Where the meter is blank, the usage type is read instead for region and tier.
• Cost per million tokens is derived on screen from summed spend divided by summed tokens for each model and direction. It is never shown when the token count is zero — an em-dash means “no tokens to divide by”, not a free model.
• Tax rows are excluded from token maths. A tax line carries no consumed unit, so it counts in dollars and never in tokens.
• An unknown meter still counts dollars. If AWS introduces a meter spelling Refine does not recognise, that model’s spend still appears in its row; only its tokens show as unknown. Money is never dropped because a label changed.

Caching and batch

When cache read/write meters are present the section shows the cache share and the saving against the uncached price; when none are present it says no caching observed rather than 0%. Batch and on-demand are split wherever the meter distinguishes them.

Tokens are a Bedrock concept. Seat-billed products and per-request services (Rekognition, Textract) appear in AI Spend by dollars only. The token report is part of AI monitoring on Growth and above.

Bedrock traffic that goes through a system inference profile or straight to a model ARN cannot be tagged, so it cannot be attributed to a team. The lever AWS provides is the application inference profile: a taggable resource you create per team, product or environment and route your calls through. Once its tag key is activated for cost allocation, the tag lands on every token line in the billing export and Refine’s showback and tag governance work on AI spend unchanged.

1. Create a profile per team

aws bedrock create-inference-profile \
--inference-profile-name team-payments-haiku \
--model-source copyFrom=arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-haiku-4-5 \
--tags key=Team,value=payments key=Environment,value=prod

Then call the model through the profile’s ARN instead of the model ARN. The finding on /tags and on AI Spend lists every profile that lacks one of your required tag keys, with the spend at stake, and marks system profiles and bare model ARNs as not taggable with this snippet ready to copy.

2. Activate the tag key for cost allocation

A tag on the resource is not enough: the key must be switched on in Billing → Cost allocation tags in the AWS console before it appears in the export. Refine checks this for you with a read-only call and reports which of your required keys are not active. It never activates a key on your behalf — that is your decision.

“Present but not active”

In the export an inactive key looks identical to a missing tag. Refine tells the two apart: a profile whose tag is set but whose key is not activated is reported as tag present, not active for cost allocation with the one-line fix, not as a missing tag. If the activation check itself cannot run (the permission is denied or the call fails) the status reads unknown — again, never missing.

3. Run showback by tag

Showback gains an AI services service group and an allocate AI spend by tag preset that runs the ordinary tag dimension over AI lines only. Tagged profiles attribute to their team; anything untaggable or untagged lands under Unallocated AI with its spend, so the gap is a number rather than a guess. Required keys come from your active tag policy (or the required-tags setting) — there is no separate AI tag list to maintain.

Kiro and Amazon Q Developer bill per user: each seat is a line in the export against an identity store user id, with the plan tier in the charge description. The Seats section of AI Spend governs them like any other SaaS licence: seats per product this month, cost per seat, plan tier, a 12-month seat-count trend, and seats added and removed month over month. The product total reconciles to the same product’s row in the service view.

New, steady, orphan

• New — billed this month, not in prior months.
• Steady — billed for three or more months.
• Orphan — still billed, but the user no longer exists in your identity store. Listed with months billed and cost at stake; a cancel candidate.

Names

Seat ids are resolved to display names and emails through your Identity Center instance, using the read-only access you already grant. Names are personal data: they render only to account Owner and Admin roles, never in digests, and are exported only by those roles. If the lookup is denied or unavailable, the roster shows ids with name unavailable — the seat counts and costs are computed from billing lines and do not depend on it.

What Refine cannot see

Whether a seat is actually used is not in the billing export, and the read-only access Refine holds does not include a usage report for either product, so usage-based inactive-seat detection is not offered today. The deterministic signals above are what ship; a seat that is steady for months while its user has left is the case they catch. Cancelling or reassigning a seat is done in the Kiro or Amazon Q console — Refine never writes to your account.

An AI seat growth alert fires when a product adds five or more seats in a month (see Notifications). Seat names are part of AI monitoring on Growth and above; counts and trends are visible to every role on the page.

Six of the recommendations on Recommendations are about AI workloads. Each is derived from your billing export alone, at rates read from your own usage rows — never from a price list Refine keeps, which would go out of date without anyone noticing.

• Batch candidate — on-demand inference that looks like it could run through the Batch API, which is priced at half. Work already batched, and work that reads like an interactive request, are excluded.
• Global inference profile — spend on a region-pinned profile where the global profile for the same model is cheaper. Priced against the difference your own rows show, so it is silent if you have never used both.
• Prompt caching — an estimate, and labelled one on the card. Cache reads and writes are not distinguishable in the export, so the hit rate is assumed rather than measured. Treat the number as a reason to look, not a figure to budget against.
• Model tier — advisory, with no dollar figure attached. Whether an Opus-class model can be swapped for a cheaper one is a question about your output quality, which billing data cannot answer; the card says what you are spending and leaves the judgement with you.
• Provisioned throughput — reported, and not priced. Provisioned throughput bills capacity rather than usage, so the tokens it served produce no line item and your bill cannot say whether it was busy. The card gives the commitment cost and the hours, names that cost as a ceiling on what could come back — and only if it served nothing — and points you at the CloudWatch invocation count, which Refine does not read. Provisioned throughput also buys guaranteed capacity and predictable latency; if that is why you bought it, nothing here is a problem.
• Idle SageMaker endpoint — hosting hours billed with no inference-request charges against them. Also a proxy: the direct signal is endpoint invocations, a CloudWatch metric Refine does not read — its one metric read is used only to confirm an idle database or cache. Async and serverless endpoints bill differently and can look identical while being in use, so confirm before deleting.

What the security scan adds

Four checks on the Security page cover configuration rather than cost — Bedrock invocation logging switched off, no guardrails, no application inference profiles (which is what makes Bedrock spend un-allocatable, see Allocating Bedrock spend), and SageMaker notebooks left running. They run in every region you have enabled, not just the one you connected — a forgotten commitment in a region nobody watches is exactly the case worth catching — and need no permission beyond the read-only access already granted at onboarding.

380+ checks across IAM, Storage, Network, Compute, and Logging, calibrated against AWS Well-Architected, AWS Foundational Security Best Practices, and CIS Benchmarks. The full 5×4 matrix can be browsed at the security findings catalog. Bedrock and SageMaker configuration is covered too, and those four checks run across every region you have enabled rather than the one you connected — see AI cost recommendations.

Findings are tiered into four severities:

• Critical — active or near-active risk (publicly exposed S3, IAM admin credentials in code, CloudTrail disabled). Address immediately.
• High — configuration weaknesses likely to be exploited or fail audit (unencrypted EBS, IMDSv2 not enforced).
• Medium — hardening opportunities; improve posture without immediate exploit risk.
• Low — hygiene. Address as time allows.

Refine never writes to your AWS account, so it does not fix a finding for you — it tells you exactly how to fix it. Where we hold a vetted remediation for a check, the finding carries a Fix Available badge and expands into How to Fix This (AWS Console Steps): a numbered walkthrough for that resource, in that region, ending in a link to the official AWS documentation for the change.

Where the scan itself returns remediation steps, those are shown in preference to the curated guide. Findings we hold no guide for say so rather than showing an empty panel.

Tag violations work the same way and go one step further: the Remediation tab generates a ready-to-run AWS CLI script or a Terraform patch covering the resources you select, with the permissions the runner needs listed in the file header and the resources it cannot address listed beside them. You run it with your own credentials.

Refine builds a rolling 30-day baseline per service per account. Anomalies use robust statistics (median absolute deviation) so noisy workloads don't bury real signals. Each anomaly is paired with AI commentary that explains the why. Details on Anomaly Detection.

Tune anomaly sensitivity per service or per account:

• High — flags smaller deviations; suitable for production
• Medium — default; balances signal and noise
• Low — only flags large deviations; useful for dev/sandbox
• Off — no anomaly detection for that scope

Quiet hours can suppress non-critical alerts for dev/sandbox accounts overnight or on weekends.

Every alert — cost anomaly, budget breach or forecast breach, commitment expiry, security finding, scheduled digest — lands in the app: the bell in the header and the full list at /notifications. In-app is always on.

On top of that, an account can send alerts out of the app by email, Slack and Microsoft Teams. That is configured under Settings → Notifications (also reachable from the bell) and is per account, not per user — the routing, quiet hours, mutes and webhooks you set apply to everyone on the account.

• Outbound delivery switch — off until an account Owner or Admin turns it on. Nothing leaves the app by email, Slack or Teams before that; in-app is unaffected.
• Alert routing — a matrix of alert type × channel. The box in each column header turns that channel on or off for every alert type; Select all channels / Clear all channels sweep the whole matrix.
• Quiet hours — a wall-clock window and timezone during which non-critical channel deliveries wait; they send when the window ends. Critical alerts go through.
• Mutes — per alert type, optionally per resource and until a date. Muted alerts stay visible in the app but never leave it.

Email goes to the account’s admins. Slack and Teams need a webhook — see Channel webhooks.

AI alerts

Five alert types watch Bedrock tokens and AI developer seats — things a dollar-only detector cannot see while the bill is still small. They are rows in the same routing matrix, honour the same mutes and quiet hours, and their thresholds can be changed per account under Settings → Notifications (AI monitoring, Growth and above). The defaults:

• AI token spike (warning) — one model’s daily token rate at least 2× its trailing baseline, and at least 10 million tokens in the period, so a first-week experiment does not page anyone.
• First-seen model (info) — a model or inference profile with spend this period and none in the prior months on record. Awareness, not alarm; it fires once.
• AI region drift (warning) — Bedrock spend in a region the account had not used for AI before.
• Output/input ratio drift (warning) — one model’s output-to-input token ratio at least 2× its baseline, above the same 10 million token floor. The signature of a retry or agent loop.
• AI seat growth (info) — a seat-billed product adds 5 or more seats in a month.

Baselines are per-day rates over the prior complete months; with no history nothing fires. Detection is daily, at the cadence of the billing export — not real time. Each alert deep-links to its anomaly page and from there to AI Spend, and the tenant digest carries an AI line only when something fired.

Refine posts alerts into a Slack or Microsoft Teams channel through a webhook: a private URL that the channel gives you, which accepts messages for that one channel. Setting it up has three parts: create the webhook in Slack or Teams, paste it into Refine, then choose which alerts go there. It takes about five minutes.

Before you start

• You need to be an Owner or Admin of the Refine account.
• Slack and Teams alerts are part of the Growth plan and above. Email and in-app alerts are on every plan.
• Settings are per Refine account. Everyone on the account shares one Slack webhook and one Teams webhook. If you manage several accounts, set each one up separately; they can point at the same channel.

Step 1 (Slack): create the webhook

1. Go to api.slack.com/apps and choose Create New App → From scratch. Name it, for example Refine alerts, pick your workspace, and select Create App.
2. In the app’s left menu, open Incoming Webhooks and switch Activate Incoming Webhooks on.
3. Select Add New Webhook, choose the channel the alerts should go to, and select Allow. If your workspace needs an admin to approve new apps, Slack asks them first.
4. Copy the new Webhook URL. It starts with https://hooks.slack.com/services/.

A Slack webhook always posts to the channel you chose when you created it. To use a different channel, add another webhook and paste that one instead.

Step 1 (Microsoft Teams): create the webhook

1. In Teams, find the channel, open More options (⋯) next to its name, and choose Workflows.
2. Pick the template Send webhook alerts to a channel.
3. Give the workflow a name, check the team and channel are right, and select Save.
4. Copy the URL Teams shows. It starts with https:// and contains powerplatform.com or logic.azure.com.

• Microsoft has retired the old Incoming Webhook connector. URLs from it, on outlook.office.com or webhook.office.com, no longer deliver. Create a workflow as above instead.
• A workflow belongs to the person who created it. If they leave your organisation it stops, so add a co-owner to the workflow in the Workflows app.
• Use a standard or shared channel. Microsoft does not yet support workflows posting as a bot in private channels.

Step 2: paste it into Refine

1. Open Settings → Notifications and scroll to Channel webhooks.
2. Paste the URL into Slack incoming webhook or Microsoft Teams incoming webhook, then select Save settings. The field then shows dots: the URL is stored encrypted and is never shown again.
3. Select Send test message under the field. Refine posts a message titled Test message from Refine that names your Refine account, and tells you straight away whether Slack or Teams accepted it. Find it in the channel you expect.

Step 3: choose which alerts go there

1. In Alert routing, tick the alert types you want in the Slack or Teams column. The box in the column header ticks every type at once. A new webhook starts with nothing ticked.
2. At the top of the page, turn on Send alerts by email, Slack and Teams. Until an Owner or Admin turns this on, nothing leaves Refine except in-app alerts.
3. Select Save settings.

Under each saved webhook, Refine shows when it last delivered there and which alert that was, or why the last attempt failed. If alerts will not reach the channel, a yellow note says why.

What arrives

One message per alert. Several alerts of the same type within ten minutes are grouped into one message with a count. Each message has a severity marker (🔴 critical, 🟠 warning, 🔵 info), the alert title, a one-line summary, and an Open in Refine button that goes straight to the anomaly, budget or finding. Alerts are sent when something happens, so a quiet week is quiet in the channel too. Test the webhook if you want reassurance.

If something is not working

• The test says “Sent” but you cannot find the message. The webhook belongs to a different channel or workspace. In Slack, the app’s Incoming Webhooks page lists the channel each URL posts to. In Teams, open Workflows and check the workflow’s channel. Create a webhook for the right channel and paste it over the saved one.
• A Teams test says “Sent” but nothing appears. Teams accepts the message before the workflow runs. Open Workflows, select the workflow, and check its run history. A workflow that was turned off, lost its owner, or targets a private channel fails there.
• The test works but alerts never arrive. Read the yellow note under the webhook: either delivery is switched off or no alert type is ticked in that column. Also check Quiet hours, which hold non-critical alerts until the window ends, and Muted alerts, which never leave the app.
• “This webhook no longer exists.” The Slack app or Teams workflow was deleted or removed from the channel. Create a new one and paste it over the saved one.
• “Refused this webhook.” It was revoked or its channel archived. Create a new one.

A delivery that fails is retried twice (after 1 and 5 seconds). If it still fails, admins see a banner on /notifications for 24 hours. The in-app alert is never affected. Refine does not send alerts that are more than a day old, so switching delivery on never floods the channel with a backlog.

Security

• Treat a webhook URL like a password: anyone who has it can post into your channel. Refine encrypts it as soon as you save it, decrypts it only to send, and never shows it or returns it again.
• Refine only accepts https:// webhook addresses issued by Slack or Microsoft Teams, so a webhook cannot point anywhere else.
• To replace a webhook, paste the new URL over the dots and save. To remove it, clear the field and save. To keep it, leave the dots alone.

Refine organizes accounts as Org → Customer → Account. The customer-hierarchy switcher in the header re-scopes everything to the customer you select. Data is strictly isolated between customers. Full architecture on the Multi-Account page.

Manage users and roles under Settings → Users & Roles. Roles include Admin, Member, Viewer, and Report-only. SSO (SAML / OIDC) is on the Enterprise roadmap.

Schedule reports under Settings → Reports. Cadence options: daily, weekly, or monthly. Recipients are configured per schedule, and a report goes only to people who are members of the account — an address outside it is skipped. For multi-customer orgs (MSPs), each customer gets its own schedule with strict data isolation.

Customer data in Refine’s database tables, file storage and backups is encrypted at rest: DynamoDB tables with AWS-owned keys, S3 with S3-managed keys (SSE-S3), and backups with AWS KMS. New connections use a read-only IAM role and no access key; the access key of an older connection is encrypted separately with a dedicated AWS KMS key until it moves to a role. All data in transit uses TLS 1.2 or higher. Refine is hosted entirely on AWS — your data stays inside the AWS trust boundary. Full architecture on Security & Trust.

The IAM role the connector stack creates is strictly read-only: AWS-managed Billing and SecurityAudit policies, S3 read scoped to the export bucket, one Savings Plans read (savingsplans:DescribeSavingsPlans, for each plan’s end date) and one CloudWatch read (cloudwatch:GetMetricData, the connection and command counts that show whether a database or cache is idle). The details are on Security & Trust. There is no second, elevated policy: "Fix Available" shows you the AWS Console steps and the official AWS doc, and you make the change.

Cost and usage data is kept for the life of your account — it is not expired on a timer, so your history stays comparable year over year. Alerts and notifications are deleted automatically after 90 days. Deleting a connected account under Settings → AWS Accounts erases its stored analyses and billing exports. To request deletion in writing:

1. Email info@habilelabs.io from the address associated with the account, OR
2. Use the in-app deletion flow under Settings → General Settings → Delete customer.

Deletion is processed within 5 business days. We send written confirmation when complete.

One of its four plans is. Free costs nothing while your AWS bill is under $2,000 a month, with no credit card and no trial clock, and covers one connected AWS account with the core cost visibility. Above that the plan follows your prior-month AWS bill — Growth at $100/mo from $2,000, Scale at $200/mo from $10,000, and Enterprise on a custom annual agreement from $50,000. All four are available today. The paid plans are set up by our team and invoiced directly; there is no card checkout on this site, and the AWS Marketplace rail is not open yet. SSO and advanced RBAC are named on the Enterprise plan but are not shipped yet, and /pricing marks them as such. A plan's band is decided by your AWS bill for the prior calendar month (BilledCost, after credits) — the same total your Refine dashboard shows. Data retention does not vary by plan: your cost and usage data is kept for the life of your account on every one of them. See pricing for the full comparison.

A read-only IAM role, created for you by the connector stack: account-wide billing, security-audit, Savings Plans and CloudWatch-metrics read, plus read access to your export bucket — no write or admin permissions. A new connection needs no AWS access key — Refine assumes the role for an hour at a time, and only by presenting the External ID your stack was created with. (An account connected earlier with an access key keeps it, encrypted, until you move it to a role.) Revoke any time by deleting the role in your AWS console. Details on the Security & Trust page.

Yes, on a paid plan. The hierarchy has no org or account limit and a switcher in the header; connecting more than one AWS account, and syncing an AWS Organizations management account, are Growth-and-up capabilities, while the Free plan covers one standalone account. See pricing. White-label customization for MSP partners is on the roadmap.

No. Customer data is not used for model training. AI narratives are generated per-request by Amazon Bedrock, inside AWS and in the same region as your data. Aggregated anonymized usage stats improve recommendation quality.