Support

Support is how you let the ServerlessInbox support team look at your deployment when you need help — without giving anyone standing access to your AWS account. Nothing is granted by default: support can only reach your account inside a case that you opened, for a tier that you granted, and only until the activation window you set runs out.

There is no vendor-initiated path in. Support cannot ask your account for access, and your account never exposes an inbound surface to us. Every step starts in your admin console.

Enabling or disabling the feature

The ServerlessInbox Standard template has a SupportAccess CloudFormation parameter with the allowed values enabled and disabled. It defaults to enabled. When it is set to disabled, no support resources are created at all — no roles, no case management, no API.

Setting it to disabled does not grant anyone anything to switch off later; access is inert until you open a case regardless.

The two tiers

A case can grant either or both tiers. Both are strictly read-only — there is no tier that can change or delete anything, and no tier can read mail content.

Tier	Console label	What it can read
Diagnostics	Diagnostics (read-only)	CloudWatch Logs (log groups, log streams, log events, filtered events, Logs Insights queries) and CloudWatch metrics (metric data, statistics, metric list).
Config read	Config read (read-only)	Everything the diagnostics tier can read, plus infrastructure configuration: Lambda function configuration/versions/aliases/policies, Step Functions state machines and execution history, DynamoDB table descriptions (structure and TTL settings — not table contents), SQS queue attributes, EventBridge rules and targets, CloudFormation stack descriptions, SSM parameters, and SES account/identity/receipt-rule/configuration-set settings.

Outside of the account-level “list” calls that AWS cannot scope by tag, every permission is restricted to resources tagged as belonging to your ServerlessInbox stack. Neither tier can read anything in your account that is not part of that stack.

Opening a case is consent — granting a tier is a separate act

These are two deliberate, separate steps:

1. Opening a case records your consent for the support team to work on the issue and to be able to access your account for it. On its own it grants nothing. You can open a case with no tiers at all; that is the normal way to start.
2. Granting a tier is what actually opens access, and it is always an explicit action on the case. The console spells this out: “Granting a tier is a separate action from opening the case, and is not automatic.”

Describing the issue and asking for a higher tier both happen out of band today, through the normal support channel you already use. There is no in-product messaging, no request-for-access inbox, and no approval queue — the case carries a ticket reference, not a conversation.

The activation window

Access ends by itself. Every case carries an active until timestamp, and a tier stops working the moment it passes — you do not have to do anything.

Setting	Value
Default when opening a case from the admin console	24 hours (the new-case form pre-fills it)
Default when the Admin API is called without an activation window	3 days
Default when reactivating a lapsed case by granting a tier again	24 hours
Minimum	5 minutes
Maximum	7 days
Maximum concurrent open cases	5

The 7-day maximum is a re-consent interval, not a cap on total access: nothing stops you reactivating a case as often as the issue needs. It exists so that access never quietly persists past the point where you last said yes.

A case whose window has lapsed shows as Expired in the console. It is not closed, and it is not deleted — it is dormant, and it grants nothing. Granting a tier again reactivates it, with the same case, the same ticket reference and the same identity used for the trust relationship, for a fresh window (24 hours unless you say otherwise).

You can hold at most 5 open cases at a time. Opening a sixth is rejected until one of them is closed. This limit exists because each tier’s access list is stored in an AWS IAM role tag with a character limit — a bound on open cases bounds the size of every tier list at once.

Closing a case

Close now is always available on an open case, and it takes effect immediately and irreversibly. Access is revoked first, before anything else about the case is updated, so a failure part-way through can only leave you with less access granted than you asked for, never more.

Closing is purely local. It runs entirely inside your own AWS account and does not depend on the vendor being reachable. If our service is down, or you have cut off outbound network access, or you simply do not trust us at that moment, closing the case still works and still revokes access.

(Opening a case is the one operation that does contact the vendor, to register the case. If that call fails, the case is not created at all and you can retry — you are never left with a half-created case.)

Seeing what support actually did

Each case detail page lists the role assumptions recorded against it: when the session started, which role was assumed, and the source IP. That record is kept in your own account and is not dependent on CloudTrail’s 90-day event-history window.

Two timing effects are worth knowing, because the console reports them rather than hiding them:

• CloudTrail events take roughly 15 minutes to appear. An empty list is therefore not automatically proof that nothing happened. When the console cannot confirm this, it says “May not have propagated yet” rather than “No access has occurred” — and it only says the latter when the live lookup actually answered.
• A newly granted tier takes roughly 30–70 seconds to take effect, and the delay is variable. An AccessDenied shortly after granting is expected rather than a fault. The lag only ever runs in the safe direction: access is slow to arrive, not slow to leave.

Every open, close, grant and window change is also written to your tenant audit log, attributed to the admin who performed it.