{"slug": "aws-security-ai-architecture-managed-mcp-custom-mcp-or-lambda-bedrock", "title": "AWS Security AI Architecture: Managed MCP, Custom MCP, or Lambda + Bedrock?", "summary": "A developer outlines three distinct architectural patterns for AI-assisted AWS security work: Lambda + Bedrock for scheduled production reporting, Custom MCP for analyst report review, and AWS Managed MCP for developer live triage. The post argues that mixing these workflows causes operational confusion and recommends separating them based on whether the task is interactive, report-based, or automated.", "body_md": "There is no single “correct” architecture for AI-assisted AWS security work.\n\nFor Security Hub, GuardDuty, ECR, and cloud security reporting, there are three valid patterns:\n\nAll three are correct.\n\nThey solve different problems.\n\nThe mistake is not choosing one over the other. The mistake is using the right technology in the wrong operating model.\n\nA 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.\n\nThe clean model is:\n\n```\nProduction reporting lane:\nLambda + boto3 + Bedrock + S3\n\nAnalyst report-review lane:\nCustom MCP + S3 reports + optional Bedrock analysis\n\nDeveloper / live triage lane:\nAWS Managed MCP + Claude Code / Codex + read-only IAM\n```\n\nThat separation removes most of the confusion.\n\nAWS security teams usually deal with three different workflows that look similar at first glance but are operationally different.\n\nA security engineer wants to ask:\n\n```\nShow me the current HIGH and CRITICAL Security Hub findings.\nExplain which ones are immediate risk.\nCheck GuardDuty or Inspector context.\nDraft remediation wording.\n```\n\nThis is interactive. The engineer is present. The assistant may need to call live AWS APIs.\n\nA weekly Security Hub or GuardDuty report already exists in S3.\n\nAn analyst wants to paste a finding and ask:\n\n```\nIs this finding already covered in the latest report?\nWhat evidence supports it?\nWhat owner action is needed?\nGive me Jira-ready wording.\n```\n\nThis is not live AWS investigation. This is analysis of approved report artifacts.\n\nThe organization needs a report every week, without a human sitting in front of Claude Code or Codex.\n\nThe system should:\n\n```\nCollect findings\nScore and sort them\nEnrich them\nGenerate Markdown/HTML/JSON/CSV\nStore the output in S3\nRun on schedule\nFallback safely if AI enrichment fails\n```\n\nThis is backend automation.\n\nThese three workflows should not use the same architecture.\n\nAWS Managed MCP, delivered through AWS Agent Toolkit, lets AI coding agents interact with AWS through the Model Context Protocol.\n\nAWS 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.\n\nThe architecture looks like this:\n\n```\nSecurity engineer\n        ↓\nClaude Code / Codex\n        ↓\nAWS Managed MCP Server\n        ↓\nRead-only AWS SSO profile / IAM role\n        ↓\nSecurity Hub / GuardDuty / Inspector / Config / CloudTrail\n        ↓\nLocal analysis output\n```\n\nThe key point:\n\nAWS Managed MCP is a live AWS access path for an AI assistant.\n\nThat can be very useful, but it must be controlled.\n\nUse AWS Managed MCP when the analyst or engineer needs live AWS context.\n\nGood examples:\n\n```\nRead current Security Hub findings.\nCheck current GuardDuty findings.\nSearch AWS documentation.\nReview AWS Config resource state.\nLook up CloudTrail events.\nAsk for remediation guidance while reviewing live AWS evidence.\nUse Claude Code or Codex during security tooling development.\n```\n\nSecurity Hub’s `GetFindings`\n\nAPI 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.\n\nChoose AWS Managed MCP when:\n\n```\nA human analyst is actively driving the session.\nThe task requires current AWS state.\nThe user is already working in Claude Code, Codex, Cursor, Kiro, or another MCP-capable client.\nThe organization can enforce read-only IAM, SSO, approval prompts, and audit logging.\nThe output is advisory, not automatically applied.\n```\n\nThis is a good design for a junior security engineer who needs help understanding findings but should not be allowed to modify AWS.\n\nThe minimum safe posture is:\n\n```\nDedicated read-only SSO permission set.\nNo administrator profile.\nNo long-lived access keys.\nExplicit deny for Security Hub, GuardDuty, IAM, S3, EC2, KMS, and Config write actions.\nTool approval enabled.\nScript execution denied or separately approved.\nNo secret or PII access.\nCloudTrail visibility.\nNegative-control test proving write actions fail.\n```\n\nAWS 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.\n\nThat means IAM is not optional. IAM is the control boundary.\n\nAWS Managed MCP is not the best engine for scheduled reporting.\n\nA weekly report should not require:\n\n```\nAn analyst session.\nA local MCP client.\nA laptop profile.\nA Claude Code/Codex session.\nManual approval of each tool call.\n```\n\nFor scheduled reporting, use Lambda.\n\nA custom MCP server is your own MCP service that exposes a narrow set of approved tools.\n\nIn this design, the MCP server does not query live Security Hub.\n\nIt reads only the security reports that your production reporting pipeline has already generated into S3.\n\nThe architecture looks like this:\n\n```\nAnalyst\n        ↓\nClaude Code / Codex\n        ↓\nCustom Report Analyst MCP Server\n        ↓\nRead-only S3 access\n        ↓\nGenerated Security Hub / GuardDuty reports\n        ↓\nOptional Bedrock analysis\n        ↓\nEvidence-bound response\n```\n\nThe MCP tools should be intentionally limited:\n\n```\nhealthcheck\nlist_available_reports\nread_report_excerpt\nsearch_reports\nanalyze_finding_against_reports\ngenerate_ticket_draft\n```\n\nThe MCP server should not expose:\n\n```\ncall_aws\nrun_script\nput_object\nupdate_finding\nbatch_update_findings\ncreate_ticket\nsend_slack\nassume_role\n```\n\nThis is the core security design.\n\nThe custom MCP server is not a general AWS assistant. It is a report analyst.\n\nUse custom MCP when the source of truth is an approved report artifact.\n\nGood examples:\n\n```\nAnalyze a pasted Security Hub finding against the latest weekly report.\nSearch generated GuardDuty reports for a finding ID.\nCompare a resource ARN against recent findings.\nGenerate Jira-ready remediation wording from existing report evidence.\nExplain whether a finding is immediate risk or backlog based on the report.\nCreate analyst notes without touching live AWS APIs.\n```\n\nThis is especially useful when the organization already has a strong reporting pipeline and wants AI-assisted review without giving the assistant broad AWS access.\n\nIf the task is:\n\n```\nRead the report and explain the finding.\n```\n\nthen the agent does not need live Security Hub access.\n\nIt only needs:\n\n```\ns3:GetObject\ns3:ListBucket\nkms:Decrypt, if the reports are encrypted with KMS\nbedrock:InvokeModel, if second-pass model analysis is used\n```\n\nThat is a much narrower trust boundary.\n\nThe analyst prompt can say:\n\n```\nUse only the report analyst MCP server.\nDo not call live AWS APIs.\nDo not update Security Hub.\nDo not create tickets.\nAnalyze this finding against the latest generated reports.\n```\n\nThis avoids a common failure mode: the AI assistant silently switching from “report analysis” to “live AWS investigation.”\n\nChoose custom MCP when:\n\n```\nReports already exist in S3.\nThe analyst should analyze approved artifacts, not live AWS state.\nYou want the smallest possible tool surface.\nYou want the same report evidence used across analysts.\nYou want the assistant to produce draft analysis, not operational changes.\nYou want to avoid broad AWS API exposure.\n```\n\nThis is the right pattern for security teams that already generate Security Hub or GuardDuty reports through a controlled pipeline.\n\nThe custom MCP server should run with a runtime role that can only:\n\n```\nList approved report prefixes.\nRead approved report objects.\nDecrypt report objects if needed.\nInvoke an approved Bedrock model if model-assisted analysis is enabled.\nWrite CloudWatch logs.\n```\n\nIt should explicitly deny:\n\n```\nSecurity Hub writes.\nGuardDuty writes.\nS3 writes to the report bucket.\nIAM changes.\nEC2 changes.\nKMS destructive actions.\nLambda invoke.\nSSM commands.\nECS Exec.\n```\n\nThe endpoint should require company authentication. Do not expose a public MCP endpoint with a long-lived shared token.\n\nA good production pattern is:\n\n```\nClaude Code signed in with a company account\n        +\nCompany SSO / OAuth / short-lived MCP bearer token\n        +\nCustom MCP endpoint\n        +\nRead-only report access\n```\n\nThe 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.\n\nThose are separate identities, and that separation is healthy.\n\nCustom MCP should not replace a backend reporting pipeline.\n\nIf the job is:\n\n```\nEvery Tuesday, collect all Security Hub findings, enrich them, and write reports to S3.\n```\n\nthen MCP is not the right primary engine.\n\nMCP is a tool interface for an agent. It is not a scheduler, state tracker, report renderer, or production batch engine by default.\n\nFor that, use Lambda or another backend compute service.\n\nThe Lambda + boto3 + Bedrock pattern is a backend automation pipeline.\n\nIn the reviewed implementation pattern, Lambda performs deterministic collection, scoring, filtering, enrichment, fallback handling, and report assembly.\n\nThe architecture looks like this:\n\n```\nEventBridge Scheduler\n        ↓\nLambda\n        ↓\nboto3 reads Security Hub and ECR\n        ↓\nBedrock Converse API enriches bounded batches\n        ↓\nLambda assembles final report deterministically\n        ↓\nS3 stores Markdown, HTML, JSON, SVG, and state files\n```\n\nThis is not MCP.\n\nThis is not an interactive agent.\n\nThis is a scheduled reporting system.\n\nAmazon Bedrock’s Converse API provides a consistent interface for sending messages to supported models, and the operation requires `bedrock:InvokeModel`\n\npermission.\n\nThat fits the Lambda model well: the function prepares bounded input, invokes the model, validates or falls back, and writes the final report.\n\nThe Lambda pattern is strong because it is deterministic around the model.\n\nA good production implementation does not ask the model to do everything.\n\nIt should use the model for bounded enrichment, while Lambda owns:\n\n```\nCollection\nFiltering\nScoring\nSorting\nDeduplication\nECR latest-image filtering\nReport structure\nFallback behavior\nS3 output\nState tracking\nSchedule\n```\n\nThat is the correct division of labor.\n\nThe model helps with language, explanation, remediation wording, and executive summarization.\n\nThe code controls the evidence pipeline.\n\nUse Lambda + boto3 + Bedrock when:\n\n```\nReports must run on a schedule.\nThe output must be consistent every week.\nNo analyst should be required to trigger the workflow.\nFindings need deterministic scoring and sorting.\nThe organization needs report history and burn-down trends.\nThe output must be stored centrally.\nThere must be fallback if AI enrichment fails.\n```\n\nThis is the right pattern for:\n\n```\nWeekly Security Hub executive reports.\nGuardDuty summary reports.\nECR vulnerability reporting.\nManager-facing HTML reports.\nDevOps remediation backlog generation.\nSecurity trend/burn-down reporting.\n```\n\nLambda has a clear production control model:\n\n```\nLambda execution role\n        ↓\nRead security findings\n        ↓\nInvoke Bedrock\n        ↓\nWrite reports to S3\n```\n\nThis is easy to audit.\n\nMCP would add unnecessary moving parts:\n\n```\nMCP client\nAgent session\nTool approval\nWorkstation profile\nPrompt/session state\nInteractive user dependency\n```\n\nThose are useful for human-led analysis. They are not useful for unattended weekly reporting.\n\nFor a production Lambda reporting job, enforce:\n\n```\nsecurityhub:GetFindings only for Security Hub read.\nECR read-only actions if ECR latest-image validation is required.\nbedrock:InvokeModel scoped to approved model or inference profile where possible.\ns3:PutObject only to approved report prefixes.\ns3:GetObject only for state/history files if needed.\nNo Security Hub write permissions.\nNo GuardDuty write permissions.\nNo IAM mutation.\nNo remediation actions.\nCloudWatch logging.\nS3 encryption and versioning.\nEventBridge schedule ownership.\nDeterministic fallback when Bedrock fails.\n```\n\nThe most important design rule:\n\nBedrock should enrich the report. It should not control the report pipeline.\n\nThe Lambda should be able to produce a safe deterministic report even if the model fails, times out, or returns malformed output.\n\nThe confusion usually comes from treating “AI security assistant” as one thing.\n\nIt is not one thing.\n\nThere are at least three jobs:\n\n```\nLive investigation\nReport analysis\nReport generation\n```\n\nEach job has a different control boundary.\n\n| Question | Best architecture |\n|---|---|\n| “What is currently in Security Hub?” | AWS Managed MCP |\n| “What does the latest generated report say about this finding?” | Custom MCP |\n| “Generate the weekly report every Tuesday.” | Lambda + boto3 + Bedrock |\n| “Help me review Terraform or AWS docs while coding.” | AWS Managed MCP |\n| “Analyze approved S3 report artifacts only.” | Custom MCP |\n| “Create manager-ready reports without human interaction.” | Lambda |\n\nThat is why all three are valid.\n\nThey are not competing solutions. They are lanes.\n\nUse this model to avoid confusion.\n\n```\nLane 1: Production reporting\nPurpose: Generate reports\nTechnology: Lambda + boto3 + Bedrock + S3\nTrigger: EventBridge schedule or controlled manual invoke\nOutput: Markdown, HTML, JSON, CSV, SVG, report state\nHuman role: Review report and act on findings\n\nLane 2: Report analyst\nPurpose: Analyze generated reports\nTechnology: Custom MCP\nTrigger: Analyst prompt in Claude Code or Codex\nOutput: Evidence-bound analysis and ticket wording\nHuman role: Paste finding, review answer, create ticket manually\n\nLane 3: Live AWS triage / developer assistant\nPurpose: Query live AWS context or docs\nTechnology: AWS Managed MCP / Agent Toolkit\nTrigger: Analyst or developer prompt\nOutput: Live read-only investigation notes, docs, code guidance\nHuman role: Approve tool calls and validate output\n```\n\nThis is the architecture I would use in a mature security program.\n\nUse:\n\n```\nAWS Managed MCP for live AWS read-only triage.\nCustom MCP for report analysis.\nLambda for scheduled reports.\n```\n\nClaude Code becomes the analyst interface. The MCP endpoint should be company-authenticated, preferably through OAuth, SSO, ZTNA, or short-lived tokens.\n\nUse the same pattern.\n\nCodex can be the MCP client for either:\n\n```\nAWS Managed MCP\nCustom Report Analyst MCP\n```\n\nBut 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.\n\nUse:\n\n```\nCustom MCP for report analysis.\nLambda for report generation.\n```\n\nAvoid requiring every analyst to configure AWS profiles locally.\n\nLet the MCP backend carry the read-only runtime role and company endpoint authentication.\n\nAWS Managed MCP becomes more attractive.\n\nUse it for live investigation, but keep write actions denied.\n\nDo not use AWS Managed MCP for live API calls.\n\nUse:\n\n```\nLambda generates approved reports.\nCustom MCP reads only approved report artifacts.\n```\n\nThis gives the AI assistant useful context without granting broad live AWS access.\n\nLambda + boto3 + Bedrock is the cleanest reporting engine.\n\nUse SAM, Terraform, or your internal platform pattern. Keep the reporting job deterministic and auditable.\n\nThe custom MCP server can run on EKS.\n\nBut 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.\n\nNo.\n\nMCP is the tool interface.\n\nThe model reasons.\n\nThe MCP server exposes tools.\n\nIAM and application code enforce permissions.\n\nThe backend system still matters.\n\nA bad MCP design can give the model too many hands.\n\nA good MCP design gives it only the tools it needs.\n\nFor example:\n\n```\nAWS Managed MCP:\nGood for live read-only AWS questions.\n\nCustom MCP:\nGood for reading approved S3 report artifacts.\n\nLambda:\nGood for scheduled collection and report generation.\n```\n\nDifferent tools. Different jobs.\n\nNot automatically.\n\nCustom MCP is safer only if it exposes fewer tools and has better boundaries.\n\nA custom MCP server with a generic `call_aws`\n\ntool can be riskier than AWS Managed MCP with strong IAM controls.\n\nA safe custom MCP server should be domain-specific:\n\n```\nRead this report.\nSearch this report.\nAnalyze this pasted finding against reports.\nGenerate ticket draft.\n```\n\nIt should not become a private version of the entire AWS API.\n\nThat is the wrong way to think about it.\n\nScheduled security reporting should be boring.\n\nBoring is good.\n\nA weekly executive report should not depend on an agent making fresh tool decisions every time. It should follow a known pipeline:\n\n```\nCollect\nNormalize\nScore\nSort\nEnrich\nValidate\nFallback\nRender\nStore\n```\n\nThe AI model can improve the wording and analysis, but the pipeline should remain deterministic.\n\nThat is a stronger architecture for production reporting.\n\n| Requirement | AWS Managed MCP | Custom MCP | Lambda + boto3 + Bedrock |\n|---|---|---|---|\n| Live AWS Security Hub triage | Strong | Weak unless it calls live AWS | Possible but not interactive |\n| Analyze generated S3 reports | Possible but too broad | Strong | Possible but not conversational |\n| Scheduled weekly report | Weak | Weak | Strong |\n| Read-only guardrails | IAM + tool approval | IAM + app tool design | IAM execution role |\n| No local AWS profile needed | Usually no | Yes | Yes |\n| Best user interface | Claude Code / Codex | Claude Code / Codex | S3/HTML/Slack/Jira after generation |\n| Best production automation | No | No | Yes |\n| Best analyst conversation | Yes | Yes | No |\n| Lowest live AWS API exposure | No | Yes | Medium, controlled by Lambda role |\n| Best audit story for scheduled reports | Medium | Medium | Strong |\n| Best audit story for report artifact analysis | Medium | Strong | Strong for generation, not interaction |\n\nFor a mature AWS security team, I would implement all three, but keep them separated.\n\n```\n1. Lambda + boto3 + Bedrock\n   Generates official weekly/daily security reports.\n\n2. Custom MCP\n   Lets analysts ask questions about those reports without querying live AWS.\n\n3. AWS Managed MCP\n   Lets approved engineers perform live read-only AWS triage and development support.\n```\n\nThe important rule:\n\n``` js\nDo not let the lanes blur.\n```\n\nProduction reporting should not depend on a chat session.\n\nReport analysis should not silently become live AWS querying.\n\nLive AWS querying should not perform write actions.\n\nDo not force one architecture to do all three jobs.\n\nThat is how security automation becomes confusing and risky.\n\nThe best architecture is not the most advanced one. It is the one with the clearest control boundary for the job.\n\n```\nEventBridge triggers Lambda.\nLambda collects Security Hub findings.\nLambda validates ECR latest-image findings.\nLambda invokes Bedrock in bounded batches.\nLambda assembles Markdown and HTML.\nLambda writes report artifacts to S3.\n```\n\nNo analyst is involved.\n\n```\nAnalyst opens Claude Code.\nAnalyst pastes a Security Hub finding.\nClaude Code calls custom MCP.\nCustom MCP reads latest S3 reports.\nCustom MCP returns evidence-bound analysis.\nAnalyst creates Jira ticket manually.\n```\n\nNo live Security Hub API call is needed.\n\n```\nEngineer opens Claude Code or Codex.\nEngineer uses AWS Managed MCP with read-only SSO profile.\nAgent searches AWS docs and checks live AWS state.\nEngineer validates and implements remediation through normal change control.\n```\n\nNo automatic remediation is approved.", "url": "https://wpnews.pro/news/aws-security-ai-architecture-managed-mcp-custom-mcp-or-lambda-bedrock", "canonical_source": "https://dev.to/mike_anderson_d01f52129fb/aws-security-ai-architecture-managed-mcp-custom-mcp-or-lambda-bedrock-10m7", "published_at": "2026-07-16 10:54:55+00:00", "updated_at": "2026-07-16 11:03:09.780065+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-infrastructure", "developer-tools", "ai-agents", "ai-products"], "entities": ["AWS", "Bedrock", "Lambda", "Security Hub", "GuardDuty", "Claude Code", "Codex", "Model Context Protocol"], "alternates": {"html": "https://wpnews.pro/news/aws-security-ai-architecture-managed-mcp-custom-mcp-or-lambda-bedrock", "markdown": "https://wpnews.pro/news/aws-security-ai-architecture-managed-mcp-custom-mcp-or-lambda-bedrock.md", "text": "https://wpnews.pro/news/aws-security-ai-architecture-managed-mcp-custom-mcp-or-lambda-bedrock.txt", "jsonld": "https://wpnews.pro/news/aws-security-ai-architecture-managed-mcp-custom-mcp-or-lambda-bedrock.jsonld"}}