Prove AWS is working — first tool + proof field

1. Why “is it working?” is five questions

Operators collapse five failures into one sentence. The API never left a management event. The packet never accepted at the ENI. GuardDuty has been Current for an hour and nobody opened the finding. The CIS control is FAILED because Config is not recording the resource type. The 5xx alarm is INSUFFICIENT_DATA, not OK. Those are five first clicks.

The factory taught the hops: account, then SG versus NACL, implicit deny, WAF versus SG. This page is the night-shift desk for proof. You are already in the account — or you think you are — and someone is asking whether the control even works. You open the tool that is allowed to answer that question, then you quote one official field.

Hero · five cubes, one ticket

2. Mental model — five proof tools

Memorise five named objects before you click. Each tool is allowed to prove one thing. Over-claiming a field is how you ship a bad change at 02:00. The factory named the hop. This desk names the store.

3. Decision flow — ticket → first tool

Flowchart first. Do not open the IAM editor or the security-group inbound rule until a diamond says so. Account and Region still come from the factory: confirm them before the first lookup.

Path · pick the branch before the menu

4. How to choose — first tool + proof field

Print this next to the Management Console. If you cannot recite the proof field, you are not ready to change anything. Official paths only — docs.aws.amazon.com wording.

5. Runbook Side A → B → C

Side A proves the API and the packet. Side B proves the threat finding and the control evaluation. Side C proves the metric the user felt. On a messy Sev-2, do them in this order until a field lights up. Isolate (read-only) until the field is on the ticket. Change-control is a later drawer — that split is in the factory.

Side A — CloudTrail + Flow Logs (API, then packet)

1. Confirm account and Region, then open Event history

   Path: sign in to the AWS Management Console → open the CloudTrail console at https://console.aws.amazon.com/cloudtrail/ → in the navigation pane choose Event history. Official: Viewing recent management events with the console. The default filter is Read-only = false (write events). You may apply one attribute filter plus a time range. Clear the default if you also need Describe* / Get* management calls.

2. Filter Event name, then open the Event record

   Lookup attribute Event name, full value (CloudTrail cannot filter on a partial value). Examples: AssumeRole, ConsoleLogin, AuthorizeSecurityGroupIngress, PutBucketPolicy. Choose the event → scroll to Event record. Quote eventName, errorCode if present, and userIdentity (type, arn, accountId, principalId, userName or assumed-role session). Source: CloudTrail record contents; CloudTrail userIdentity element.

3. If the ticket is a packet, switch stores — do not stay in Event history

   Path: CloudWatch console at https://console.aws.amazon.com/cloudwatch/ → Logs → Log groups → select the group that receives the VPC flow log → Search log group (or open the ENI log stream). Official: Search flow log records. Flow records are space-delimited. Default format includes srcaddr dstaddr srcport dstport protocol … action log-status.

4. Read action + 5-tuple, not the SG screenshot

   Filter pattern (default format): [version, accountid, interfaceid, srcaddr, dstaddr, srcport, dstport, protocol, packets, bytes, start, end, action, logstatus]. Narrow with values, e.g. dstport = 443 and action = REJECT. Quote ACCEPT or REJECT plus the five fields. action is the evidence word. REJECT means SG or NACL (or a closed connection) dropped it — it does not name the rule number. Source: Flow log records — available fields.

Side B — GuardDuty + Security Hub / Config (threat, then control)

1. Open Findings, not the detector settings

   Path: GuardDuty console at https://console.aws.amazon.com/guardduty/ → left navigation Findings. Default sort is Last seen descending. Status menu = Current (not Archived). Official: Viewing generated findings in GuardDuty console. Choose the finding Title to open the details panel.

2. Quote Finding type before you contain or suppress

   Overview fields: Finding type, Account ID, Severity (Critical / High / Medium / Low), Resource ID, Count, Created at, Updated at. The type is a formatted string such as UnauthorizedAccess:IAMUser/MaliciousIPCaller.Custom or CredentialAccess:IAMUser/AnomalousBehavior. That string is the ticket. Contain the principal (Side A CloudTrail for the same window). Do not archive from Slack text. Source: Finding details; GuardDuty finding types.

3. If the ticket is “is the control on?”, switch to Hub or Config

   Security Hub CSPM: https://console.aws.amazon.com/securityhub/ → Findings, or Controls, or Security standards → View results. Quote Compliance.Status: PASSED, FAILED, WARNING, NOT_AVAILABLE. Config: https://console.aws.amazon.com/config/home → Rules. Quote the rule name and ComplianceType: COMPLIANT, NON_COMPLIANT, INSUFFICIENT_DATA. A rule that exists is not an evaluation.

4. Treat WARNING / INSUFFICIENT_DATA as a recording problem, not a pass

   Hub WARNING often means AWS Config resource recording is not on for that type. Config cannot evaluate a type it is not recording (example: cloudtrail-enabled with trail recording off). Official: you must record AWS::Config::ResourceCompliance for accurate compliance. Do not tell the auditor “green” from a WARNING row.

Path:            Config console → Rules
Rule name:       s3-bucket-server-side-encryption-enabled
Quote:           ComplianceType = NON_COMPLIANT
Resource:        AWS::S3::Bucket lab-app-uploads
If INSUFFICIENT_DATA: recording / first evaluation — not a pass
Prerequisite:    record AWS::Config::ResourceCompliance

Side C — CloudWatch metric + alarm (the path the user felt)

1. Open All alarms, not a random dashboard tile

   Path: CloudWatch console → Alarms → All alarms. Official create/view path uses this pair (Create a CloudWatch alarm based on a static threshold). Filter by state if the ticket says “nothing fired.” Choose the alarm name.

2. Quote StateValue and MetricName together

   Metric alarm states: OK (within threshold), ALARM (outside threshold), INSUFFICIENT_DATA (just started, metric missing, or not enough points). Also quote MetricName, namespace, dimensions (LoadBalancer, TargetGroup), Statistic, Period, Evaluation Periods, Datapoints to Alarm. Source: Alarm evaluation.

3. If the alarm is INSUFFICIENT_DATA, prove the metric exists

   Path: CloudWatch → Metrics → All metrics. Metrics with no new datapoints for two weeks do not appear in Browse. An alarm that never leaves INSUFFICIENT_DATA is not a healthy control — the metric is missing, the dimension is wrong, or the period is longer than the incident. Do not close “AWS is fine” from a grey tile.

6. Five tickets as full stories

These five land every quarter. Memorise first tool + proof field. Times, ARNs, and IPs below are lab-only (account 123456789012, Region us-east-1, RFC 5737 203.0.113.88).

Journey · one REJECT is the ticket

AWEVD-01 — Prove the API (CloudTrail)

01:42 · P2. Pipeline red after last night’s IAM ship. L1 already drafted AdministratorAccess “to test.” Screenshot of the CodeBuild log says AccessDenied, no JSON.

First tool: CloudTrail Event history, this Region. Lookup attribute Event name = AssumeRole. Time range = the UTC window on the ticket. One attribute plus time — that is the official limit.

Proof field: Event record eventName = AssumeRole, errorCode = AccessDenied, userIdentity.type = IAMUser, userIdentity.userName = cicd-bot, userIdentity.accountId = 123456789012. That triple is the ticket. The factory then names which hop denied (identity policy, trust policy, SCP, permissions boundary). This desk only proves the API fired and failed.

AWEVD-02 — Prove the packet (VPC Flow Logs)

02:05 · P2. Partner on 203.0.113.88 cannot reach the ALB. Internal 10/8 works. Network wants 0.0.0.0/0 on 443 “for five minutes.”

First tool: CloudWatch Logs → Log groups → /vpc/flow → Search log group. Filter default-format fields with dstport = 443. Confirm the ENI is the ALB’s, not a random instance.

Proof field: 10.0.8.22 → 10.0.9.10:443 proto 6 ACCEPT; 203.0.113.88 → 10.0.9.10:443 proto 6 REJECT. That pair is the ticket. Next hop (factory): read the SG source, then the NACL if SG looks right and the client still hangs. Change-control, if approved: /32 + Description, never 0.0.0.0/0.

AWEVD-03 — Prove the finding type (GuardDuty)

02:20 · P1. Slack paste of a High finding. Someone wants the detector paused “until we know.” Someone else wants the WAF web ACL deleted.

First tool: GuardDuty Findings, Status = Current. Open the Title. Do not start from Archived. Do not start from a forwarded email that lost the type string.

Proof field: Finding type = UnauthorizedAccess:IAMUser/MaliciousIPCaller.Custom, Severity High, Resource = AccessKey / cicd-bot, Count 4, Last seen 01:41 UTC. That type is the ticket. Next: Side A CloudTrail for the same principal and window (ConsoleLogin, AssumeRole, CreateAccessKey). Isolate the key. A finding is a lead — official GuardDuty docs treat it as something to review, not as a change-control approval.

AWEVD-04 — Prove the control (Security Hub / Config)

02:40 · P3. Auditor on the bridge: “You said S3 encryption is on. Prove the control is working.” L1 pasted the Config rule name. No evaluation.

First tool: Security Hub Controls (or Security standards → View results) for the control, or Config Rules for s3-bucket-server-side-encryption-enabled. Open the resource lab-app-uploads.

Proof field: Hub Compliance.Status = FAILED (control status Failed) on arn:aws:s3:::lab-app-uploads, or Config ComplianceType = NON_COMPLIANT. PASSED / COMPLIANT is the only close that the encryption check is working for that bucket. WARNING or INSUFFICIENT_DATA means you cannot see — usually recording. “The rule is enabled” is not an evaluation.

AWEVD-05 — Prove the metric (CloudWatch)

03:00 · P2. Checkout 5xx. Chat typed Sev-1 and “rebuild the ALB.” Flow Logs already ACCEPT the client 5-tuple. CloudTrail is quiet.

First tool: CloudWatch Alarms → All alarms → lab-alb-5xx. Then the metric graph for HTTPCode_Target_5XX_Count.

Proof field: StateValue = ALARM, MetricName = HTTPCode_Target_5XX_Count, Sum > 10 for 3 of 3 sixty-second periods, dimension LoadBalancer = app/lab-alb/0lab. If the alarm is INSUFFICIENT_DATA, the control is not working — the metric never arrived. That is a metric/dimension ticket, not a security-group ticket.

7. Traps + close-the-ticket proof

Proof · named field, then Closed

Sources

• AWS CloudTrail User Guide — Viewing recent management events with the console (Event history; Lookup attributes; Read-only default; 90 days)
• AWS CloudTrail User Guide — Working with CloudTrail event history
• AWS CloudTrail User Guide — CloudTrail record contents (eventName, errorCode, userIdentity, eventTime)
• AWS CloudTrail User Guide — CloudTrail userIdentity element
• AWS CloudTrail User Guide — Understanding CloudTrail events (management vs data events; Event history does not show data events)
• Amazon VPC User Guide — Logging IP traffic using VPC Flow Logs
• Amazon VPC User Guide — Flow log records (action ACCEPT / REJECT; 5-tuple fields)
• Amazon VPC User Guide — Search flow log records (CloudWatch Logs → Log groups → Search log group)
• Amazon VPC User Guide — Publish flow logs to CloudWatch Logs
• Amazon GuardDuty User Guide — Viewing generated findings in GuardDuty console (Findings; Current / Archived)
• Amazon GuardDuty User Guide — Finding details (Finding type, Severity, Resource, Count)
• Amazon GuardDuty User Guide — GuardDuty finding types
• Amazon GuardDuty User Guide — Severity levels of GuardDuty findings
• AWS Security Hub User Guide — Evaluating compliance status and control status (Compliance.Status PASSED / FAILED / WARNING / NOT_AVAILABLE)
• AWS Security Hub User Guide — Reviewing finding details and history (Findings / Controls / Security standards)
• AWS Security Hub User Guide — Reviewing the details of a security standard (Security standards → View results)
• AWS Config Developer Guide — Viewing details and compliance information for your AWS Config rules (Rules page)
• AWS Config Developer Guide — Viewing compliance information and evaluation results
• Amazon CloudWatch User Guide — Alarm evaluation (OK / ALARM / INSUFFICIENT_DATA; Period; Datapoints to Alarm)
• Amazon CloudWatch User Guide — Using Amazon CloudWatch alarms
• Amazon CloudWatch User Guide — Create a CloudWatch alarm based on a static threshold (Alarms → All alarms)

Related: Blog 1 · AWS Security factory · Security groups vs NACLs · IAM security · GuardDuty + Security Hub · Security Hub CSPM findings · AWS Security practice dashboard