Cloud Security Architecture Questions

Direct answer

Defense-in-depth for managed cloud-native services (a managed database, serverless functions, a managed cache) means the four layers, network, identity, compute, and data, still all apply, but each one is expressed differently than it would be for a self-managed server, since the provider has already absorbed part of the compute layer's traditional responsibility; the value of the remaining layers is precisely that they compensate for each other when one fails, not that any single layer is expected to be perfect.

Structured elaboration

Network layer. For a managed database: private subnet placement with no public endpoint, security-group scoping to only the application tier. For serverless functions: no network perimeter in the traditional sense, but Virtual Private Cloud (VPC) endpoints for the specific managed services the function depends on, and egress restricted to only what the function's logic actually requires. For a managed cache: identical private-placement and security-group scoping to the managed database's pattern, since a cache holding session data or partially-processed sensitive data deserves the same network isolation as a database, a control frequently under-applied because caches are perceived as lower-stakes than the primary data store.

Identity layer. For a managed database: identity and access management (IAM)-based database authentication (short-lived, auto-rotated tokens) rather than a static database password, and database-native least-privilege roles scoped per application. For serverless functions: a dedicated, narrowly-scoped execution role per function, never a shared role across multiple functions. For a managed cache: an authentication token or IAM-based access policy scoped to the specific application that legitimately reads and writes it, since a cache left with default or no authentication is a common, underestimated gap precisely because caches are often assumed to hold only "non-sensitive, disposable" data.

Compute layer. For a managed database: the provider handles the underlying host and engine patching entirely, so the compute layer's remaining customer responsibility is narrow but real, confirming the maintenance window and patch-application settings match the organization's own risk tolerance (deferring critical security patches too long, or accepting the provider's default schedule without review). For serverless functions: the compute layer's customer responsibility is the function's own code and its dependency tree, since the provider owns the execution environment. For a managed cache: similar to the database, the provider owns host and engine patching, with customer responsibility narrowed to configuration (eviction policy, persistence settings) that can have security implications (data lingering longer than intended if eviction is misconfigured).

Data layer. Encryption at rest with a customer-managed key (for the database and, where the cache offering supports at-rest persistence, the cache); encryption in transit enforced, not merely available, for connections to all three; and, specific to caches, a data-classification decision about whether the cache should ever hold genuinely sensitive data at all, since a cache's original design intent (fast, ephemeral, ideally non-critical data) is often violated in practice as an application evolves to cache something more sensitive than its original design assumed.

How the layers compensate for each other's failures

If the network layer fails (a security group accidentally widened, exposing the managed database's private endpoint to a broader range than intended), the identity layer's IAM-based authentication and narrow database role still require a valid, short-lived credential scoped to specific actions, meaning the network exposure alone does not grant an attacker meaningful access. If the identity layer fails (an overly broad execution role attached to a serverless function), the network layer's egress restriction still limits what that broadly-permissioned function can actually reach externally, even if its internal permissions are wider than ideal. If the compute layer fails (an unpatched vulnerability in a function's dependency is exploited), the data layer's encryption and the identity layer's narrow role together limit what the resulting compromise can actually read or exfiltrate, since the attacker inherits the function's own narrow scope, not broader account access.

Worked example

A managed cache is used to store partially-processed customer session data, more sensitive than the cache's original "just performance optimization" design intent, a drift that happened gradually as the application evolved. The network layer places it in a private subnet with a security group scoped to the specific application tier. The identity layer requires an authentication token scoped to that application. The data layer enforces encryption in transit. When a misconfiguration accidentally widens the cache's security group to a broader internal range (a network-layer failure), the identity layer's authentication requirement still blocks any of the newly-and-unintentionally-reachable internal services from actually reading cache contents, since none of them hold the required authentication token, illustrating the compensating relationship directly: the network-layer mistake did not become a data breach because the identity layer independently held.

Trade-offs and pitfalls

• Caches are the service most likely to be under-secured relative to their actual data sensitivity, precisely because their original design intent (fast, disposable, non-critical) creates an assumption that ages poorly as an application evolves to store more sensitive data in them over time. The worked example's session-data drift is a common, realistic pattern, not a contrived edge case, and it argues for periodically re-evaluating what a cache actually holds against its original security configuration, not assuming the initial classification remains correct indefinitely.
• The compensating-layers property only holds if each layer is genuinely independently configured, not derived from or dependent on another layer's own settings; a design where the identity layer's access decision itself depends on the network layer already having correctly restricted reachability (rather than being independently enforced regardless of network position) would not have caught the worked example's network-layer failure the way the independent identity check did.
• The narrower customer responsibility on the compute layer for managed services (patch scheduling and window review, rather than patching itself) is easy to treat as "nothing to do here," when the maintenance-window decision itself carries real risk if a critical patch is deferred too long relative to the organization's actual risk tolerance. A managed service reducing the compute-layer workload does not reduce it to zero.
• A common wrong turn is assuming that because the provider manages more of the compute layer for these services, fewer of the four layers need customer attention overall; the worked example shows the opposite is true in practice, all four layers still matter, they are simply expressed through different, service-specific mechanisms than they would be for a self-managed server.

Direct answer

Across Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS), the shared responsibility line moves in one direction only, toward the provider, as the service becomes more managed, but the customer's core responsibility, identity, access control, and what data goes into the service, never fully disappears at any point on that spectrum, which is exactly what makes the gray-area cases (not the clear-cut ones) the actual place organizations get this wrong.

Structured elaboration

IaaS, example: Amazon Elastic Compute Cloud (EC2). Provider responsibility: physical datacenters, the hypervisor, the host's own network infrastructure. Customer responsibility: guest operating system patching, network configuration (security groups, subnet placement), identity and access management (IAM) for who can access the instance, and everything running on top of the OS, since the customer chose and controls essentially the entire software stack above the hypervisor.

PaaS, example: Amazon Relational Database Service (RDS). Provider responsibility: the physical infrastructure, the hypervisor, and now also the database engine's own patching and the underlying operating system, since the customer never has direct OS-level access to a managed database instance. Customer responsibility: network access configuration (is the instance public, what security group scopes reachability), authentication method and credential management, encryption configuration, and the data itself, a narrower slice than IaaS but still real and still the customer's to get right.

SaaS, example: Gmail (as a representative business-email SaaS product). Provider responsibility: essentially the entire technical stack, the application itself, its infrastructure, its own security patching, with the customer having no direct infrastructure-level control at all. Customer responsibility: narrows to identity and access configuration (who has an account, multi-factor authentication (MFA) enforcement, single sign-on (SSO) integration), data governance (what data users choose to put into the product, sharing and retention settings the product exposes), and user behavior (a phished user credential is still the customer's problem to prevent and respond to, regardless of how secure the underlying SaaS platform itself is).

Common gray-area responsibilities

Encryption key management on a managed service. Whether the customer is responsible for key management depends entirely on whether they opted into a customer-managed key or accepted the provider's default key; this is nominally the customer's choice, but many organizations never make it deliberately, defaulting to whatever the console's default happens to be, which means the actual responsibility boundary in practice is often determined by an unexamined default rather than a considered decision.

Default configuration values. When a managed service is deployed with an insecure default (a database provisioned with a public endpoint enabled by default, for instance, in certain configurations), the provider technically offered the configuration option, but the customer is universally held accountable for the actual deployed state in every compliance framework and every real-world incident response; "the default was insecure" is not a defense, which is a gray area in principle but a settled question in practice, worth stating plainly because it is so commonly misunderstood.

Documenting responsibility boundaries for a new cloud service onboarding

Before onboarding any new managed service, produce a written responsibility matrix specific to that service (not a generic, one-size-fits-all shared-responsibility document), explicitly naming which of the customer's own controls apply (network configuration, IAM, encryption key choice, data classification) and confirming a specific, named owner for each; review the provider's own documented responsibility boundary for that specific service, since it varies by service even within one provider, rather than assuming it matches a different service the organization has already onboarded; and require this documented matrix as a gate in the onboarding process itself, not an afterthought produced once the service is already in production use.

Worked example

An organization onboarding Gmail as its business email platform for the first time documents its responsibility matrix explicitly: MFA enforcement and SSO integration are named, owned controls (assigned to the identity team), data-loss-prevention policy configuration for what leaves the organization via email is a named, owned control (assigned to the security team), and user security-awareness training for phishing resistance is a named, owned control (assigned to the security-awareness program), each with a specific owner rather than an implicit assumption that "Google handles security." Six months later, a user falls for a phishing email and enters their credentials on a fake login page; because MFA enforcement was a documented, owned control that had actually been implemented, the stolen password alone is insufficient for the attacker to access the account, the concrete payoff of having named and implemented that specific customer-side responsibility rather than assuming the SaaS provider's own security covered it.

Trade-offs and pitfalls

• "It's SaaS, the provider handles security" is the single most common and most consequential misunderstanding of this entire model, and it is exactly backwards about where the narrowing happens: the technical infrastructure responsibility narrows toward the provider as services become more managed, but the identity, access, and data-governance responsibility never narrows to zero, and SaaS is precisely where that narrower-but-real slice matters most, since it is often the only thing standing between a phished credential and an actual breach.
• The encryption-key-management gray area is a case where "the customer could have chosen differently" is technically true and practically misleading, since most organizations never make an active, considered choice about it; treating this as a settled customer responsibility without acknowledging how often it is an unexamined default is an honest gap worth naming rather than glossing over.
• A generic, one-size-fits-all shared-responsibility document produced once and reused for every new service onboarding misses that the actual boundary varies by specific service, even within the same provider; the worked example's Gmail-specific matrix would look meaningfully different from an EC2-specific or RDS-specific one, and treating them as interchangeable templates undermines the entire point of documenting the boundary explicitly.
• A responsibility matrix that names an owner on paper but is never actually implemented (MFA "assigned" to the identity team but never actually enforced, for instance) provides no real protection, only the appearance of it; the worked example's payoff depends specifically on the named control having been genuinely implemented, not merely documented as someone's responsibility.

Direct answer

A serverless web application built on an API Gateway, Lambda/Cloud Functions, a managed NoSQL store (DynamoDB/Cloud Datastore), and object storage has five threat categories worth enumerating explicitly (authentication, authorization, data exfiltration, injection, and event source spoofing), and the highest-leverage mitigations concentrate on the boundary where each event source hands control to a function, since that boundary is where this architecture's trust decisions actually get made.

Structured elaboration

flowchart LR
    Client(["Client"]) --> APIGW["API Gateway"]
    APIGW --> AuthFn["Auth-checking Lambda / authorizer"]
    AuthFn --> BizFn["Business-logic Lambda"]
    BizFn --> DB[("DynamoDB / Cloud Datastore")]
    Client -->|"file upload"| S3[("S3 / Cloud Storage")]
    S3 -->|"object-created event"| ProcFn["Processing Lambda"]
    ProcFn --> DB

Data flow. A client calls the API Gateway, which routes to an authorizer function confirming the caller's identity and claims before forwarding to a business-logic function that reads and writes the managed data store; separately, a client uploads a file directly to object storage, which triggers a processing function through an object-created event, writing results back to the same data store.

Authentication threats. Token theft or replay (a stolen JSON Web Token (JWT) or API key reused by an attacker), and a misconfigured authorizer that accepts a token without fully validating its signature, issuer, and expiration; mitigation: short-lived tokens, full signature and claims validation on every request (not cached or skipped for performance), and token binding where the identity provider supports it.

Authorization threats. A business-logic function trusting a client-supplied identifier (a user ID passed in the request body, rather than derived from the validated token) to decide what data to return, letting an attacker request another user's data by simply changing the identifier; mitigation: authorization decisions must derive the acting identity from the validated token itself, never from a client-controlled field, and the data store's own access pattern should be scoped so a function can only query rows matching the authenticated caller's own identity.

Data exfiltration threats. An over-broad execution role on the business-logic or processing function allowing it to read more of the data store or object storage than its actual function requires, so a compromise of that one function (through any other vector) yields broader data access than necessary; mitigation: per-function least-privilege roles scoped to the specific table, partition key range, or bucket prefix each function actually needs.

Injection threats. A managed NoSQL data store is not immune to injection-style attacks: unsanitized user input used to construct a dynamic query expression, or, for a data store with any secondary compute (a stored procedure or attached scripting layer), unsanitized input reaching that layer; mitigation: parameterized query construction (never string-concatenating user input into a query expression) and strict input validation at the API Gateway or authorizer layer before the request ever reaches business logic.

Event source spoofing threats. The processing function's object-created trigger fires based on the object's presence in the bucket, not on any verification of who uploaded it; an attacker with any legitimate upload path (even a narrow, intended-for-a-different-purpose one) can trigger the processing function with an object it never expected, potentially exploiting how that function interprets the object's filename, metadata, or content. Mitigation: the processing function must treat every field of the triggering event, including the object key and any metadata, as untrusted input, and the upload path itself should be scoped (a pre-signed URL limited to a specific key pattern) so an attacker's upload options are as narrow as the legitimate use case actually requires.

Threats prioritized by risk and effort

Worked example

The processing function, triggered by an object-created event, is found to trust the uploaded object's filename directly, using it to construct a downstream storage key for the processed result without validation. An attacker who has any legitimate upload path (even one intended only for a narrow use case) uploads a file with a filename containing path-traversal characters, and the processing function's unsanitized use of that filename lets the resulting output land at an unintended location. This is both an event-source-spoofing finding (the function trusted an untrusted event field) and, once traced, reveals the function's own execution role is broader than necessary (it can write to more of the object storage bucket than its actual output path requires), the authorization/data-exfiltration finding compounding the first. The prioritized fix: validate and sanitize the filename before it is used to construct any downstream key (closing the injection-adjacent spoofing vector directly), and separately scope the function's role to only its actual intended output prefix (limiting what even a successful future exploit of this class could reach).

Trade-offs and pitfalls

• The authorization-trusting-a-client-supplied-identifier finding is prioritized highest specifically because it combines the two properties that matter most for triage: high impact (direct cross-user access) and low fix effort (a code-level change, not new infrastructure); a prioritization scheme based on severity alone, without also weighing effort, would not surface this as clearly as the most urgent, most tractable fix.
• Over-broad execution roles are rarely the direct entry point for a compromise, but they are the multiplier on every other finding's severity, which is why they are prioritized highly despite not being the initial vulnerability in the worked example; a report that lists them as a lower-priority, standalone finding misses how much they amplify everything else.
• Event source spoofing is the threat category most specific to this exact architecture (an event-driven serverless pipeline) and the one most likely to be missed by a security review written from a general web-application threat-modeling template, since a traditional template's authentication/authorization/injection categories do not naturally prompt a reviewer to ask "does this function trust something about how it was invoked that an attacker could control."
• The worked example's combined finding (spoofing plus over-broad role) illustrates why threat modeling should trace an actual attack path through the architecture, not just enumerate categories independently; the two findings compound specifically because of how they connect, a relationship an independent, category-by-category review can miss.

Direct answer

A public web application that accepts file uploads and processes them in serverless functions maps cleanly onto STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege), and the highest-priority findings concentrate specifically on Tampering and Elevation of privilege, since an untrusted file is, by definition, attacker-controlled content reaching a processing function, which is exactly the shape of threat those two categories describe; the mitigations a solutions architect should recommend are architectural (network and identity boundaries), not code-level fixes the architecture review itself cannot verify.

Structured elaboration

Spoofing. An attacker impersonates a legitimate user to upload a file under someone else's identity, or spoofs the upload event itself to trigger processing without a genuine upload having occurred. Likelihood: medium (requires either a stolen credential or a flaw in the upload-authorization flow); impact: medium (primarily an attribution and audit-trail problem, unless combined with a Tampering finding). Mitigation: strong, short-lived upload-authorization tokens (a pre-signed URL scoped to one specific object key and a short expiration) rather than a broadly-reusable upload credential, and event-source validation in the processing function confirming the triggering event genuinely originated from the expected storage location, not an event a caller crafted directly.

Tampering. The uploaded file's content or metadata (filename, declared content type) is attacker-controlled and used unsafely by the processing function, the highest-priority finding in this threat model. Likelihood: high (this is the architecture's primary attacker-reachable surface); impact: high (can range from a processing function crash to remote code execution, depending on how the function parses the file). Mitigation: validate file type by content inspection, not by trusting the client-declared type or the filename's extension; never construct a file path, a shell command, or a downstream query using the filename or any other attacker-controlled metadata without strict validation first; and run the actual file-parsing logic in an isolated, minimally-privileged execution context.

Repudiation. Without sufficient logging, neither the platform nor the uploading user can later prove or disprove that a specific upload occurred, or what a processing function did with it. Likelihood: high if logging is not deliberately designed in; impact: low to medium on its own, but it compounds every other finding's investigability. Mitigation: log the upload event, the authenticated uploader's identity, and every stage of processing with enough detail to reconstruct what happened to a specific file, shipped to a centralized, tamper-resistant log destination.

Information disclosure. A processing function with an execution role broader than its actual function requires can read more data (other users' uploaded files, unrelated internal resources) than the specific upload it was invoked for; separately, an error message or a debug log accidentally including file content could leak sensitive data uploaded by one user to an operator with no legitimate need to see it. Likelihood: medium; impact: high, since this is a direct data-exposure path. Mitigation: per-function least-privilege execution roles scoped to only the specific object the triggering event names, and structured logging that explicitly excludes file content from log output.

Denial of service. A maliciously crafted or oversized file exhausts the processing function's memory, execution time, or downstream storage, or a flood of upload requests exhausts the platform's processing capacity. Likelihood: medium; impact: medium (availability, not data exposure). Mitigation: enforce a maximum file size before the file is even fully accepted, set function-level timeout and memory limits appropriate to legitimate file sizes, and rate-limit the upload endpoint itself.

Elevation of privilege. A compromised processing function (through a successfully exploited Tampering vulnerability) uses its own execution role to reach further than the immediate file it was invoked to process, the second-highest-priority finding, since it is the direct consequence of a successful Tampering attack turning into broader account access. Likelihood: medium (requires a prior successful Tampering exploit as the precondition); impact: high (turns a single-file compromise into a broader account compromise). Mitigation: the same per-function least-privilege role scoping named under Information disclosure, which is the single control doing the most work across both categories.

Prioritization by likelihood and impact

Tampering is prioritized highest (high likelihood, high impact, and the entry point every other high-impact finding in this model depends on). Elevation of privilege is prioritized second, specifically because it is what determines how bad a successful Tampering exploit actually becomes, the multiplier effect named in the elaboration above. Information disclosure and Denial of service follow as independently medium-to-high priority findings. Spoofing and Repudiation, while genuine findings, are lower standalone priority, since their impact is largely contingent on or compounds one of the other categories rather than being independently severe.

Architectural mitigations a solutions architect should recommend

Least-privilege, per-function execution roles (the single highest-leverage architectural control here, addressing both Information disclosure and Elevation of privilege at once); content-based file-type validation happening in a dedicated, isolated validation step before any business-logic processing touches the file; short-lived, narrowly-scoped upload authorization; centralized, tamper-resistant logging covering the full upload-to-processing lifecycle; and explicit size, timeout, and rate limits enforced at the platform edge, not left to the processing function's own default behavior.

Worked example

A file-sharing application's processing function extracts metadata from uploaded documents and stores the results in a database. An attacker uploads a file with a crafted filename containing a path-traversal sequence, exploiting the processing function's unsanitized use of that filename to write its output somewhere outside the intended location, a direct Tampering exploit. Because the function's execution role happens to be scoped broadly (shared across several processing functions "for simplicity"), the attacker's crafted output path lands in a location the function's role can write to, but that a properly-scoped, per-function role would not have permitted, turning a single Tampering finding into an Elevation-of-privilege finding as well. The architectural fix recommended is not a single patch to this one function's filename handling (a code-level fix outside this review's own scope, though also necessary), but the broader architectural correction: per-function role scoping across every processing function in the pipeline, so the next Tampering vulnerability discovered in a different function does not have the same broader-than-necessary blast radius this one did.

Trade-offs and pitfalls

• A threat model that stops at listing STRIDE categories independently, without tracing how a Tampering finding becomes an Elevation-of-privilege finding once it succeeds, misses the compounding relationship that actually determines real-world severity, exactly what the worked example demonstrates directly.
• A solutions architect's recommendations need to stay at the architectural level (role scoping, isolation boundaries, platform-level limits) rather than prescribing a specific code fix for a specific function, since the architectural review's own scope and expertise is the system's structure, not auditing every function's internal code; the worked example's filename-handling bug still needs a code fix, but the review's own deliverable is the broader per-function-role-scoping recommendation that limits the next such bug's impact too.
• Repudiation and Spoofing are genuinely lower standalone priority, and that ranking can be mistaken for "not worth fixing," when actually their value is specifically in supporting investigation of the higher-priority findings; without adequate logging (addressing Repudiation), an actual Tampering exploit in production is far harder to detect and investigate after the fact, even though Repudiation itself was ranked lower.
• A shared execution role "for simplicity" across multiple processing functions, as in the worked example, is a common, well-intentioned shortcut that directly converts what should be an isolated, single-function compromise into an account-wide risk; the cost of per-function role authoring is real but is precisely what the highest-priority finding in this model depends on to stay contained.

Direct answer

Automated misconfiguration detection for a multi-account AWS environment layers three native services and two external tool categories into one pipeline, AWS Config and Security Hub for continuous configuration and finding aggregation, GuardDuty for behavioral threat detection, IaC (infrastructure-as-code) scanning (Checkov/tfsec) for pre-deployment prevention, and policy engines (OPA/Sentinel) for plan-time enforcement, feeding one central dashboard; the design decision that matters most is not which tools to use, all of these are reasonably standard choices, it is which findings get automated remediation versus which get routed to a human, since that boundary determines whether the system is trustworthy or dangerous.

Structured elaboration

Native service roles. AWS Config continuously evaluates every resource's configuration against managed and custom rules across every account, the primary source of configuration-drift and misconfiguration findings. Security Hub aggregates findings from Config, GuardDuty, and any third-party integrated tool into one normalized finding format and one dashboard, serving as the central aggregation point rather than each source having its own separate view. GuardDuty adds behavioral, threat-intelligence-driven detection (an unusual API call pattern, a known-malicious IP contacted) that configuration-based Config rules structurally cannot provide, since Config checks state, not behavior over time.

IaC scanning role. Checkov or tfsec run in the CI (continuous integration) pipeline against every infrastructure-as-code change before it merges, catching a misconfiguration before it is ever deployed, the cheapest point in the whole pipeline to catch a finding, since it requires no live cloud resource to exist yet.

Policy engine role. OPA/Sentinel evaluates the fully-resolved terraform plan output (or an equivalent for another IaC tool) at plan time, catching a misconfiguration that only resolves once variables and modules are fully computed, which static IaC scanning alone can miss; this is a preventive gate specifically for changes that go through the IaC pipeline, distinct from Config's detective, always-on coverage of the account regardless of how a resource got there.

How findings flow to a central dashboard

Every source (IaC scanning, policy-engine plan-time checks, Config, GuardDuty) emits findings in, or normalized into, the AWS Security Finding Format, feeding into Security Hub, which serves as Aggregation account's own delegated-administrator view across every member account in the AWS Organization, consistent with the delegated-administrator pattern used for centralized security tooling throughout this domain. From Security Hub, findings route into the organization's existing ticketing system (via an EventBridge rule triggering a Lambda function or a native integration), so the dashboard is not the only place a finding lives, it also becomes tracked, assigned work in the tool the responsible team already uses daily.

Prioritization

Findings are scored by a combination of severity (the source tool's own rating), exploitability (is the affected resource internet-reachable right now), and business context (is the account tagged as production, does the resource hold sensitive data), rather than a flat severity list that would treat a critical finding on an isolated development resource the same as an identical finding on an internet-facing production one.

Automated remediation versus human-reviewed remediation

Automated remediation is reserved for a narrow, explicitly reviewed list of finding types where the fix is unambiguous and reversible (re-enabling S3 Block Public Access, closing a security-group rule matching a known-bad pattern with no legitimate business justification ever recorded for it), triggered directly from a Config rule's non-compliant state via an automated remediation action (a Systems Manager Automation document, or an equivalent), with the remediation action itself logged as its own auditable event. Everything else routes to human review: a finding whose "correct" fix depends on context the automated system cannot evaluate (an unusually broad but potentially legitimate permission grant, a resource whose configuration might be intentional for a specific business reason) becomes a ticket with a severity-based service-level agreement (SLA), not an automatic action, since auto-remediating a context-dependent finding risks breaking a legitimate configuration the automated system had no way to distinguish from a genuine misconfiguration.

Worked example

A developer's Terraform pull request adding a new S3 bucket without Block Public Access enabled is caught by Checkov at the IaC-scanning stage, blocking merge before any resource is created, the cheapest possible catch. A separate, unrelated change made directly through the console (bypassing IaC entirely) opens a security-group rule to 0.0.0.0/0 on port 22; AWS Config's continuous evaluation flags this within its next scheduled evaluation cycle, and because this exact pattern (SSH open to the world, no recorded business justification) is on the narrow auto-remediation list, an automated remediation action reverts the rule within minutes, logging the action and notifying the resource's owning team after the fact. A third finding, a database security group permitting inbound access from a broader internal CIDR range than the organization's general policy prefers, does not match any auto-remediation pattern (the "correct" fix depends on whether a specific application dependency actually needs that broader range), so it routes to a ticket with a 7-day SLA for the owning team to review and either narrow the rule or document the justification.

Trade-offs and pitfalls

• The auto-remediation list is the single highest-stakes design decision in this architecture, and it needs to stay narrow and under continuous review, not grow opportunistically every time a new "obviously safe" pattern is proposed; the worked example's SSH-open-to-the-world case is genuinely unambiguous, but a broader or more context-dependent pattern added to the same list without the same scrutiny risks an automated action breaking a legitimate configuration.
• GuardDuty's behavioral detection and Config's configuration-state detection catch fundamentally different things, and a design that treats them as redundant (or worse, only implements one) misses half of what this layered approach is built to catch; Config would never flag an unusual API call pattern, and GuardDuty would never flag a static, unchanging misconfiguration that was simply never actually exploited.
• IaC scanning and Config together still leave a real gap: a change made entirely outside the IaC pipeline, caught only by Config's own continuous, out-of-band evaluation, not prevented at merge time. The worked example's console-made security-group change demonstrates this directly; the design's real strength is that Config's detective coverage exists specifically because IaC scanning's preventive coverage cannot see everything.
• Routing every finding to Security Hub and then to a ticketing system only delivers real value if the ticket routing correctly identifies the owning team via resource tagging; a finding routed to the wrong team, or to no team at all because tagging was incomplete, sits unactioned regardless of how well the detection and aggregation layers themselves are working.