Building a Private AI Reporting Pipeline from AWS Security Hub to Client-Ready HTML
- Authors
- Name
- Nino
- Occupation
- Senior Tech Editor
Modern cloud security posture management (CSPM) produces an overwhelming volume of raw telemetry. AWS Security Hub aggregates findings from Amazon GuardDuty, Amazon Inspector, and IAM Access Analyzer into the standardized AWS Security Finding Format (ASFF). While ASFF provides excellent source fidelity for audit trails, it presents a significant reporting challenge: raw findings are cluttered with internal Amazon Resource Names (ARNs), account IDs, verbose technical evidence, and unstructured remediation guidance.
Transforming this raw JSON payload into an executive-level, client-facing HTML document typically consumes hours of manual engineering effort every week. Attempting to solve this solely by passing raw enterprise vulnerability telemetry directly to cloud-hosted AI APIs introduces data boundary concerns and non-deterministic scoring risks. For teams utilizing scalable model infrastructure via n1n.ai or AWS Bedrock, a structured hybrid architecture provides the optimal balance of privacy, performance, and narrative clarity.
This guide outlines a battle-tested, two-stage private AI reporting architecture deployed in the AWS Singapore region (ap-southeast-1). The pipeline combines deterministic mathematical scoring, bounded cloud-hosted LLM summaries (via Bedrock or n1n.ai), and a zero-egress offline ARM64 EC2 local transformer host to generate client-ready security artifacts.
The Dual-Artifact Architecture Pattern
A common mistake in cloud security automation is attempting to force a single report artifact to serve both compliance auditors and C-suite executives. Auditors require unedited source telemetry, complete ARNs, and raw JSON parameters. Clients and executives demand visual hierarchy, prioritized remediation candidates, week-over-week differential metrics, and clean typography.
Requirement Matrix: Evidence Artifact vs. Client Report
| Feature / Requirement | Stage 1: AWS Source Evidence Artifact | Stage 2: Post-Processed Client HTML |
|---|---|---|
| Primary Target Audience | Internal Security Engineers & Auditors | Executive Stakeholders & External Clients |
| Source Fidelity | 100% Unedited Raw Telemetry (ASFF) | Aggregated & Filtered Summaries |
| Resource Identification | Full AWS ARNs, Account IDs, MACs | Masked / Anonymized Strategic References |
| Finding Comparison | Snapshot-in-time snapshot | Delta-tracked (New, Persistent, Resolved) |
| Interactivity | Basic static tables | Sortable tables, interactive client-side filters |
| Data Boundaries | AWS Account Boundary | Air-gapped / Local Processing Boundary |
By splitting the pipeline into two discrete stages, you prevent report renderers from maintaining direct IAM access to your live security databases while preserving full auditability.
+---------------------------------------------------------------------------------+
| Stage 1: AWS Cloud Boundary (ap-southeast-1) |
| |
| GuardDuty + Inspector + Security Hub CSPM |
| │ |
| ▼ |
| EventBridge Weekly Cron -> AWS Lambda (Scoring Engine) |
| │ |
| Deterministic Logic + Bounded Narrative (Bedrock / n1n.ai API) |
| │ |
| ▼ |
| S3 Bucket (SSE-KMS Encrypted Raw & Evidence MD) |
+---------------------------------------------------------------------------------+
│
S3 Read-Only (Restricted IAM)
│
▼
+---------------------------------------------------------------------------------+
| Stage 2: Private Isolated Processing Host (ARM64 EC2) |
| |
| EC2 (t4g.2xlarge ARM64) <- Model: Qwen2.5 7B GGUF (llama-cpp-python) |
| (Zero Network Egress / Encrypted EBS Volume / No Internet Access) |
| │ |
| ▼ |
| Client-Ready Offline HTML Security Report |
+---------------------------------------------------------------------------------+
Stage 1: AWS Architecture & Deterministic Scoring Engine
The first stage executes inside an AWS Lambda function triggered on a weekly EventBridge cron schedule. It collects active findings, enforces deterministic priority scoring, queries Bedrock or n1n.ai for constrained narrative summaries, tracks delta state against prior weeks, and writes formatted Markdown evidence to Amazon S3.
Step 1: S3 Bucket Hierarchy Setup
Create a dedicated KMS-encrypted S3 bucket in ap-southeast-1 enforcing Block Public Access:
aws s3api create-bucket \
--bucket example-security-reporting-ap-southeast-1 \
--region ap-southeast-1 \
--create-bucket-configuration LocationConstraint=ap-southeast-1
aws s3api put-public-access-block \
--bucket example-security-reporting-ap-southeast-1 \
--public-access-block-configuration "BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true"
Organize objects into a structured lifecycle scheme:
s3://example-security-reporting-ap-southeast-1/
├── weekly/raw/2026-09-07/weekly-security-summary.md
├── weekly/evidence-html/2026-09-07/security-evidence.html
├── weekly/client-html/2026-09-07/client-security-report.html
└── weekly/state/2026-09-07/findings-manifest.json
Step 2: Deterministic Scoring Implementation
AI models must never be permitted to dynamically alter risk severity or suppress vulnerabilities without governance. Severity scoring must remain hardcoded and reviewable.
The following Python logic illustrates how the Lambda function evaluates ASFF telemetry, factoring in asset criticality and exposure modifiers:
# scoring_engine.py
SEVERITY_BASE = \{
"CRITICAL": 100,
"HIGH": 75,
"MEDIUM": 45,
"LOW": 20,
"INFORMATIONAL": 5,
\}
def calculate_priority_score(finding: dict, asset_criticality: int = 0, exposure_modifier: int = 0) -> int:
"""
Calculates an auditable, deterministic priority score.
- asset_criticality: Value 0–25 derived from approved AWS resource tags (e.g., Environment=Production).
- exposure_modifier: Value 0–20 based on public accessibility indicators.
"""
raw_severity = finding.get("Severity