AWS access:
how one laptop reaches a private database

An access key belongs to one IAM user and has two parts. The access key ID, AKIAIOSFODNN7EXAMPLE, identifies the key the way a username identifies a person. It travels with every request and appears in every CloudTrail event the key causes, so it is not a secret.

The secret access key is 40 characters long, and AWS shows it only once, in the response that creates the key. No API returns it later. Lose it, and the only fix is to delete the key and create a new one.

Each IAM user can have at most two access keys at a time. The second slot exists so a rotation can overlap: create the new key, move every program to it, then delete the old one.

Every IAM identifier starts with a four-letter prefix that names its type. AKIA marks a long-term access key, like the one in your credentials file. ASIA marks a temporary access key issued by STS, the subject of chapter 02. IAM’s documentation adds that an ASIA key ID is unique only together with its secret and its session token.

The other prefixes name identities rather than keys: AIDA is an IAM user, AROA a role, ANPA a managed policy, ABIA an STS service bearer token. The reference page for STS GetAccessKeyInfo states the same rule for keys: AKIA means long-term, and ASIA means temporary.

aws configure asks four questions and writes the answers to two files. The key ID and secret go under [default] in ~/.aws/credentials, and the Region and output format go in ~/.aws/config. Both are plain-text INI files. Any process running as you can read them, and so can backups, dotfile repositories and container images built from your home directory.

The command sends nothing to AWS. It doesn’t check that the key exists or works, so a mistyped secret only shows up on the first real request, as SignatureDoesNotMatch. Nothing in either file says when the key expires, because an AKIA key never does.

At 09:02:10 you run aws sts get-caller-identity, request #1. It returns a UserId starting AIDA, the Account 111122223333 and the Arn of user new-engineer. The call needs no IAM permission and works even under an explicit deny, because the same details come back in any access-denied error.

At 09:03:40, aws sts get-access-key-info with --access-key-id AKIAIOSFODNN7EXAMPLE is request #2. It returns the account that owns the key, from the key ID alone, and doesn’t say whether the key is still active. Pasting the key in sent nothing, so Σ requests the laptop sent is now 2.

At 09:05:12, aws s3 ls s3://ledger-invoices/2026/11/ sends request #3, a GET to the bucket with the prefix in the query string. Its headers carry the host, an X-Amz-Date timestamp and X-Amz-Content-Sha256, the SHA-256 of the body, which for a GET is the hash of zero bytes.

The last header is Authorization, in SigV4 form: the algorithm, a Credential= naming the key ID with a date, Region and service, the list of SignedHeaders, and a Signature= of 64 hex characters, one HMAC-SHA256. None of the secret’s 40 characters appears in the request. Σ requests the laptop sent is now 3.

Before signing, the CLI writes a canonical request: the method, the path, the query string sorted by name, the headers lowercased and sorted, the list of signed header names, and the SHA-256 of the body. Canonical means there is exactly one way to write it, so two machines that see the same request produce the same bytes.

The string to sign is four lines: AWS4-HMAC-SHA256, the timestamp, the credential scope, and the SHA-256 of the canonical request. AWS rebuilds both from what it received and signs them with its own copy of the secret. If one byte of a signed part changed on the way, the two signatures differ and the answer is SignatureDoesNotMatch.

The secret never signs a request directly. It goes through four HMACs first. kDate is the HMAC of the date 20261109 under the key “AWS4” plus the secret. kRegion is the HMAC of us-east-1 under kDate, kService adds s3, and kSigning adds the fixed string aws4_request.

The signature is the hex HMAC of the string to sign under kSigning. AWS derives the same key from its own copy of the secret, so both sides agree without the secret crossing the network. The derived key is good for one date, one Region and one service. The same signature sent to S3 in us-west-2, or to STS, is refused.

X-Amz-Date is one of the signed headers, so the timestamp can’t be changed without breaking the signature. In most cases a request must reach AWS within five minutes of that timestamp, or AWS refuses it.

That rule limits replay: a request copied off the network stops working a few minutes later, although its signature is still correct. It also refuses honest requests from a laptop whose clock has drifted, which is why a Signature expired error is fixed with NTP, not with new keys.

aws s3 presign s3://ledger-invoices/2026/11/INV-0042.pdf --expires-in 3600 moves the same kind of signature from the header into the query string, as six X-Amz parameters. The CLI computes all of it on the laptop and sends nothing, so Σ requests the laptop sent stays at 3.

The result is a presigned URL. Whoever holds it can make that one GET as you, with no credentials of their own, until it expires. Signed with an IAM user’s key, it can last up to 7 days. Signed with temporary credentials, it stops working when they expire, whatever X-Amz-Expires says.

The IAM user new-engineer can do almost nothing in ledger-prod on its own. What it may do is assume the IAM role ops-readonly. At 09:20:31, aws sts assume-role sends request #4 to AWS STS, signed with the AKIA key from chapter 00.

STS returns four fields: an AccessKeyId starting ASIA, a SecretAccessKey, a SessionToken and an Expiration of 2026-11-09T10:20:31Z. Together they are temporary credentials. Temporary credentials work like a hotel key card: encoded for one room and one checkout time, and useless after checkout without anyone having to collect them.

DurationSeconds sets the lifetime. It defaults to 3,600 seconds, and it can range from 900 up to the maximum configured on the role, which is at most 43,200 seconds (12 hours).

IAM has no record of an ASIA key. No user owns it, and aws iam list-access-keys never lists it. IAM’s documentation says an ASIA key ID is unique only in combination with its secret access key and its session token.

The session token is an opaque string from STS. It tells the service that receives a request which role session the key belongs to, when that session expires, and which session policies and tags apply. Those policies and tags take up room inside the token, so AssumeRole reports how much of the maximum they used, in PackedPolicySize.

At 09:21:05, with the three values exported, aws s3 ls sends request #5. Compared with #3 in chapter 01, one header is new: X-Amz-Security-Token, which carries the session token. Its name appears in SignedHeaders, so the token is covered by the signature, just as the timestamp is.

The Credential= field now starts with ASIA, and the signature is computed exactly as in chapter 01, with the temporary secret in place of the long-term one. An ASIA key sent without its token is refused with InvalidClientTokenId, even when the signature is correct.

The trust policy on ops-readonly lets the account assume the role only when aws:MultiFactorAuthPresent is true. That is why request #4 carried --serial-number, the ARN of new-engineer’s MFA device, and --token-code with a 6-digit code.

STS checks the code when it creates the session and records that MFA was used. Requests signed with that session then count as MFA-authenticated until its Expiration, and the code is never sent again.

GetSessionToken is the other way to get MFA-backed credentials, with no role involved: 12 hours by default and up to 36 for an IAM user, and at most 1 hour for the root user. A role assumed from another role session, called role chaining, is capped at 1 hour.

At 10:24:50, with the same three variables still exported, aws s3 ls sends request #6, and S3 answers ExpiredToken. Nothing on the laptop changed. The Expiration inside the token passed at 10:20:31, four minutes earlier.

Exported variables are plain strings. Nothing watches their expiry time or fetches a replacement, so every command after 10:20:31 sends the same expired credentials. A profile can renew itself, which is chapter 03. This chapter adds 3 requests, and Σ requests the laptop sent is now 6.

The credential chain is the fixed list of sources the AWS CLI v2 checks before it signs a request. In order: command-line options, environment variables, assume-role settings, web identity, IAM Identity Center, the credentials file, a custom process, the config file, ECS container credentials and the EC2 instance profile.

The CLI stops at the first source that returns credentials and never reads the rest. Sources are never merged, so a key ID from one place is never paired with a secret from another. The environment-variable source doesn’t check whether its keys have expired either: it hands them over as they are.

At 10:26:15 you run export AWS_PROFILE=ops-readonly and then aws s3 ls again. Request #7 gets ExpiredToken, the same answer as #6. AWS_PROFILE only chooses which profile rows 3 to 8 read, and row 2 answered first, with the keys that expired at 10:20:31.

--profile ops-readonly on the command line would have worked. When a profile is named that way, botocore, the Python library under the CLI, leaves the environment-variable source out of the chain. aws configure list shows where each value came from, and here its TYPE column says env for both keys.

Unset the three variables, and profile ops-readonly takes over. Its section in ~/.aws/config holds no key at all: role_arn names the role, source_profile = default names the key that may assume it, and mfa_serial names the device to ask a code for.

At 10:27:40 the CLI prompts for a code and calls AssumeRole itself as request #8, signed with the default profile’s AKIA key. It writes the response to ~/.aws/cli/cache/ as JSON, then signs #9, the listing, with the new ASIA key. When those credentials expire at 11:27:40, the next command calls AssumeRole again, so there is no exported copy to go stale.

This chapter adds 3 requests, #7 to #9, and Σ requests the laptop sent is now 9.

On AWS compute the same chain ends in its lower rows, and every source there hands out ASIA keys. An EC2 instance gets its instance profile role’s credentials from the instance metadata service at 169.254.169.254, row 10. IMDSv2, the token-protected version of that service, is covered in the VPC tutorial.

An ECS task gets its task role from the container credentials endpoint, row 9. An EKS pod uses web identity, row 4, or EKS Pod Identity, whose agent on the node at 169.254.170.23 also answers through row 9. Lambda sets AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY and AWS_SESSION_TOKEN as environment variables, row 2.

The same code therefore runs on the laptop and on the server without a change. Only the row that answers is different.

AWS Single Sign-On was renamed IAM Identity Center on 26 July 2022. The CLI kept the old name: its commands are still aws sso and its config keys still start with sso_. Identity Center users live in its own directory or in an external one such as Okta or Microsoft Entra ID. None of them is an IAM user, so none of them has an access key.

An administrator assigns a permission set to a user for one account, and Identity Center creates a matching IAM role in that account, named AWSReservedSSO_DatabaseOps_ plus a random suffix. When you sign in and pick DatabaseOps, every request you make to ledger-prod is made as that role.

At 11:00:05 you run aws configure sso. The person signing in has no AWS key yet, which is the reason for signing in, so the first requests can’t be signed with SigV4. RegisterClient (#10) registers the CLI as an OAuth client (OAuth is the web’s standard for letting an app act for a signed-in user) and returns a clientId and a clientSecret.

The CLI then opens your browser at the sign-in page. Since CLI 2.22.0 the default flow is PKCE: the CLI sends a hash of a random secret first and reveals the secret itself at the end, which proves the same program started and finished the sign-in. After sign-in and MFA, the browser hands an authorization code to a listener the CLI runs on localhost.

CreateToken (#11) trades that code and the PKCE secret for an access token and a refresh token. botocore’s service model marks RegisterClient and CreateToken authtype: none. With --use-device-code, the CLI uses the older device-code flow instead: it prints a short code, and you type it into a browser anywhere.

~/.aws/sso/cache/ now holds a JSON file with accessToken, expiresAt and refreshToken. The access token is a bearer token: AWS accepts it from whoever sends it, with no signature. The CLI uses it to list your accounts (#12, ListAccounts) and your roles in ledger-prod (#13, ListAccountRoles), sending it in an x-amz-sso_bearer_token header.

At 11:01:10, aws sts get-caller-identity --profile ledger-prod needs a key, so the CLI first calls GetRoleCredentials (#14) with the bearer token. It gets back accessKeyId (ASIA…), secretAccessKey, sessionToken and expiration. Then it signs GetCallerIdentity (#15) with SigV4, and the Arn that comes back ends in oncall@example.com: your email address is the role session name.

Signing in and asking one question took 6 requests, and Σ requests the laptop sent is now 15.

Two durations apply, and an administrator sets them in different places. The access portal session decides how often you sign in through the browser: 8 hours by default, configurable from 15 minutes to 90 days. The permission set’s session duration decides how long each batch of role credentials lasts: 1 hour by default, up to 12. DatabaseOps is set to 4 hours.

While the portal session is valid, the CLI fetches new role credentials without asking you anything. You signed in at 11:00, and the credentials from #14 last until 15:01:10. That covers both Session Manager commands in chapters 06 and 07, so neither of them needs another GetRoleCredentials.

An access key and an Identity Center sign-in differ in what sits on the laptop and how long it lasts. The key is two strings in ~/.aws/credentials that work until someone deletes them. Identity Center leaves a token file and cached ASIA credentials that expire within hours. MFA happens at every sign-in, and CloudTrail names you by email instead of by IAM user.

Offboarding differs too. A departing engineer’s access keys have to be found and deleted in every account that has them, while an Identity Center user is disabled once. That has one catch, covered in chapter 05: role sessions already issued keep working. The last row is identical on both sides, because the request that reaches S3 or STS is ordinary SigV4.

At 13:00:02 you run aws iam delete-access-key --user-name new-engineer --access-key-id AKIAIOSFODNN7EXAMPLE with the default profile. Request #16 is signed by the key it deletes, and IAM accepts it, because the key still existed when the request arrived. At 13:00:30, aws sts get-caller-identity (#17) is refused with InvalidClientTokenId: “The security token included in the request is invalid.”

The message says “security token” about a key that has no token: AWS uses that wording for any key ID it doesn’t recognize. In an incident, mark the key Inactive with aws iam update-access-key first. An inactive key is refused too, and unlike a deleted one it can be switched back on. Σ requests the laptop sent is now 17.

In a controlled test on 19 December 2025, Palo Alto Networks Unit 42 pushed a working access key to a public GitHub repository at 18:50:05 UTC. At 18:50:15, ten seconds later, AWS attached the managed policy AWSCompromisedKeyQuarantineV3 to the key’s IAM user. GitHub’s own alert arrived at 18:50:16.

The quarantine policy denies a list of commonly abused actions, such as creating users and access keys or launching instances. It doesn’t deactivate the key, so every action the list leaves out still works. CloudTrail records the attachment as an AttachUserPolicy call, as if a user had made it.

No API deletes a temporary credential. Deleting an AKIA key doesn’t end the sessions already created from it either, so credentials it got from GetSessionToken keep working for up to 36 hours. What you can do is refuse them: a Deny on every action when aws:TokenIssueTime is earlier than a chosen instant refuses every session issued before that instant.

The IAM console’s “Revoke active sessions” button on a role does exactly this. It attaches an inline policy named AWSRevokeOlderSessions holding the current time, and it doesn’t affect long-term keys, which carry no issue time. Disabling an Identity Center user blocks new sign-ins, but the role sessions that user already holds keep working for up to 12 hours.

Rank each credential the laptop held today by how long it would work if it leaked. The AKIA key had no end of its own and worked until #16 deleted it. AssumeRole credentials lasted 1 hour here and can last 12. GetSessionToken credentials last 12 hours by default and 36 at most. The SSO role credentials last 4 hours.

The SSO token file is the long one. While the portal session lasts, 8 hours here and up to 90 days if an administrator allows it, a copy of ~/.aws/sso/cache can buy fresh role credentials on any machine. A Session Manager TokenValue is the short one: it is valid only long enough to open its connection.

Session Manager, part of AWS Systems Manager, reaches an instance through a connection the instance opened itself. SSM Agent, preinstalled on Amazon Linux 2023 and many other AWS AMIs, uses the instance profile’s role, with the managed policy AmazonSSMManagedInstanceCore, to open outbound HTTPS on port 443 to the ssm and ssmmessages endpoints. The role’s keys come from row 10 of chapter 03’s chain. Agents from version 3.3.40.0 prefer ssmmessages over the older ec2messages.

db-bastion’s subnet has no NAT gateway, so it reaches those services through interface endpoints, one per service. Three endpoints in 2 Availability Zones at $0.01 an hour each, for 730 hours, cost $43.80 a month. Default Host Management Configuration can supply the role without an instance profile, but only on instances that require IMDSv2.

At 14:00:00, aws ssm start-session --target i-1234567890abcdef0 --profile ledger-prod sends StartSession (#18), signed with SigV4 using the SSO role credentials from chapter 04. The response has three fields: a SessionId, a StreamUrl of the form wss://ssmmessages.us-east-1.amazonaws.com/v1/data-channel/…, and a TokenValue of at most 300 characters.

The Session Manager plugin, a separate program the CLI starts, opens that WebSocket (#19) and presents the TokenValue, which is good only for opening this one connection. SSM Agent on db-bastion opens its own outbound data channel to ssmmessages, and the service joins the two connections. Σ requests the laptop sent is now 19.

A session token, from chapter 02, is part of a credential. It travels with an ASIA key, is signed into every request, and expires with that key. Requests #4 and #14 each returned one, and whoever copies it can call AWS as you until its Expiration.

A Session Manager SessionId names one shell connection. aws ssm describe-sessions lists it, aws ssm terminate-session ends it, and it begins with the caller’s name: the API reference’s example is John-Doe-0dc5b7af96EXAMPLE. It signs nothing, so printing it in a log does no harm.

The TokenValue that came back with it in #18 opens one WebSocket and is useless afterwards. When an onboarding doc asks for a “session ID” next to an access key, it means the session token, the only one of the three that can sign an AWS request.

Session Manager checks one IAM permission instead of a Linux account: ssm:StartSession on the instance and on the session document. Here the instance must carry the tag team=ledger-ops, and the DatabaseOps permission set grants it. There is no authorized_keys file and no Linux password anywhere in the path.

The shell runs as ssm-user, an account SSM Agent creates and adds to sudoers. Run As can map IAM principals to other OS users, though never to root. CloudTrail records each StartSession under your SSO identity, and the shell’s input and output can be logged to S3 or CloudWatch Logs.

A traditional bastion host sits in a public subnet with a public IPv4 address, which costs $0.005 an hour, or $3.65 a month. Its security group allows inbound port 22 from an office range, and every engineer’s public key goes into authorized_keys. To reach the database you run ssh -L 5432:ledger-db…:5432 ec2-user@bastion.

Each of those SSH keys is a long-term credential, like an AKIA key, with three differences. IAM can’t see it, CloudTrail doesn’t log its use, and removing it means editing a file on the instance. Offboarding one engineer means finding their line in authorized_keys on every bastion they could reach.

Port forwarding through Session Manager uses a different session document, not a different service. At 14:10:00, aws ssm start-session with --document-name AWS-StartPortForwardingSessionToRemoteHost, host set to ledger-db’s endpoint and both port numbers set to 5432, sends StartSession (#20). The plugin then opens WebSocket #21, as in chapter 06.

The plugin listens on localhost:5432 on the laptop. For each connection psql makes, SSM Agent on db-bastion opens a TCP connection to ledger-db:5432, which ledger-db’s security group allows from db-bastion’s. The database needs no agent; the feature needs SSM Agent 3.1.1374.0 or later, from May 2022. Σ requests the laptop sent is now 21.

RDS IAM authentication replaces the database password with a SigV4 signature. aws rds generate-db-auth-token with the hostname, port 5432 and username ops_readonly builds a presigned request on the laptop, the same construction as chapter 01’s presigned URL, and sends nothing. The token it prints is valid for 15 minutes.

psql sends that token as the PostgreSQL password over the tunnel, with sslmode=require, because the server’s certificate names ledger-db and not localhost. The database user has the rds_iam role, and DatabaseOps grants rds-db:connect. No database password is stored anywhere, and Σ requests the laptop sent stays at 21.

SSH over Session Manager runs the SSH protocol inside a session, for tools such as scp, rsync and remote IDEs. A ProxyCommand in ~/.ssh/config runs aws ssm start-session with the document AWS-StartSSHSession. sshd must run on the instance, but inbound port 22 stays closed. You still need an SSH key, from a key pair or from EC2 Instance Connect, which pushes a public key that lasts 60 seconds.

The cost is visibility. Session Manager can record every keystroke of a shell session, but it carries SSH and port-forwarding sessions as bytes it can’t read, so it logs nothing inside them. EC2 Instance Connect Endpoint, launched on 13 June 2023, is the other option: real SSH from an endpoint inside the VPC, with no agent on the instance.

Session Manager alone is enough when the target runs SSM Agent: start-session reaches it directly, and no bastion is needed. A target that can’t run an agent, such as RDS, ElastiCache or a network appliance, needs a hop inside the VPC. Session Manager turns that hop into a private instance with no SSH, so the bastion stays and port 22 goes.

To copy files, use SSH over Session Manager and accept that the session isn’t logged. For an instance with no agent at all, use EC2 Instance Connect Endpoint. In every row, no instance in ledger-prod needs a public IP address or an inbound rule from the internet.