AWS
Where a great many enterprise workloads actually live. Connecting it means an assistant can answer about the state of the services your teams depend on, without anyone opening a console.
Where a great many enterprise workloads actually live. Connecting it means an assistant can answer about the state of the services your teams depend on, without anyone opening a console.
What AWS holds, and why that matters here
Most organisations that run anything at scale run part of it on AWS. What matters here is not the breadth of the platform but the small number of questions people ask about it repeatedly: is the service healthy, did the job finish, where is that file, what is this costing.
Those questions currently go to whoever holds console access. That is a small group by design, and it becomes a bottleneck the moment anyone outside it needs an answer — which is constantly.
The connection is read-only and scoped to an explicit list. Reading a job status does not need permission to start one, and reading a bucket listing does not need permission to write to it. That distinction is what makes this reviewable.
- Service health — what is running, what is degraded, what is scheduled.
- Job and pipeline state — finished, failed, still going, and when.
- Object storage — file presence and metadata, within named paths only.
- Cost and usage — where spend is going, for those entitled to see it.
- Tags and environments — which estate a resource belongs to.
Questions Elbi can answer from your AWS account
Is this service healthy?
Current state from your own monitoring, in a sentence rather than a dashboard.
Did that job finish?
Completion state and time, without opening a console.
Where is that file?
Presence and metadata within the paths you allow.
What is this costing us?
Spend by service or tag, for those entitled to see it.
Which environment is this in?
The tags as recorded, not as remembered.
Is there an incident open?
What is declared, so nobody files a second ticket for it.
How Elbi reads from an AWS account
- An IAM identity made for this connectionYour team creates a role in your own account, or a dedicated IAM user where a role cannot be used, and attaches a policy you wrote. The assistant uses it and nothing else does, so its permissions describe the connection exactly, and deleting it ends the connection cleanly.
- A policy that names actions and resourcesThe policy lists individual read actions — describing alarms, reading the latest runs of named jobs, listing objects under one prefix — against specific resource ARNs or tag conditions. Wildcard actions and the broad AWS managed read-only policies are left out, because they reach far more than any of these questions needs.
- Each question is tied to a known callDuring deployment, every supported question is mapped to the API call that answers it. "Did last night's load finish?" becomes a read of one state machine's most recent execution, not a search across the account for something that looks relevant.
- The asker's entitlement narrows it furtherThe IAM policy is the ceiling for everyone. Within it, what a given person is told follows their identity from your own sign-in, so spend figures can stay with finance and leadership even though the role itself is able to read them.
- AWS states become plain sentencesAn alarm in the ALARM state, an execution marked FAILED, a timestamp in UTC and a resource ARN are all accurate and all unhelpful to most people. The answer comes back as a sentence in Arabic or English, with the identifiers left out.
- Changes stay where they are governedRe-running a job, scaling a service or changing a budget stays in the console, the CLI or your deployment pipeline, under the approvals that already apply there. The assistant can say that a job failed and hand the conversation to a person; it does not restart the job.
Scope and control on the AWS side
| Direction of access | Read-only. The policy holds describe, get and list actions on named resources and nothing that creates, modifies or deletes. Reading a job's status does not require permission to start it, so that permission is never requested. |
|---|---|
| Who can see what | Two layers. The IAM policy decides what the connection can reach at all; the asker's own identity decides which of those answers they receive. |
| Credentials | An IAM identity you create, in your account, used only by this connection. If it is assumed from outside the account, set an external ID, which is AWS's documented safeguard for third-party access. If an access key is unavoidable, you rotate it on your own schedule, and detaching the policy or deleting the identity takes effect from your side without involving us. |
| Where data goes | Whatever is read is used to answer the question that asked for it. Message content is destroyed within 24 hours, usually when the conversation ends, and no external AI service sees it. |
| Audit | CloudTrail in your account records the API calls the connection's identity makes, independently of anything on our side. Object-level S3 reads appear there only if data events are enabled for the bucket, so enable them for the buckets in scope if you want that trail as well. |
| If it is unavailable | If a call is throttled, times out or comes back AccessDenied, the assistant says it could not get the answer and offers a person. A denied request must never be reported as "nothing found" — the two mean very different things — and it is one of the cases rehearsed before launch. |
What the AWS connection replaces
What this replaces is a queue in front of a small number of people. Console access is restricted for good reasons, so every question from outside that group becomes an interruption — and the answer is almost always a single field somebody reads off a screen.
The cost is invisible because it is distributed: two minutes here, five there, several times a day, spread across the people you least want interrupted. Nobody logs it, so nobody sees it.
The connection removes the middle step for questions that have a definite answer, and leaves anything requiring judgement — or any change at all — exactly where it was.
Which teams use the AWS connection, and for what
Engineering
Job and deployment state without breaking someone's focus.
Operations
Service health in plain language during an incident.
Finance
Spend by service and tag, on a schedule or on demand.
Data teams
Pipeline completion, without console access for everyone.
Support
Whether a customer-facing service is actually degraded.
Leadership
A straight answer about status without assembling a call.
Getting value from the AWS connection
Start with the questions that already interrupt your cloud or platform team. They are usually few and repetitive: did the overnight job finish, is the problem ours or AWS's, has the file landed yet, what did this project cost last month. Counting them across a few weeks of chat messages and tickets gives you the list to connect for, and it tends to be shorter than people expect.
Health answers are only as good as your CloudWatch alarms. If nothing monitors a service, the honest reply is that nothing monitors it, which is worth knowing in itself. Where alarms exist, putting them in scope alongside AWS Health events for the account lets the assistant separate a fault in your workload from one in the platform — the "is it us or them?" question that otherwise lands on an engineer. API access to AWS Health depends on your AWS support plan, so check that before promising it.
Cost and environment answers depend on tagging. When resources carry consistent tags for environment, project and owner, "what is staging costing?" has a clean answer; when they do not, the assistant can only report the tags that exist. User-defined tags also have to be activated as cost allocation tags in the Billing console before they show up in cost data, a step that is easy to miss and a common reason cost-by-tag questions come back empty.
What connecting AWS involves
- List the questions and what answers themFor each question, write down the account, region and resource that holds the answer: the state machine, the alarm, the bucket and prefix. A question that cannot be tied to a specific resource is not ready to connect yet.
- Write the policy, then check itTurn that list into a policy of specific read actions on specific ARNs. IAM Access Analyzer can validate it and flag statements that are broader than intended before it is attached to anything.
- Create the identity in your accountYour team creates the role or dedicated user, attaches the policy and passes on only what the connection needs in order to use it. Under AWS Organizations this is usually one role in each member account in scope, rather than a single identity with reach across all of them.
- Decide how cost data is reachedConsolidated billing data sits with the management account, which is the account you most want to keep closed. Many organisations therefore answer cost questions from a scheduled cost and usage export delivered to an S3 bucket, and grant read access to that bucket instead.
- Test the refusals as well as the answersAsk for things outside scope on purpose: another bucket, another region, a cost figure from someone not entitled to it. Confirm that each is refused cleanly and that the calls appear in CloudTrail under the connection's identity.
- Start with one account, then widenGo live against a single account and a short list of questions. Add accounts, regions and questions once real people have used the first set and the policy has held up under them.
Personal data and residency in an AWS connection
Most questions about cloud state involve no personal data at all: alarm states, job outcomes and cost figures describe infrastructure, not people. The exceptions are predictable — S3 objects that hold customer documents, application logs that record user details, and tags or resource names that carry someone's name or email address. Under the Saudi Personal Data Protection Law, those are the paths that need a stated purpose before they go into scope, and they are also the easiest to leave out.
Residency on the AWS side is set by the regions you chose for each workload and bucket. The connection reads from them where they are and does not move stored data between regions or accounts. Record the in-scope accounts and regions in the same document as the IAM policy, because a PDPL or internal review will ask where the source data sits as well as who can read it.
Most of the evidence is already in your hands. The IAM policy answers "what could it read?" and CloudTrail answers "what did it read?" — both in your account, under your control, and reviewable without asking us.
What organisations typically see
Other ways to answer AWS questions, and their trade-offs
AWS offers its own routes. Amazon Q Developer answers questions about resources and costs for people signed in to the AWS console, within their own IAM permissions, and AWS's chat integration can post alarms and notifications into Slack or Microsoft Teams channels. For engineers who already work in the console, these are natural choices.
The common in-house alternative is to give more people view-only console access, typically through IAM Identity Center with the ViewOnlyAccess job-function policy. It works, but every extra console user is another identity to review, and the person still has to know which service and which region to look in.
Some teams build their own bot on Amazon Lex or Amazon Bedrock. That brings full control and full responsibility: someone has to own the permission model, the Arabic handling and the upkeep for as long as it runs.
Whichever route is taken, the failure that recurs is the over-broad grant. Attaching the AWS managed ReadOnlyAccess policy is quick, but it reads far more of an account than its name suggests, including the contents of S3 objects. That is why the policy for this connection is written action by action.
Common questions about the AWS connection
No. Read-only, scoped to an explicit list of services and paths. Reading a job status does not require permission to start one, and we do not ask for permission we do not need.
Only what you name. The scope is a list you write and can audit, not a role with broad reach.
Answers are bounded by the identity of the person asking. Somebody without entitlement to cost data does not get cost data through the assistant.
What is read is used to answer the question that prompted it. Nothing is copied into a second store, because a second store means drift and another thing to defend.
Each is scoped separately. Starting with one is faster and makes the review shorter.
By revoking the service credential. It is separate from anyone's personal access for exactly this reason.
No. The connection runs as an IAM identity you create in your own account for the assistant, bounded by a policy you wrote. IAM shows what it may do, CloudTrail shows what it has done, and you can remove it without going through us.
It can be scoped to named log groups, but logs are where personal data and secrets tend to end up. Start with alarms and job states, and add a log query only where a specific, recurring question needs one.
Some can. Several AWS APIs are billed per request, the Cost Explorer API among them, and S3 requests are billed as usual. Each question maps to a single named call rather than a scan, and cost questions can be answered from a scheduled export instead of live API calls.
Connect it to your own systems
A working assistant against your own records, in both languages.