Overview
Creation of a structured, reusable infrastructure cloud context enabling professionals with less environment familiarity to research, locate evidence and initiate operational and security analyses with greater autonomy, reducing dependency on tacit knowledge concentrated in a few individuals.
Context
In complex cloud environments, the knowledge needed to investigate a problem isn't only in the tool. You need to know which component generates a given log, where it's sent, where it's stored, which service should be queried, which regions and accounts are involved, which guardrails exist and which resource relationships need to be considered. For professionals less familiar with the architecture, discovering this path consumed more time than the analysis itself.
Challenge
Make tacit infrastructure knowledge accessible — logging paths, service relationships, guardrails, internal patterns — without relying on static documentation or point specialists. Build a context that AI tools could use to guide investigations aligned with the actual environment.
My role
- Reusable infrastructure context modeling: cloud resources, environments, regions, network components, Kubernetes architecture and security services
- Logging flow mapping: log origins, destinations, storage and query paths
- Guardrail documentation, resource relationships and internal platform patterns
- Context integration with AI assistants for investigation guidance
- Application in security investigations: WAF, VPC Flow Logs, resource and evidence source correlation
- Operational knowledge democratization for less experienced professionals
Architecture
The context combined architectural and operational environment information: cloud resources, environments, regions, network components, Kubernetes architecture, security services, logging flows, observability, logical log locations, service relationships, guardrails, internal patterns and common investigation paths. The AI used this context to guide queries and investigations more aligned with the actual environment.
Technical decisions
- Structured context as operational asset — not static documentation
- Logging path mapping as part of observability architecture
- Guardrails documented as operational knowledge, not AI-automated controls
- Knowledge democratization as an explicit initiative goal
- Context-guided investigation — not generic tool responses
Principles of safe use
AI assisted discovery, research, interpretation and investigation, but operational and security decisions continued to depend on human validation. Guardrails described in the context were not automatically applied by the AI — real guardrails continued to be enforced by IAM, SCPs, AWS Config, policies, pipelines and platform security controls.
Context sourced from controlled, verifiable technical sources. AI used as investigation support, not autonomous decision-making. Structured responses, evidence and human validation. No exposure of credentials, secrets or excessive permissions. Prompt, source and result logging for traceability.
Automation
The context was updated as infrastructure evolved, maintaining alignment with the actual environment. Investigation automation depended on the quality of the fed context — outdated data compromised guidance.
Engineering challenges
The differentiator wasn't just AI usage, but building a context that enabled the model to understand how the actual infrastructure was organized. For example: when investigating AWS WAF, the context knew the flow WAF → Logging → Kinesis Data Firehose → S3 → Athena, enabling investigation guidance aligned with that specific environment's flow. The same concept applied to VPC Flow Logs, connectivity, unexpected traffic and incident investigation.
Results
- Infrastructure knowledge made more accessible
- Reduced need to previously know all logging paths
- Greater autonomy for less experienced professionals in investigations
- Faster access to relevant evidence sources
- Consistent context for troubleshooting and security investigation