# AWS Security AI Architecture: Managed MCP, Custom MCP, or Lambda + Bedrock? > Source: > Published: 2026-07-16 10:54:55+00:00 There is no single “correct” architecture for AI-assisted AWS security work. For Security Hub, GuardDuty, ECR, and cloud security reporting, there are three valid patterns: All three are correct. They solve different problems. The mistake is not choosing one over the other. The mistake is using the right technology in the wrong operating model. A scheduled production report should not depend on an analyst’s laptop. A report-analysis assistant should not need broad live AWS API access. A developer investigating AWS findings interactively should not be forced to wait for a weekly Lambda job. The clean model is: ``` Production reporting lane: Lambda + boto3 + Bedrock + S3 Analyst report-review lane: Custom MCP + S3 reports + optional Bedrock analysis Developer / live triage lane: AWS Managed MCP + Claude Code / Codex + read-only IAM ``` That separation removes most of the confusion. AWS security teams usually deal with three different workflows that look similar at first glance but are operationally different. A security engineer wants to ask: ``` Show me the current HIGH and CRITICAL Security Hub findings. Explain which ones are immediate risk. Check GuardDuty or Inspector context. Draft remediation wording. ``` This is interactive. The engineer is present. The assistant may need to call live AWS APIs. A weekly Security Hub or GuardDuty report already exists in S3. An analyst wants to paste a finding and ask: ``` Is this finding already covered in the latest report? What evidence supports it? What owner action is needed? Give me Jira-ready wording. ``` This is not live AWS investigation. This is analysis of approved report artifacts. The organization needs a report every week, without a human sitting in front of Claude Code or Codex. The system should: ``` Collect findings Score and sort them Enrich them Generate Markdown/HTML/JSON/CSV Store the output in S3 Run on schedule Fallback safely if AI enrichment fails ``` This is backend automation. These three workflows should not use the same architecture. AWS Managed MCP, delivered through AWS Agent Toolkit, lets AI coding agents interact with AWS through the Model Context Protocol. AWS describes the AWS MCP Server as a managed remote MCP server that gives AI agents secure access to AWS through MCP. It can expose AWS API access, documentation search, curated skills, CloudWatch metrics, and IAM-based controls. It is designed to work with coding agents such as Claude Code and Codex. The architecture looks like this: ``` Security engineer ↓ Claude Code / Codex ↓ AWS Managed MCP Server ↓ Read-only AWS SSO profile / IAM role ↓ Security Hub / GuardDuty / Inspector / Config / CloudTrail ↓ Local analysis output ``` The key point: AWS Managed MCP is a live AWS access path for an AI assistant. That can be very useful, but it must be controlled. Use AWS Managed MCP when the analyst or engineer needs live AWS context. Good examples: ``` Read current Security Hub findings. Check current GuardDuty findings. Search AWS documentation. Review AWS Config resource state. Look up CloudTrail events. Ask for remediation guidance while reviewing live AWS evidence. Use Claude Code or Codex during security tooling development. ``` Security Hub’s `GetFindings` API returns findings matching specified criteria, and if cross-Region aggregation is enabled, calling it from the aggregation home Region can include findings from linked Regions. That makes it a strong fit for read-only triage when the IAM role is scoped correctly. Choose AWS Managed MCP when: ``` A human analyst is actively driving the session. The task requires current AWS state. The user is already working in Claude Code, Codex, Cursor, Kiro, or another MCP-capable client. The organization can enforce read-only IAM, SSO, approval prompts, and audit logging. The output is advisory, not automatically applied. ``` This is a good design for a junior security engineer who needs help understanding findings but should not be allowed to modify AWS. The minimum safe posture is: ``` Dedicated read-only SSO permission set. No administrator profile. No long-lived access keys. Explicit deny for Security Hub, GuardDuty, IAM, S3, EC2, KMS, and Config write actions. Tool approval enabled. Script execution denied or separately approved. No secret or PII access. CloudTrail visibility. Negative-control test proving write actions fail. ``` AWS Managed MCP is powerful because it can expose broad AWS capability. AWS notes that Agent Toolkit can allow agents to interact with AWS APIs, run sandboxed scripts, search AWS documentation, and apply enterprise controls through IAM context keys and CloudWatch metrics. That means IAM is not optional. IAM is the control boundary. AWS Managed MCP is not the best engine for scheduled reporting. A weekly report should not require: ``` An analyst session. A local MCP client. A laptop profile. A Claude Code/Codex session. Manual approval of each tool call. ``` For scheduled reporting, use Lambda. A custom MCP server is your own MCP service that exposes a narrow set of approved tools. In this design, the MCP server does not query live Security Hub. It reads only the security reports that your production reporting pipeline has already generated into S3. The architecture looks like this: ``` Analyst ↓ Claude Code / Codex ↓ Custom Report Analyst MCP Server ↓ Read-only S3 access ↓ Generated Security Hub / GuardDuty reports ↓ Optional Bedrock analysis ↓ Evidence-bound response ``` The MCP tools should be intentionally limited: ``` healthcheck list_available_reports read_report_excerpt search_reports analyze_finding_against_reports generate_ticket_draft ``` The MCP server should not expose: ``` call_aws run_script put_object update_finding batch_update_findings create_ticket send_slack assume_role ``` This is the core security design. The custom MCP server is not a general AWS assistant. It is a report analyst. Use custom MCP when the source of truth is an approved report artifact. Good examples: ``` Analyze a pasted Security Hub finding against the latest weekly report. Search generated GuardDuty reports for a finding ID. Compare a resource ARN against recent findings. Generate Jira-ready remediation wording from existing report evidence. Explain whether a finding is immediate risk or backlog based on the report. Create analyst notes without touching live AWS APIs. ``` This is especially useful when the organization already has a strong reporting pipeline and wants AI-assisted review without giving the assistant broad AWS access. If the task is: ``` Read the report and explain the finding. ``` then the agent does not need live Security Hub access. It only needs: ``` s3:GetObject s3:ListBucket kms:Decrypt, if the reports are encrypted with KMS bedrock:InvokeModel, if second-pass model analysis is used ``` That is a much narrower trust boundary. The analyst prompt can say: ``` Use only the report analyst MCP server. Do not call live AWS APIs. Do not update Security Hub. Do not create tickets. Analyze this finding against the latest generated reports. ``` This avoids a common failure mode: the AI assistant silently switching from “report analysis” to “live AWS investigation.” Choose custom MCP when: ``` Reports already exist in S3. The analyst should analyze approved artifacts, not live AWS state. You want the smallest possible tool surface. You want the same report evidence used across analysts. You want the assistant to produce draft analysis, not operational changes. You want to avoid broad AWS API exposure. ``` This is the right pattern for security teams that already generate Security Hub or GuardDuty reports through a controlled pipeline. The custom MCP server should run with a runtime role that can only: ``` List approved report prefixes. Read approved report objects. Decrypt report objects if needed. Invoke an approved Bedrock model if model-assisted analysis is enabled. Write CloudWatch logs. ``` It should explicitly deny: ``` Security Hub writes. GuardDuty writes. S3 writes to the report bucket. IAM changes. EC2 changes. KMS destructive actions. Lambda invoke. SSM commands. ECS Exec. ``` The endpoint should require company authentication. Do not expose a public MCP endpoint with a long-lived shared token. A good production pattern is: ``` Claude Code signed in with a company account + Company SSO / OAuth / short-lived MCP bearer token + Custom MCP endpoint + Read-only report access ``` The Claude or Codex account gives access to the AI client. The company token gives access to the MCP endpoint. The MCP runtime role gives access to the report bucket. Those are separate identities, and that separation is healthy. Custom MCP should not replace a backend reporting pipeline. If the job is: ``` Every Tuesday, collect all Security Hub findings, enrich them, and write reports to S3. ``` then MCP is not the right primary engine. MCP is a tool interface for an agent. It is not a scheduler, state tracker, report renderer, or production batch engine by default. For that, use Lambda or another backend compute service. The Lambda + boto3 + Bedrock pattern is a backend automation pipeline. In the reviewed implementation pattern, Lambda performs deterministic collection, scoring, filtering, enrichment, fallback handling, and report assembly. The architecture looks like this: ``` EventBridge Scheduler ↓ Lambda ↓ boto3 reads Security Hub and ECR ↓ Bedrock Converse API enriches bounded batches ↓ Lambda assembles final report deterministically ↓ S3 stores Markdown, HTML, JSON, SVG, and state files ``` This is not MCP. This is not an interactive agent. This is a scheduled reporting system. Amazon Bedrock’s Converse API provides a consistent interface for sending messages to supported models, and the operation requires `bedrock:InvokeModel` permission. That fits the Lambda model well: the function prepares bounded input, invokes the model, validates or falls back, and writes the final report. The Lambda pattern is strong because it is deterministic around the model. A good production implementation does not ask the model to do everything. It should use the model for bounded enrichment, while Lambda owns: ``` Collection Filtering Scoring Sorting Deduplication ECR latest-image filtering Report structure Fallback behavior S3 output State tracking Schedule ``` That is the correct division of labor. The model helps with language, explanation, remediation wording, and executive summarization. The code controls the evidence pipeline. Use Lambda + boto3 + Bedrock when: ``` Reports must run on a schedule. The output must be consistent every week. No analyst should be required to trigger the workflow. Findings need deterministic scoring and sorting. The organization needs report history and burn-down trends. The output must be stored centrally. There must be fallback if AI enrichment fails. ``` This is the right pattern for: ``` Weekly Security Hub executive reports. GuardDuty summary reports. ECR vulnerability reporting. Manager-facing HTML reports. DevOps remediation backlog generation. Security trend/burn-down reporting. ``` Lambda has a clear production control model: ``` Lambda execution role ↓ Read security findings ↓ Invoke Bedrock ↓ Write reports to S3 ``` This is easy to audit. MCP would add unnecessary moving parts: ``` MCP client Agent session Tool approval Workstation profile Prompt/session state Interactive user dependency ``` Those are useful for human-led analysis. They are not useful for unattended weekly reporting. For a production Lambda reporting job, enforce: ``` securityhub:GetFindings only for Security Hub read. ECR read-only actions if ECR latest-image validation is required. bedrock:InvokeModel scoped to approved model or inference profile where possible. s3:PutObject only to approved report prefixes. s3:GetObject only for state/history files if needed. No Security Hub write permissions. No GuardDuty write permissions. No IAM mutation. No remediation actions. CloudWatch logging. S3 encryption and versioning. EventBridge schedule ownership. Deterministic fallback when Bedrock fails. ``` The most important design rule: Bedrock should enrich the report. It should not control the report pipeline. The Lambda should be able to produce a safe deterministic report even if the model fails, times out, or returns malformed output. The confusion usually comes from treating “AI security assistant” as one thing. It is not one thing. There are at least three jobs: ``` Live investigation Report analysis Report generation ``` Each job has a different control boundary. | Question | Best architecture | |---|---| | “What is currently in Security Hub?” | AWS Managed MCP | | “What does the latest generated report say about this finding?” | Custom MCP | | “Generate the weekly report every Tuesday.” | Lambda + boto3 + Bedrock | | “Help me review Terraform or AWS docs while coding.” | AWS Managed MCP | | “Analyze approved S3 report artifacts only.” | Custom MCP | | “Create manager-ready reports without human interaction.” | Lambda | That is why all three are valid. They are not competing solutions. They are lanes. Use this model to avoid confusion. ``` Lane 1: Production reporting Purpose: Generate reports Technology: Lambda + boto3 + Bedrock + S3 Trigger: EventBridge schedule or controlled manual invoke Output: Markdown, HTML, JSON, CSV, SVG, report state Human role: Review report and act on findings Lane 2: Report analyst Purpose: Analyze generated reports Technology: Custom MCP Trigger: Analyst prompt in Claude Code or Codex Output: Evidence-bound analysis and ticket wording Human role: Paste finding, review answer, create ticket manually Lane 3: Live AWS triage / developer assistant Purpose: Query live AWS context or docs Technology: AWS Managed MCP / Agent Toolkit Trigger: Analyst or developer prompt Output: Live read-only investigation notes, docs, code guidance Human role: Approve tool calls and validate output ``` This is the architecture I would use in a mature security program. Use: ``` AWS Managed MCP for live AWS read-only triage. Custom MCP for report analysis. Lambda for scheduled reports. ``` Claude Code becomes the analyst interface. The MCP endpoint should be company-authenticated, preferably through OAuth, SSO, ZTNA, or short-lived tokens. Use the same pattern. Codex can be the MCP client for either: ``` AWS Managed MCP Custom Report Analyst MCP ``` But do not confuse the Codex account with the AWS identity. The AI account authenticates you to the tool. The MCP endpoint must still require company-side authorization. Use: ``` Custom MCP for report analysis. Lambda for report generation. ``` Avoid requiring every analyst to configure AWS profiles locally. Let the MCP backend carry the read-only runtime role and company endpoint authentication. AWS Managed MCP becomes more attractive. Use it for live investigation, but keep write actions denied. Do not use AWS Managed MCP for live API calls. Use: ``` Lambda generates approved reports. Custom MCP reads only approved report artifacts. ``` This gives the AI assistant useful context without granting broad live AWS access. Lambda + boto3 + Bedrock is the cleanest reporting engine. Use SAM, Terraform, or your internal platform pattern. Keep the reporting job deterministic and auditable. The custom MCP server can run on EKS. But do not choose EKS just because it is more advanced. For a small stateless MCP API, ECS Fargate or Lambda-style backend hosting is often simpler. EKS is appropriate when the organization already has hardened Kubernetes standards, ingress controls, pod identity, network policies, and platform ownership. No. MCP is the tool interface. The model reasons. The MCP server exposes tools. IAM and application code enforce permissions. The backend system still matters. A bad MCP design can give the model too many hands. A good MCP design gives it only the tools it needs. For example: ``` AWS Managed MCP: Good for live read-only AWS questions. Custom MCP: Good for reading approved S3 report artifacts. Lambda: Good for scheduled collection and report generation. ``` Different tools. Different jobs. Not automatically. Custom MCP is safer only if it exposes fewer tools and has better boundaries. A custom MCP server with a generic `call_aws` tool can be riskier than AWS Managed MCP with strong IAM controls. A safe custom MCP server should be domain-specific: ``` Read this report. Search this report. Analyze this pasted finding against reports. Generate ticket draft. ``` It should not become a private version of the entire AWS API. That is the wrong way to think about it. Scheduled security reporting should be boring. Boring is good. A weekly executive report should not depend on an agent making fresh tool decisions every time. It should follow a known pipeline: ``` Collect Normalize Score Sort Enrich Validate Fallback Render Store ``` The AI model can improve the wording and analysis, but the pipeline should remain deterministic. That is a stronger architecture for production reporting. | Requirement | AWS Managed MCP | Custom MCP | Lambda + boto3 + Bedrock | |---|---|---|---| | Live AWS Security Hub triage | Strong | Weak unless it calls live AWS | Possible but not interactive | | Analyze generated S3 reports | Possible but too broad | Strong | Possible but not conversational | | Scheduled weekly report | Weak | Weak | Strong | | Read-only guardrails | IAM + tool approval | IAM + app tool design | IAM execution role | | No local AWS profile needed | Usually no | Yes | Yes | | Best user interface | Claude Code / Codex | Claude Code / Codex | S3/HTML/Slack/Jira after generation | | Best production automation | No | No | Yes | | Best analyst conversation | Yes | Yes | No | | Lowest live AWS API exposure | No | Yes | Medium, controlled by Lambda role | | Best audit story for scheduled reports | Medium | Medium | Strong | | Best audit story for report artifact analysis | Medium | Strong | Strong for generation, not interaction | For a mature AWS security team, I would implement all three, but keep them separated. ``` 1. Lambda + boto3 + Bedrock Generates official weekly/daily security reports. 2. Custom MCP Lets analysts ask questions about those reports without querying live AWS. 3. AWS Managed MCP Lets approved engineers perform live read-only AWS triage and development support. ``` The important rule: ``` js Do not let the lanes blur. ``` Production reporting should not depend on a chat session. Report analysis should not silently become live AWS querying. Live AWS querying should not perform write actions. Do not force one architecture to do all three jobs. That is how security automation becomes confusing and risky. The best architecture is not the most advanced one. It is the one with the clearest control boundary for the job. ``` EventBridge triggers Lambda. Lambda collects Security Hub findings. Lambda validates ECR latest-image findings. Lambda invokes Bedrock in bounded batches. Lambda assembles Markdown and HTML. Lambda writes report artifacts to S3. ``` No analyst is involved. ``` Analyst opens Claude Code. Analyst pastes a Security Hub finding. Claude Code calls custom MCP. Custom MCP reads latest S3 reports. Custom MCP returns evidence-bound analysis. Analyst creates Jira ticket manually. ``` No live Security Hub API call is needed. ``` Engineer opens Claude Code or Codex. Engineer uses AWS Managed MCP with read-only SSO profile. Agent searches AWS docs and checks live AWS state. Engineer validates and implements remediation through normal change control. ``` No automatic remediation is approved.