AWS 026: Security, operations, and billing contacts for a personal AWS account
The problem
AWS may need to report suspected abuse, exposed credentials, an operational issue, or a payment problem. If all notices go to an abandoned inbox or one person ignores them, a small problem becomes an account incident.
Alternate contacts are an operational control, not administrative permission.
Final outcome
You will configure and verify the security, operations, and billing alternate contacts, separate them from the root mailbox where practical, and create a response matrix for each notice type.
Four different concepts
| Concept | Purpose |
|---|---|
| Primary account contact | legal and ownership contact associated with the account |
| Root email | root sign-in and recovery channel |
| Alternate contacts | where AWS sends billing, operations, or security communications |
| IAM permissions | what a signed-in principal can do through AWS APIs |
Adding someone as a security contact does not give that person Console access. Granting Console access does not automatically make that identity an alternate contact.
Plan the contact design
For a personal account, one person may perform several roles, but use addresses that are actively monitored and recoverable. Where possible:
- root email is dedicated to ownership and recovery;
- security contact reaches someone able to respond to compromise or abuse;
- operations contact reaches someone able to investigate availability and service events;
- billing contact reaches someone able to review charges and payment issues.
For a business, use controlled distribution lists rather than an employee's personal address. For a personal learning account, aliases can help classification, but they must deliver to a protected mailbox.
All relevant email accounts need strong passwords and MFA. Protecting AWS while leaving its recovery mailbox weak is incomplete.
Console procedure
Use the daily non-root identity if it has account-contact permissions. Use root only if the account setup requires it and no safer delegated path exists.
- Open the account menu in the upper-right corner.
- Choose Account.
- Find Alternate contacts.
- Choose Edit for Billing contact.
- Enter the monitored name, title, email, and telephone number.
- Repeat for Operations contact and Security contact.
- Review spelling, country code, delivery address, and ownership.
- Save each contact.
- Reload the page and confirm all three contact types display the intended redacted values.
AWS permits one alternate contact for each type. An alternate contact can be a distribution list and does not need to be an IAM principal.
Do not place passwords, access keys, account numbers, or incident detail in a contact-name field.
Permission boundary
The AWS Account Management API exposes operations such as GetAlternateContact and PutAlternateContact. The lesson does not use the CLI because local AWS CLI installation and authentication are taught later.
Minimum permission should match the task. A principal that only audits contacts needs read operations. A principal that changes them needs the specific update operation. It does not need broad administrator access merely to edit contact information.
In AWS Organizations, a management or delegated administrator account can centrally manage member-account contacts after required trusted access and organization settings are enabled. This personal standalone-account lesson does not create an organization.
Verification test
Do not wait for a real incident. Use controlled verification:
- Confirm each mailbox or alias can receive an ordinary test email.
- Confirm the named responder can access the mailbox with MFA.
- Confirm the telephone number is current.
- Ask the responder to identify the expected action for a sample AWS message.
- Store a quarterly review date.
Create:
mkdir -p "$HOME/nitwings-aws/evidence/aws-026"
Create contact-matrix.md:
| Contact | Monitored by | Review interval | Example notice | First action | Escalation |
|---|---|---|---|---|---|
| Security | quarterly | exposed key or abuse report | preserve notice, contain access, investigate | ||
| Operations | quarterly | service or account operation issue | identify workload and impact | ||
| Billing | quarterly | unusual charge or payment issue | inspect bill dimensions and payment state |
Use aliases or redaction in shared evidence.
Response expectations
Security notice
Preserve the original message and headers, confirm it points to legitimate AWS channels, inspect the AWS account directly rather than following an unexpected login link, contain exposed credentials or public resources, preserve CloudTrail and related evidence, and rotate only after identifying dependencies.
Operations notice
Identify affected service, Region, resource, time, and customer impact. Check AWS Health and internal monitoring. Do not assume an AWS notice proves the root cause of the application symptom.
Billing notice
Open Billing and Cost Management directly, inspect Bills and cost dimensions, confirm credits and payment status, and identify retained resources. A budget alert may be delayed and is not a final invoice.
Phishing and message safety
An AWS-looking email is not automatically authentic.
- Do not enter credentials after clicking an unexpected email link.
- Open the AWS Console from a known bookmark.
- Inspect sender, headers, URLs, and account context.
- Treat attachments and urgent telephone requests carefully.
- Never send a password, MFA code, secret key, or private key by email.
- Use official Support channels for sensitive coordination.
Security response must be fast without becoming careless.
Common failures
| Failure | Consequence | Correction |
|---|---|---|
| old personal email | notices are missed | update to controlled monitored address |
| same weak mailbox for everything | one compromise affects recovery and notices | separate and protect channels |
| contact assumed to have IAM access | response cannot enter account | document access and escalation separately |
| employee leaves | distribution stops | use role-based aliases and quarterly review |
| phishing message followed | credentials exposed | navigate directly and verify |
| screenshot shares phone and email | privacy leak | redact evidence |
Architecture and certification decisions
Operational excellence includes ownership and escalation, not only monitoring services. A multi-account organization should standardize contacts at account creation and audit drift. Security contacts need a tested path to incident evidence. Billing contacts need cost visibility but not necessarily workload-administration permission.
Least privilege can separate:
- who receives a notice;
- who can read account contacts;
- who can update them;
- who can investigate resources;
- who can approve a costly or destructive response.
Knowledge check
- Does a security contact receive IAM permissions?
- How many alternate contact categories exist?
- Why use a distribution list for a business?
- What is the safe way to respond to an unexpected AWS login link?
- Why test contact delivery before an incident?
Expected answers: no; three; continuity and shared ownership; open a known Console URL and verify there; untested contact data is not reliable.
Completion gate
Pass when all three alternate contacts are present and tested, the root mailbox remains protected, the matrix defines ownership and first actions, a quarterly review date exists, and shared evidence exposes no personal or account-sensitive data.
Retain the contacts and review them after any email, phone, or ownership change.