AWS Access
Expiry, revocation and re-authorization
Access ends on a date you set whether or not anyone remembers, and you can end it sooner by deleting one stack.
Expiry is enforced twice
You set an engagement expiry when you create the stack. Two separate rules act on it.
| Rule | Effect |
|---|---|
| A condition on the trust policy | No new session may be issued after that time |
| A deny statement inside the role | Every action is denied after that time |
The second exists because the first is not sufficient on its own. A session issued moments before expiry is still valid for up to an hour, and the deny kills it. A denial in IAM overrides every allow, including the managed policies.
Nobody has to remember to remove anything. Access stops working on the date, whether or not anyone acts.
Revoking sooner
You can remove the access before the expiry date, but only after checking who owns the role and that nothing else relies on it. One role serves every GovIntel engagement for an account, so it must not be deleted blindly. Nothing on GovIntel's side needs to succeed for your own removal to take effect, and GovIntel never removes anything in your account. The checks and the removal steps are in Revoking GovIntel access after your assessment.
What expiry does not do
It does not delete the role, and it does not delete anything of yours. An expired role still exists and denies everything, which is why re-authorizing is an update rather than a fresh build.
Re-authorizing
Re-opening the window means updating the existing stack with a new expiry, not creating a second one. There is one role per account, always.
Creating a second stack against an account that already holds the role fails, because the role name is fixed per account. See If your account already has GovIntel access.