Security Architecture for Greenfield Solutions

New solutions security design is the SAP-C02 Task 1.2 competency that asks you to architect security from the first line of Terraform for a greenfield workload, not to retrofit controls onto an existing mess. On the professional exam, "new solutions security design" question stems describe a workload that has not yet been built — a new B2B SaaS, a new regulated healthcare platform, a new global fintech API — and ask the architect to prescribe the Zero Trust identity model, the encryption hierarchy, the tenant isolation pattern, the edge protection layering, the detection pipeline, and the logging design. The right answer combines a dozen AWS security services into one coherent architecture, and the exam rewards candidates who understand how the pieces reinforce each other.

This Pro-depth guide walks through new solutions security design for a reference scenario the exam loves: a B2B SaaS with 10,000 tenants, compliance-bound data (SOC 2, HIPAA, PCI DSS depending on tenant), and a zero-trust mandate from the CISO. You will see how AWS Verified Access replaces the legacy client VPN, how VPC Lattice + ACM Private CA enforce mTLS between microservices, how the KMS key hierarchy splits by environment / tenant / data classification, how multi-tenant isolation trades off between account-per-tenant, VPC-per-tenant, and row-level silos, how WAF + Shield Advanced + CloudFront signed URLs layer at the edge, and how GuardDuty + Detective + Security Hub and centralized CloudTrail + VPC Flow Logs + CloudWatch Logs build the org-wide detection and audit plane. By the end, you will be able to look at a greenfield scenario on the exam and prescribe the complete new solutions security design the question is asking for.

What Is New Solutions Security Design?

New solutions security design is the prescriptive architectural exercise of selecting and composing AWS security services before a workload is built, such that the controls are native to the design rather than bolted on later. The AWS Well-Architected Security Pillar codifies the seven design principles — strong identity foundation, traceability, security at all layers, automated best practices, data protection at rest and in transit, keep people away from data, and prepare for events — and new solutions security design is the act of translating those principles into concrete service choices.

Why New Solutions Security Design Matters for SAP-C02

Task 1.2 of the SAP-C02 exam ("Prescribe security controls") has shifted markedly toward greenfield scenarios in recent exam forms. Question stems now frequently say "a new SaaS application," "a new healthcare platform being built," or "the architecture team is designing a new global API gateway." These stems reward candidates who know the 2023–2025 Zero Trust service catalog — Verified Access, VPC Lattice, IAM Identity Center, Verified Permissions — not just the legacy VPN-and-security-group answers. New solutions security design also demands that you understand which service replaces what: Verified Access replaces Client VPN for application access; VPC Lattice replaces self-managed service mesh plus NLB-per-service sprawl; Verified Permissions replaces homegrown RBAC databases.

The Seven Pillars of New Solutions Security Design

Every greenfield architecture must address seven concerns, and the exam tests them individually and in combination:

1. Identity and access — Zero Trust, Identity Center, Verified Access, Verified Permissions, VPC Lattice auth policies.
2. Data protection — KMS key hierarchy, envelope encryption, in-transit TLS / mTLS, ACM + Private CA.
3. Network security — VPC design, security groups, Network Firewall, Transit Gateway, PrivateLink, zero-trust service mesh via VPC Lattice.
4. Tenant isolation — account-per-tenant, VPC-per-tenant, namespace-per-tenant, row-level-per-tenant, or hybrid silos.
5. Edge protection — CloudFront, WAF, Shield Advanced, signed URLs, Route 53, AWS Global Accelerator hardening.
6. Detection and response — GuardDuty, Detective, Security Hub, Inspector, Config, Macie, Access Analyzer.
7. Logging and audit — Org CloudTrail, VPC Flow Logs, CloudWatch Logs, centralized Log Archive, immutable retention.

On the exam, a single question often touches three or four of these pillars, and the correct answer is the one that addresses every pillar the stem implies — never just one.

The Reference Scenario — 10,000-Tenant B2B SaaS With Zero Trust Mandate

Throughout this guide, one scenario anchors the design decisions. Internalize it; the SAP-C02 exam frequently varies it minimally.

The workload: a B2B SaaS product serving 10,000 enterprise tenants. Each tenant has compliance requirements ranging from SOC 2 baseline to HIPAA PHI or PCI-DSS card data. The CISO has mandated a Zero Trust architecture: no implicit trust based on network location, every request authenticated and authorized explicitly, continuous verification. The platform must scale to 50,000 tenants in three years. Tenants expect dedicated-looking performance and strict isolation, with a smaller enterprise tier willing to accept pooled isolation for lower pricing. Engineering is 80 developers across 12 microservice teams. Go-live is 12 months from now.

This scenario forces every new solutions security design decision on the table. You cannot solve it with a single service or a single account. The correct architecture is a disciplined layering of roughly fifteen AWS services, which this guide walks through section by section.

Plain-Language Explanation: New Solutions Security Design

New solutions security design is abstract until you put it in everyday terms. Three analogies from different domains make each aspect concrete — read all three.

Analogy 1 — Designing a New Hospital (Building / Healthcare Analogy)

Imagine you are the chief architect for a brand-new regional hospital serving 10,000 patients annually with mixed acuity — emergency, oncology, pediatrics, maternity. New solutions security design is the exercise of designing safety into the building before the first brick is laid, rather than retrofitting after patients start arriving.

Zero Trust is the hospital's badge-everywhere policy: no hallway is "safe by default"; every doorway reads your badge, every medication dispense verifies the nurse's current authorization, every patient room logs every entry. AWS Verified Access is the reception station that replaces the old perimeter fence — instead of trusting anyone who made it past the hospital gate (the VPN), every visitor is identified at every ward entrance with a current badge and a current reason. VPC Lattice with mTLS is the internal courier system: every lab result moving between departments carries a signed cryptographic envelope proving it came from the actual lab, not from an impostor cart.

The KMS key hierarchy is the medication lockbox system: one master pharmacy safe holds environment-level keys, each ward has its own sub-safe (tenant key), each high-risk drug class has its own inner lock (data-classification key). Multi-tenant isolation is the ward design — the oncology unit is a separate floor with separate HVAC (account-per-tenant, dedicated blast zone), while the general-medicine ward is open beds with curtained privacy (row-level silo, pooled resources, cheap). WAF + Shield + CloudFront signed URLs are the ambulance bay and main entrance security: WAF screens for known weapons patterns, Shield absorbs crowd surges at the gate, signed URLs are the visitor wristbands that let a specific person see a specific patient for a specific hour.

GuardDuty + Detective is the CCTV monitoring room with forensic playback: GuardDuty spots the suspicious gurney movement in real time, Detective lets investigators scrub the tape and connect five separate events into one incident. Security Hub is the accreditation board's scorecard hanging in the hospital administrator's office — Joint Commission readiness, HIPAA Security Rule compliance, all green-amber-red. Centralized CloudTrail and VPC Flow Logs are the legally mandated patient-visit log and pharmacy dispensary log stored in an off-site vault with immutable retention. Design all of these on the hospital blueprint before the walls go up and patient safety is architectural. Retrofit them later and every retrofit fights against the floor plan.

Analogy 2 — Building a New Central Bank (Finance / Institution Analogy)

Picture you are commissioned to design a new central bank for a national government — the vault, the treasury, the wire system, the counterfeit detection lab, the auditor's office, all under one institutional charter. New solutions security design is that commissioning work for a cloud workload.

Zero Trust with AWS Verified Access is the visitor identity verification at every floor elevator: the bank abolishes the idea of "you're in the building, you're trusted." Each elevator to the vault, to the trading floor, to the auditor's suite requires badge re-authentication with current employment status and current authorization — IAM Identity Center provides the badge, Verified Access is the elevator reader. VPC Lattice mTLS is the inter-department pneumatic tube system: every document capsule between the loan department and the compliance department is stamped with a cryptographic seal (mTLS certificate from ACM Private CA) that proves the sender's identity and detects tampering.

The KMS key hierarchy is the nested vault system: the master vault at the root holds national treasury keys, inside are per-department vaults (per-environment CMKs), inside those are per-account-holder safety deposit boxes (per-tenant keys), inside those are specific-document envelopes (per-data-class keys). KMS Grants are the temporary delegation slips signed by a vault officer permitting a named contractor to retrieve one specific deposit box for one specified duration. Multi-tenant isolation — account-per-tenant is a separate chartered subsidiary bank per large client; VPC-per-tenant is separate branch offices; row-level silo is shared tellers with privacy screens and strict procedures.

WAF + Shield + CloudFront is the public-facing lobby security: WAF is the entrance metal detector scanning for known threat patterns (SQLi, XSS, bot patterns), Shield Advanced is the crowd-control crew when a protest arrives (DDoS absorption and 24/7 SOC support), CloudFront signed URLs are the dated-and-named visitor passes that expire in fifteen minutes. GuardDuty is the counterfeit and fraud detection lab running ML on every transaction; Detective is the forensic accountants who pull six weeks of logs into one relationship graph when an incident happens. Security Hub is the regulatory compliance officer's desk with a live feed of every accreditation's status (SOC 2, PCI DSS, regional banking regulator). Centralized logging is the legally mandated write-once ledger shipped daily to an off-site vault — the auditor cannot be tampered with, ever.

Analogy 3 — Designing a New City's Utility Grid From Scratch (Infrastructure / Civil Engineering Analogy)

Suppose you are the chief systems engineer designing the power, water, telecom, and emergency-services grid for a new planned city of 500,000 residents. New solutions security design is that engineering exercise for a cloud workload.

Zero Trust is the principle that no neighborhood is implicitly safe — every substation, every pumping station, every cell tower is independently secured with its own badge reader and its own monitoring, regardless of where in the city it sits. AWS Verified Access is the badge reader at every critical-infrastructure gate, replacing the old "chain-link fence around the whole utility district" model (Client VPN). VPC Lattice with ACM Private CA-issued mTLS is the SCADA control signal system: every command sent from a control centre to a substation is cryptographically signed and the substation verifies the signature before acting — a stolen control channel cannot issue valid commands without the certificate.

KMS key hierarchy is the tiered locksmith system: master keys at the regional utility level, substation-tier keys, cabinet-tier keys, component-tier keys. Grants are the short-term work orders that let a contractor access one cabinet for one day without being issued a permanent key. Multi-tenant isolation — in this analogy, tenants are large-industry customers consuming dedicated substation capacity (account-per-tenant), commercial districts on shared feeders with metering (VPC-per-tenant), and residential blocks on pooled lines with smart meters (row-level silo).

Edge protection is the city perimeter: WAF is the border inspection for known threats in inbound data (signatures, rate limits), Shield Advanced is the emergency response when a coordinated cyber-physical attack hits, CloudFront signed URLs are the time-limited work permits for contractors entering a specific facility. GuardDuty is the distributed intrusion sensor network — motion detectors on every substation, cameras on every cabinet — reporting anomalies to one operations centre. Detective is the incident reconstruction lab that stitches months of sensor data into an attack timeline. Security Hub is the regulatory compliance dashboard showing conformance with the public utility commission's requirements. Centralized logging is the mandatory operations journal replicated daily to a fireproof off-site archive.

Architect all of this on paper before breaking ground and the city is born secure. Try to add it after the grid is energized and every retrofit requires brownouts.

Zero Trust Architecture With AWS Verified Access

Zero Trust is the foundational pattern for new solutions security design on SAP-C02. The mental shift: never trust based on network location; always verify identity, device posture, and authorization at every request.

Why Verified Access Replaces Client VPN for Application Access

AWS Client VPN (legacy pattern) establishes a network-layer tunnel; once inside the tunnel, the client reaches a VPC and can talk to any application the security groups allow. This violates Zero Trust — network membership is not identity. AWS Verified Access flips the model: the client connects over the public internet to a Verified Access endpoint, which authenticates the user via an identity provider (IAM Identity Center, Okta, Ping, any OIDC IdP), evaluates device trust signals from a Device Trust provider (CrowdStrike, Jamf, Jumpcloud), evaluates the Verified Access policy (Cedar-based, written as boolean expressions on user attributes, group membership, device attributes, and request attributes), and only then routes the request to the private application behind the endpoint.

Verified Access gives you per-request authorization at the application layer. A user who authenticates once into Identity Center does not thereby gain network-level access to everything. Each application (an internal HR portal, an internal admin console, a developer Kubernetes dashboard) has its own Verified Access endpoint with its own policy. A contractor might be allowed the developer dashboard but denied the HR portal, even though both sit in the same VPC.

Verified Access Policy Language — Cedar

Verified Access uses Cedar, AWS's open-source authorization policy language. Cedar policies read naturally:

permit(principal, action, resource)
when {
  context.identity.groups.contains("Engineering") &&
  context.identity.email_verified == true &&
  context.device.os_version >= "14.0" &&
  context.http_request.method == "GET"
};

Cedar is the same language used by Amazon Verified Permissions for application-layer authorization, which means your Verified Access policies and your in-app fine-grained authorization can share a consistent expression grammar. This is new-solutions-security-design gold: pick Cedar once for the greenfield and use it twice.

Verified Access Trust Providers — Identity and Device

A Verified Access endpoint attaches one user identity trust provider (Identity Center or external OIDC) and optionally one or more device trust providers (Jamf, CrowdStrike, Jumpcloud). The Cedar policy can reference both, for example requiring that the user is in a specific Identity Center group AND the endpoint is running a CrowdStrike-reported healthy posture. Device trust is the Zero Trust requirement that a compromised device should be denied even if the user credentials are valid.

Verified Access Logging and Detective Integration

Verified Access emits structured access logs to S3, CloudWatch Logs, or Kinesis Data Firehose. Every allow and deny decision is logged with the user, device posture, policy outcome, and request attributes. These logs feed Security Hub, GuardDuty (for anomalous access detection), and Detective (for forensic pivoting). On the exam, "the auditor asks for a record of every application access decision over the past year" is a Verified Access + centralized log archive answer.

VPC Lattice and Service-to-Service Zero Trust

East-west traffic (service-to-service) is where many greenfield Zero Trust designs fall short. Amazon VPC Lattice is the AWS-native service mesh that makes east-west Zero Trust declarative.

What VPC Lattice Does

VPC Lattice is a managed application networking service that connects services across VPCs and accounts. A service owner registers a service (an ALB, NLB, Lambda, or IP target group) with VPC Lattice. Consumer applications in any VPC in any account in the organization can reach that service through the Lattice data plane by hostname, without VPC peering, Transit Gateway attachments, or PrivateLink endpoints. Lattice routes traffic inside a managed multi-VPC "service network."

Crucially for new solutions security design, every service-to-service call through Lattice passes through the Lattice authorization engine, which evaluates auth policies (IAM-based policies on the service or service network). This is Zero Trust service-to-service authorization: service A can call service B only if the auth policy on service B explicitly permits the IAM principal of service A.

Lattice Auth Policies — Service-Level Zero Trust

An auth policy on a VPC Lattice service looks like an IAM resource policy:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {
      "AWS": "arn:aws:iam::TENANT-ACCOUNT:role/OrderServiceTaskRole"
    },
    "Action": "vpc-lattice-svcs:Invoke",
    "Resource": "arn:aws:vpc-lattice:us-east-1:PROD-ACCOUNT:service/svc-orders/*",
    "Condition": {
      "StringEquals": {
        "vpc-lattice-svcs:RequestMethod": "POST",
        "vpc-lattice-svcs:RequestPath": "/orders/submit"
      }
    }
  }]
}

This says: the Orders service accepts calls only from the OrderServiceTaskRole in the tenant account, only on POST to /orders/submit. Every other caller, every other method, every other path is denied by default. Compared to traditional security-group-based east-west control (where any workload in the same security group can reach any port), Lattice auth policies give per-IAM-principal, per-HTTP-method, per-path authorization — the Zero Trust ideal.

mTLS With ACM Private CA at the Service Layer

VPC Lattice supports native TLS termination, and for cryptographic peer identity (not just transport encryption) you layer mTLS using certificates issued by AWS Private Certificate Authority (PCA). The pattern for new solutions security design:

1. Set up an AWS Private CA hierarchy in the shared-services or security account: a root CA (offline, rarely used) signs a subordinate CA that issues end-entity certificates.
2. Share the subordinate CA to workload accounts via AWS RAM.
3. Each microservice obtains a certificate from the subordinate CA with its DNS name as the Subject Alternative Name.
4. The service terminates mTLS, validating peer certificates against the shared CA's trust chain.
5. Combine with Lattice auth policies for IAM-based authorization on top of cryptographic peer identity.

mTLS gives you the cryptographic proof of identity that Zero Trust requires for the most sensitive service-to-service calls — for example, the payment service accepting requests only from the order service when the order service presents a certificate chain rooted in the internal PCA.

VPC Lattice vs Service Mesh (App Mesh, Istio)

App Mesh is AWS's Envoy-based sidecar service mesh, now in maintenance mode — not the forward-looking choice for greenfield. Istio is self-managed, heavy operationally. VPC Lattice is the managed, AWS-native, mesh-without-sidecar answer for new solutions security design. On the exam, if the scenario says "service-to-service authorization across accounts and VPCs, minimal operational overhead, Zero Trust," Lattice is the answer.

KMS Key Hierarchy Design at Scale

Encryption at rest is non-negotiable in the reference scenario. The challenge with 10,000 tenants and mixed compliance requirements is not whether to encrypt — it is how to structure the key hierarchy so that operations, auditing, cost, and tenant isolation all work.

The Three-Axis Key Hierarchy

A mature greenfield KMS design organizes customer-managed keys (CMKs) along three axes:

• Environment axis: separate keys per environment (dev / stage / prod). Prevents a dev-account compromise from decrypting production data.
• Tenant axis: separate keys per tenant for tenants whose isolation mandate requires it (HIPAA BAA, PCI cardholder environment, premium enterprise tiers).
• Data classification axis: separate keys per data class (general, PII, PHI, cardholder, financial records). Enables per-class access policies and per-class retention/rotation.

For 10,000 tenants with a mix of isolation requirements, the pragmatic design is:

• One pool CMK per environment per data class for the general-tier tenants (about 5–10 CMKs total, shared across 9,000 tenants).
• One dedicated CMK per tenant for the premium / compliance tier (up to 1,000 CMKs for the top 10% of tenants).

This hybrid balances cost (KMS keys are $1/month each) against isolation. 10,000 dedicated keys would be $10,000/month just for key storage; a hybrid design is an order of magnitude cheaper and aligns with how tenants actually pay.

Key Policies vs IAM Policies vs Grants at Scale

Three mechanisms control access to a KMS key, and choosing the right one at scale is a common SAP-C02 trap:

Key policies are the authoritative grant for a key. Edit the key policy to add principals, conditions, and action scopes. Key policies scale poorly when thousands of short-lived principals need access — you cannot continuously rewrite a key policy.

IAM policies in the same account delegate from the key policy's "allow IAM delegation" clause. IAM policies scale to many principals in the same account because they attach to the caller, not to the key. For intra-account access at scale, IAM policies on principals plus a key policy that enables IAM delegation is the right pattern.

KMS Grants are programmatic, ephemeral delegations. A grant authorizes a specific principal for specific operations on a specific key with optional encryption-context constraints, and can be revoked independently. Grants scale best when an AWS service (EBS attaching a volume, RDS starting an instance, Aurora creating a replica, Lambda invoking with encrypted environment variables) needs temporary key access. The service creates a grant, uses it, and the grant is revoked or retires.

For the 10k-tenant scenario, the grant pattern dominates: when a tenant's workload provisions a new EBS volume or new RDS instance, the provisioning automation creates a KMS grant scoped to that resource. When the resource is decommissioned, the grant is retired. No key-policy edits are required for ordinary operations.

Encryption Context as a Tenant Tag

KMS encryption context is a set of non-secret key-value pairs supplied during encrypt and required during decrypt. Use it to bind every ciphertext to its tenant:

encryption_context = { "tenant_id": "tenant-47381", "data_class": "PHI" }

Now a decrypt call that does not supply the matching encryption context fails, even if the caller has kms:Decrypt permission on the key. Combined with a key policy condition "kms:EncryptionContext:tenant_id": "${aws:PrincipalTag/TenantId}", you cryptographically enforce that tenant A's principal cannot decrypt tenant B's ciphertext — even when both share a pool CMK.

KMS Multi-Region Keys for DR

The reference scenario is compliance-bound and needs disaster recovery. KMS Multi-Region Keys (MRKs) have the same key ID across replica regions so ciphertext encrypted in us-east-1 is decryptable in us-west-2 without re-encrypting on failover. MRK replicas have independent key policies, so cross-account grants must be set per region. For greenfield, decide upfront which keys are MRKs (those protecting DR-replicated data) and which are single-region.

Multi-Tenant Isolation Patterns

The scenario demands isolation for 10,000 tenants with mixed compliance. There is no single right answer — the SaaS Tenant Isolation Strategies whitepaper defines four patterns, and the greenfield design usually combines them.

Pattern 1 — Account Per Tenant (Silo)

One AWS account per tenant. Strongest isolation — SCPs, IAM, KMS, VPC, resources are all tenant-scoped. Used by high-compliance tenants (PCI, HIPAA with explicit isolation requirements) and high-value enterprise clients willing to pay for dedicated infrastructure.

Operational cost is high — tenant onboarding requires Control Tower Account Factory or AFT to provision an account, baseline security services, and deploy application stack. CI/CD pipelines must handle per-account deployment (CodePipeline cross-account roles). Billing is per-account, making cost attribution crystal clear.

Limit: AWS Organizations defaults to 10,000 accounts per organization (soft limit, raisable). Hitting this limit is realistic for the 50,000-tenant three-year target; plan multi-organization from the start for that scale, or combine with pooled pattern.

Pattern 2 — VPC Per Tenant (Silo)

One VPC per tenant inside a shared account (or a small number of accounts). Network isolation is strong (no network path between tenants). Account-level controls (SCPs, CloudTrail) are shared. Mid-tier compliance tenants often land here.

Implementation: Transit Gateway or VPC Lattice connects tenant VPCs to shared services (observability, logging, identity). KMS keys and IAM roles are typically per-tenant even in a shared account.

Pattern 3 — Namespace Per Tenant (Pool)

One Kubernetes namespace per tenant (or one schema per tenant in a shared database, one OpenSearch index per tenant, one Lambda alias per tenant). Shared compute, shared control plane, tenant context enforced by application-level logic. Lower cost per tenant; lower isolation guarantee.

Used for the base tier where tenants accept pooled resources for lower pricing. Works for SOC 2 baseline tenants; does not satisfy HIPAA or PCI on its own.

Pattern 4 — Row-Level Per Tenant (Pool)

Shared database table with a tenant_id column on every row. Database-level row security or ORM-layer filter enforces tenant isolation. Cheapest; weakest isolation guarantee (a bug in the ORM filter leaks data across tenants).

Combine row-level with envelope encryption per tenant — each row's sensitive fields are encrypted with a tenant-specific KMS data key. Even if a query bug returns another tenant's rows, the ciphertext cannot be decrypted without the target tenant's key. This is the common pattern for pool tier with meaningful isolation.

The Hybrid Reference Design

For the 10,000-tenant scenario, the pragmatic hybrid:

• Platinum tier (top 1%, ~100 tenants): account-per-tenant, dedicated CMKs, dedicated VPC, strict SCP. PCI/HIPAA compliance.
• Gold tier (next 10%, ~1,000 tenants): VPC-per-tenant inside a pool of shared accounts, dedicated CMK per tenant, stricter IAM role isolation. SOC 2 with tenant-specific controls.
• Silver tier (bulk 89%, ~8,900 tenants): namespace-per-tenant in shared EKS cluster, row-level silo in shared RDS, per-tenant envelope encryption with encryption-context-bound decrypts. SOC 2 baseline.

This hybrid maps directly to commercial tiers and explains to the exam grader that you understand isolation is a spectrum, not a single choice.

SCP Patterns for Tenant Isolation

Account-per-tenant uses SCPs to prevent cross-tenant actions: deny iam:* actions that could create a role trustable from another tenant's account, deny kms:* actions that modify key policies to add external principals, deny sharing resources via RAM outside an approved list. The SCP is the hard isolation guarantee that even if a tenant admin is compromised, the blast radius is tenant-scoped.

Edge Security Layering — WAF + Shield Advanced + CloudFront Signed URLs

Public-facing entry points are the most attacked surface in a new SaaS. New solutions security design layers three services at the edge.

CloudFront as the Edge Termination Point

All public traffic terminates at CloudFront. Benefits: geographic attack surface reduction (origin is not exposed), caching absorbs volumetric load, native integration with WAF and Shield, signed URL / signed cookie support for private content, and edge functions (Lambda@Edge and CloudFront Functions) for request-time logic.

The origin (ALB, API Gateway, S3) is restricted via origin access control (OAC for S3, VPC origin for ALB, AWS WAF IP-set on ALB listener to accept only CloudFront's IP ranges published in AMAZON_CLOUDFRONT). This ensures every request reaches the origin only through the edge.

AWS WAF at the CloudFront Layer

WAF attaches to CloudFront (for public traffic) and to regional ALB / API Gateway / AppSync (for internal or regional endpoints). Managed rule groups cover OWASP Top 10 (AWSManagedRulesCommonRuleSet), known bad inputs, IP reputation lists, bot control, account takeover prevention. Custom rules add workload-specific logic — block requests with unexpected geolocations, rate-limit by tenant ID in a header, block requests missing a mandatory API key.

WAF logs flow to S3, CloudWatch Logs, or Kinesis Data Firehose. For the greenfield, enable WAF full logging to S3 with object lock — WAF logs are both detection data (feed to GuardDuty / Detective / Security Hub) and forensic evidence for compliance audits.

Shield Advanced for DDoS Defence

Standard Shield is included free on CloudFront and ALB. Shield Advanced ($3,000/month per organization) adds enhanced DDoS detection, 24/7 SRT (Shield Response Team) engagement during attacks, cost protection (DDoS-related scaling charges refunded), and application-layer DDoS mitigation via WAF rate-based rules tuned by SRT.

For a compliance-bound B2B SaaS, Shield Advanced is typically justified. On the exam, "business-critical workload with SLA tied to availability, concerned about DDoS" is a Shield Advanced answer.

CloudFront Signed URLs and Signed Cookies

For private content (tenant data downloads, per-tenant video, premium assets), CloudFront signed URLs are time-limited, optionally policy-scoped URLs that grant access to one principal for one resource for one window. Signed cookies scope to multiple resources at once.

In the greenfield, every tenant-facing asset delivery uses signed URLs — the application generates the URL at the moment of delivery, signs it with a CloudFront key-group private key, and the edge validates the signature and expiration. This prevents URL hoarding and cross-tenant URL sharing. A leaked URL expires in minutes; a leaked signing key is rotated via a key-group update without invalidating live CloudFront deployments.

Firewall Manager for Organization-Wide Edge Policy

AWS Firewall Manager enforces WAF web ACLs, Shield Advanced protections, and security group baselines across all accounts in the Organization. In the greenfield, the security account is Firewall Manager delegated admin; it pushes a baseline WAF policy (OWASP core rules) to every public-facing ALB and CloudFront distribution in the organization, preventing a tenant account from shipping a public endpoint without WAF attached.

GuardDuty and Detective — Detection Pipeline for Greenfield

GuardDuty is the baseline threat-detection service for every greenfield. Detective layers forensic investigation on top. Both should be enabled on day zero, not added after the first incident.

GuardDuty Baseline at Greenfield

Enable GuardDuty with the Organizations delegated admin pattern from day one:

• Security account is GuardDuty delegated admin.
• Auto-enable new accounts and all required protection plans.
• Enable every applicable protection plan: Malware Protection for EC2, S3 Protection, EKS Protection, Lambda Protection, RDS Protection.
• Findings flow to Security Hub and to an EventBridge bus for SIEM integration.

GuardDuty's ML models baseline each account's normal activity. For a greenfield, this means the first 30 days are a learning period — expect initial false positives to tune out via suppression rules. After that, GuardDuty reliably detects unusual API patterns, crypto-mining, DNS exfiltration, and compromised credentials.

Detective for Forensic Investigation

Amazon Detective builds a relationship graph from CloudTrail, VPC Flow Logs, GuardDuty findings, EKS audit logs, and Route 53 query logs. When GuardDuty raises a finding — say, "IAM role X made an API call from a Tor exit node" — Detective lets analysts click through to the role's last 30 days of activity, the resources it touched, the IP addresses it originated from, the other roles that may share behavioral patterns.

Detective is a delegated-admin service (security account). Enable it alongside GuardDuty at greenfield; the data source activation is automatic once both are on. Storage is priced per GB of ingested data; for a 50-account greenfield Detective costs low hundreds of dollars per month and dramatically reduces incident-response time.

GuardDuty Malware Protection for EC2

Malware Protection for EC2 scans EBS volumes when GuardDuty raises a suspicious finding — it snapshots the volume, mounts the snapshot in an AWS-managed scanning environment, runs malware detection, and returns findings without touching the live workload. Critically, scanning does not require an agent on the workload — zero footprint. For greenfield, enable this plan from day one.

GuardDuty S3 and EKS Protection

S3 Protection analyses S3 data events for anomalous access patterns (unusual download volumes, access from unusual principals). EKS Protection ingests EKS audit logs and detects pod behavior anomalies (pods making unexpected API calls, privilege-escalation attempts). Both are essential for a SaaS workload with S3-heavy data storage and EKS-based compute.

Security Hub as the CSPM Baseline

Cloud Security Posture Management (CSPM) is the continuous measurement of security misconfigurations against a standards baseline. Security Hub is AWS's native CSPM.

Enable Day-One Standards

At greenfield, enable Security Hub from the delegated admin (security account) and turn on:

• AWS Foundational Security Best Practices (FSBP): AWS's curated 200+ controls. The baseline for every workload.
• CIS AWS Foundations Benchmark v3.0: industry standard.
• PCI DSS v4.0: enabled for the platinum tier accounts.
• NIST SP 800-53 Rev. 5: enabled if any federal or federal-adjacent tenant exists.

Security Hub computes a security score per account per standard. In the greenfield baseline, most accounts start at 60–70% compliance; the goal for production launch is 90%+ with documented exceptions for the rest.

Cross-Region Aggregation

Pick an aggregation region on day one (typically us-east-1) and enable Security Hub cross-region aggregation. Every finding from every region flows to the aggregation region's console. The security team has one pane of glass across the entire organization and every region of operation.

Automation Rules for Finding Triage

Security Hub Automation Rules modify findings based on attributes without writing Lambda. Examples: auto-suppress findings on sandbox accounts (tag Environment=Sandbox), auto-raise severity for findings on PCI-classified resources (tag DataClass=PCI), auto-add a compliance-framework reference note to findings touching specific controls. Set up automation rules at greenfield; they scale with the workload.

Integration With GuardDuty, Inspector, Macie, Access Analyzer

All AWS security services' findings flow into Security Hub in the standard AWS Security Finding Format (ASFF). Third-party partner findings (CrowdStrike, Wiz, Palo Alto Prisma) integrate via the partner catalog. Security Hub is the one dashboard where the security team sees everything.

Centralized Logging Design — CloudTrail + VPC Flow Logs + CloudWatch Logs

Audit logging is table stakes for compliance. New solutions security design centralizes logs in a Log Archive account with immutable retention.

Organization CloudTrail to Log Archive

Create an organization trail from the management account that captures every management event and optionally data events from every member account in every region. Deliver to a central S3 bucket in the Log Archive account. Enable:

• S3 Object Lock in compliance mode for the log bucket (immutable retention, ransomware-resistant).
• S3 Bucket Key for KMS cost optimization.
• CloudTrail log file integrity validation (digest files).
• CloudWatch Logs delivery for real-time query via CloudTrail Lake or Athena.
• MFA delete on the bucket.

The Log Archive account has no human users; access is via break-glass IAM roles audited separately. SCPs prevent the Log Archive bucket from being modified or deleted by anyone.

CloudTrail Data Events — Selective Not Universal

Management events are the foundation. Data events (S3 object-level, Lambda function-level, DynamoDB item-level, EKS kubectl) are priced per event and can generate massive volume. At greenfield, enable data events selectively:

• S3 data events on the Log Archive bucket itself (who read the audit logs).
• S3 data events on PCI/HIPAA-classified buckets.
• Lambda data events on privileged functions (the one that rotates secrets, the one that provisions tenants).

Don't enable S3 data events organization-wide on day one — cost spirals. Turn on selectively by classification tag.

VPC Flow Logs Centrally Collected

Enable Flow Logs on every VPC (or at the TGW level for centralized architectures). Deliver to the Log Archive account's S3 bucket, partition by account/region/vpc/date for efficient Athena querying, and parquet-format for cost and performance. Flow Logs feed GuardDuty (VPC Flow Logs data source), Detective, and ad-hoc forensic queries.

CloudWatch Logs Organization-Wide Collection

Application logs, Lambda logs, Lambda@Edge logs, container logs — CloudWatch Logs is the universal sink. In a multi-account organization, ship critical log groups to the Log Archive account via CloudWatch Logs subscription filters → Kinesis Data Firehose → central S3. Retain 30 days in-account for operational troubleshooting; retain years in central S3 for compliance.

Log Classification and Retention

Classify log streams: security logs (CloudTrail, GuardDuty findings, WAF logs, VPC Flow Logs) retained 7 years; operational logs (app logs, Lambda logs) retained 30–90 days; audit-evidence logs (what SOC 2 / HIPAA requires) retained per framework (typically 7 years). Use S3 lifecycle policies: hot (S3 Standard) for 90 days → Infrequent Access → Glacier Instant Retrieval → Glacier Deep Archive for multi-year compliance retention at minimum cost.

IAM Identity Center as the Human Identity Plane

For 80 developers across 12 teams, human identity is IAM Identity Center (formerly AWS SSO). Identity Center is the federated sign-on across all organization accounts.

Identity Source Choice

Identity Center supports three identity sources: Identity Center directory (built-in, okay for small orgs), Active Directory (on-prem or AWS Managed Microsoft AD), and external IdP (Okta, Azure AD, Ping via SAML or SCIM). For the greenfield, Okta or Azure AD via SCIM is typical — users and groups sync automatically, permissions are managed in the corporate IdP, and offboarding a user in the IdP revokes all AWS access instantly.

Permission Sets

Permission sets are Identity Center's unit of IAM — a permission set is a collection of IAM policies that, when assigned to a user or group for a specific account, provisions an IAM role in that account with those policies. Define permission sets centrally:

• AdminAccess (break glass, MFA required, restricted group).
• DevOpsDeveloper (broad workload access within permission boundary).
• ReadOnly (audit and support role).
• SecurityAuditor (security team's read-only across all accounts).
• TenantOperator (tenant account admin, tenant-scoped).

Assign permission sets to groups (not users). A user's AWS access is derived from Identity Center group membership, which comes from the IdP. This is Zero Trust: the employee's current HR record determines their current AWS access, always.

Verified Permissions for Application Authorization

For the SaaS application's internal authorization (which tenant user can do which action on which resource in the application), Amazon Verified Permissions is the managed Cedar-based authorization engine. Define policies once in Cedar; evaluate millions of times per second via the Verified Permissions API. This replaces homegrown RBAC databases and keeps application-authorization logic auditable and centrally managed.

Permission Boundaries for Developer Self-Service

With 80 developers across 12 teams, central IAM admin cannot be the bottleneck. Permission boundaries are how you delegate IAM role creation safely.

The Pattern

• Central security team defines a permission boundary policy named PlatformDeveloperBoundary. The boundary allows Lambda, DynamoDB, S3, CloudWatch Logs, Secrets Manager, KMS decrypt on specific keys; denies IAM admin, Organizations, CloudTrail modification, Config modification.
• Developer permission sets grant iam:CreateRole, iam:PutRolePolicy, iam:PassRole — but with a condition "iam:PermissionsBoundary": "arn:aws:iam::ACCOUNT:policy/PlatformDeveloperBoundary". Developers can only create roles that attach the boundary.
• SCPs at the workload OU deny deletion of the boundary policy and deny modifying any role tagged SecurityManaged=true.

Result: developers self-service Lambda execution roles, ECS task roles, CodeBuild roles — but cannot escape the boundary. Security team is not a deploy-time gate.

Putting It Together — The Complete New Solutions Security Design

For the 10k-tenant B2B SaaS greenfield, the complete new solutions security design looks like this:

Account Structure

• Management account (Organizations root, minimally used).
• Log Archive account (centralized CloudTrail, VPC Flow Logs, WAF logs, CloudWatch Logs, immutable S3).
• Security account (GuardDuty delegated admin, Security Hub delegated admin, Config aggregator, Macie admin, Detective admin, Access Analyzer organization analyzer, Firewall Manager admin).
• Shared Services account (ACM Private CA root + subordinate, Identity Center, shared VPC Lattice service network).
• Workload OUs per tenant tier:
  • Platinum OU (account-per-tenant, ~100 accounts).
  • Gold OU (small pool of accounts with VPC-per-tenant).
  • Silver OU (shared accounts with namespace/row-level tenant pool).

Identity and Access

• Identity Center federated from Okta/Azure AD via SCIM.
• Permission sets aligned to team roles.
• PlatformDeveloperBoundary permission boundary for self-service role creation.
• AWS Verified Access endpoints for every internal web app; Cedar policies require Identity Center group + device trust.
• VPC Lattice service network shared across workload accounts; auth policies per service.
• ACM Private CA hierarchy for mTLS certs; service certs auto-rotated.
• Amazon Verified Permissions for application-layer RBAC (tenant users and their permissions).

Data Protection

• Per-environment KMS CMKs for platform services.
• Per-tenant KMS CMKs for platinum/gold tiers.
• Pool CMKs with encryption-context tenant binding for silver tier.
• KMS Grants for ephemeral service delegation (EBS, RDS, Aurora replicas).
• Multi-Region Keys for DR-replicated data.
• S3 default encryption SSE-KMS, bucket keys enabled.

Network

• Transit Gateway for account-to-account connectivity.
• VPC Lattice for service-to-service traffic.
• PrivateLink to AWS services (no NAT gateway costs for API traffic).
• Network Firewall at egress for IDS/IPS and domain allowlisting.
• Zero public IPs on compute; all internet-bound traffic via NAT or Network Firewall egress VPC.

Edge

• CloudFront in front of every public application.
• WAF managed rule groups + custom rules per workload, logs to S3.
• Shield Advanced enabled.
• CloudFront signed URLs for every private asset.
• Route 53 with DNSSEC on public zones.
• Firewall Manager pushing baseline WAF policy org-wide.

Detection and Response

• GuardDuty with all protection plans, auto-enable new accounts.
• Detective for forensic graph.
• Inspector v2 for EC2 / ECR / Lambda vulnerability scanning.
• Macie for S3 sensitive-data discovery.
• Security Hub with FSBP + CIS + PCI + NIST standards, cross-region aggregation.
• Config aggregator with organization conformance packs (PCI, HIPAA, operational best practices).
• IAM Access Analyzer organization analyzer (external access + unused access + policy generation).
• EventBridge bus centralizing findings; Lambda or Step Functions automation for remediation runbooks.

Logging

• Organization CloudTrail to Log Archive S3 with Object Lock compliance mode.
• VPC Flow Logs on every VPC to central S3.
• WAF full logs to central S3.
• CloudWatch Logs subscription filters to central Firehose for app logs.
• S3 lifecycle: Standard → IA → Glacier Instant Retrieval → Glacier Deep Archive for 7-year compliance retention.
• CloudTrail Lake or Athena on central logs for ad-hoc query.

Compliance

• Audit Manager with SOC 2 Type 2, PCI DSS v4.0, HIPAA Security Rule frameworks.
• Continuous evidence collection from CloudTrail, Config, Security Hub.
• Quarterly audit-ready exports.

This is the new solutions security design the exam rewards: every pillar addressed, every layer chosen deliberately, and every service selected because it does a job the others cannot.

Cost Implications of New Solutions Security Design

Security is not free, and the exam tests cost-conscious design.

Rough Monthly Cost for the Reference Greenfield

For a 50-account organization (growing to 200 over year one):

• GuardDuty with all protection plans: $500–$2,000 per account per month depending on activity. At 50 accounts, budget $25,000–$100,000/month.
• Security Hub: $1,000–$3,000/month for finding ingestion across 50 accounts.
• Config: $2,000–$5,000/month depending on resource count.
• Detective: $500–$2,000/month.
• Macie automated sensitive discovery: $1,000–$5,000/month depending on S3 data volume.
• Shield Advanced: $3,000/month flat + per-protected-resource.
• KMS: low-hundreds (pool keys) to low-thousands (dedicated tenant keys at premium tier).
• Verified Access: $0.27/hour per endpoint + $0.02 per request.
• VPC Lattice: $0.025/hour per service + $0.025 per GB processed.
• CloudTrail S3 storage (7-year retention): grows to $5,000–$20,000/month by year three.

Total day-one security-services cost for the 50-account greenfield is roughly $40,000–$120,000/month. This is the cost of a mature security posture at cloud-native compliance scale. The exam sometimes asks about "reducing security cost" — the answers involve selective data event logging, sampling-based Macie, regional scoping of GuardDuty, and aggressive Glacier transition for log storage.

The Optimization Playbook

• Enable GuardDuty only in regions with actual workloads (combine with region-restriction SCP).
• Use Macie automated sensitive-data discovery (sampling) for general buckets; targeted jobs only on PCI/HIPAA buckets.
• Selective CloudTrail data events (not universal S3 or Lambda).
• Aggregation region for Security Hub (avoid duplicating ingestion costs).
• KMS bucket keys reduce KMS API call costs dramatically on S3.
• Pool CMKs with encryption context for silver-tier tenants, not dedicated keys.

Common Exam Traps for New Solutions Security Design

Trap 1 — Verified Access Replaces Site-to-Site VPN

Wrong. Verified Access replaces Client VPN for user-to-application access. Site-to-Site VPN connects office networks to VPCs and is a different use case.

Trap 2 — VPC Lattice Auth Policies Replace Security Groups

Partial. Lattice auth policies add IAM-based authorization at the service layer; security groups still exist at the VPC layer. The modern pattern uses both: security groups for coarse network segmentation, Lattice auth policies for fine per-principal service authorization.

Trap 3 — Dedicated KMS Key Per Tenant Is Always Right

Wrong. Dedicated keys are right for high-isolation tiers; pool keys with encryption context are right for cost-efficient silver tier. "Always dedicated" wastes $10,000+/month in the 10k-tenant scenario.

Trap 4 — Account-Per-Tenant Is the Only Compliant Isolation

Wrong. HIPAA does not require account-per-tenant. Pool-with-envelope-encryption-per-tenant satisfies HIPAA when properly designed. The exam sometimes offers account-per-tenant as the "safe" answer; check whether the stem says "10,000 tenants" — at that scale, account-per-tenant is usually impractical and wrong.

Trap 5 — Shield Standard Is Enough for Compliance-Bound SaaS

Wrong in most business-critical scenarios. Shield Standard is free and covers network-layer DDoS. Shield Advanced adds application-layer DDoS, 24/7 SRT engagement, and cost protection. For SLA-bound SaaS, Shield Advanced is table stakes.

Trap 6 — GuardDuty Alone Is the Detection Plane

Wrong. GuardDuty is threat detection; Security Hub aggregates findings and scores compliance; Detective provides forensic investigation; Inspector handles vulnerabilities; Macie handles data classification. All five are the detection plane, not GuardDuty alone.

Trap 7 — CloudFront Signed URLs and Signed Cookies Are Interchangeable

Partial. Signed URLs scope to a single URL; signed cookies scope to multiple URLs matching a pattern. For a tenant downloading a specific report, signed URL; for a tenant browsing a private asset area with many files, signed cookies.

Trap 8 — WAF at ALB Is Sufficient; CloudFront Not Needed

Wrong for public-facing compliance-bound workloads. CloudFront provides edge DDoS absorption, caching, and origin shielding — WAF at regional ALB alone exposes the origin's IP and does not benefit from global edge rejection.

Trap 9 — Private CA Only Matters for Public Websites

Wrong. Private CA (AWS Private Certificate Authority) issues internal certificates for mTLS between microservices and for internal TLS. For public websites, use ACM public certificates (which are free). The two serve different purposes.

Trap 10 — Identity Center Replaces the Corporate IdP

Wrong. Identity Center federates from the corporate IdP (Okta, Azure AD). The corporate IdP remains the source of truth for employment, groups, MFA. Identity Center is the AWS-side SSO endpoint. Breaking the corporate IdP does not mean AWS is now the IdP.

Key Numbers and Must-Memorize Facts

Verified Access

Endpoint types: browser (HTTPS), CLI/API via token broker. Trust providers: one user + optional device. Policy language: Cedar. Logs: S3/CloudWatch/Firehose.

VPC Lattice

Max services per service network: 500. Max service networks a VPC can associate with: 1. SigV4 auth + optional mTLS. Auth policies evaluated per request.

KMS

Key policy authoritative; IAM policy delegation for same-account; Grants for ephemeral/service delegation. Multi-Region Keys for geography. Encryption context binds ciphertext to scope. Bucket Keys cut S3 KMS call costs by 99%.

Multi-Tenant Isolation Tiers

Silo (strong, expensive) → Pool (weaker, cheap). Account-per-tenant → VPC-per-tenant → Namespace-per-tenant → Row-per-tenant. Hybrid by commercial tier is the pragmatic greenfield answer.

Edge

CloudFront + WAF + Shield (Advanced for critical) + signed URLs. Firewall Manager for org-wide baseline enforcement.

Detection

GuardDuty + Detective + Security Hub + Inspector + Macie + Config + Access Analyzer. All delegated-admin from security account; all feed Security Hub.

Logging

Org CloudTrail to Log Archive with Object Lock. VPC Flow Logs. WAF logs. CloudWatch Logs subscription to central Firehose. Athena / CloudTrail Lake for query.

FAQ — New Solutions Security Design Top Questions

Q1 — When do I choose AWS Verified Access over AWS Client VPN?

Verified Access when the requirement is application-layer Zero Trust access for users — internal web apps, admin dashboards, developer tools. Verified Access authenticates each request with identity + device posture + Cedar policy, and logs the decision. Client VPN when you need network-layer connectivity to a VPC (reaching services that are not HTTP, reaching IP addresses, legacy thick-client applications). For greenfield SaaS, Verified Access is almost always correct for user-to-app; Client VPN is a legacy fallback. Also note Client VPN and Verified Access coexist — you might have both, used for different purposes.

Q2 — How do VPC Lattice auth policies differ from IAM resource policies on ALBs?

IAM resource policies on ALBs do not exist — ALBs do not support IAM-based authorization at the load balancer layer. VPC Lattice is specifically the service that introduces IAM-based authorization for service-to-service HTTP traffic. If you want Zero Trust authorization between microservices across VPCs and accounts without sidecar service mesh, VPC Lattice with auth policies is the AWS-native answer. You can combine Lattice with mTLS (ACM Private CA) for cryptographic peer identity on top of IAM-based authorization.

Q3 — Should I use dedicated KMS keys per tenant, or pool keys with encryption context?

Hybrid. Use dedicated keys for high-compliance tiers (PCI, HIPAA, premium enterprise clients with explicit key-isolation requirements). Use pool keys with encryption context + key policy conditions for cost-efficient base tier tenants. At 10,000 tenants, full dedicated costs $10,000+/month in KMS key storage alone — the hybrid pattern cuts that dramatically while preserving isolation for the tenants that matter. The encryption context tenant_id binds every ciphertext to its tenant and prevents cross-tenant decrypt even on a pooled key.

Q4 — How do I implement multi-tenant isolation for a SaaS with 10,000 tenants?

Map isolation to commercial tier. Platinum tier (top 1%) gets account-per-tenant with dedicated KMS keys and dedicated VPC. Gold tier gets VPC-per-tenant in shared accounts with dedicated KMS keys. Silver tier gets namespace-per-tenant (Kubernetes) + row-level-per-tenant (DB) with pool KMS keys bound by encryption context. At scale, the hybrid is the practical answer; pure account-per-tenant runs into Organizations account-limit and operational-cost walls.

Q5 — What is the right edge security layering for a public-facing greenfield SaaS?

CloudFront at the edge (origin obfuscation, caching, edge rejection) → WAF on CloudFront (managed rule groups for OWASP, custom rate limits, bot control) → Shield Advanced (DDoS, SRT, cost protection) → origin (ALB / API Gateway / S3) locked down to accept only CloudFront via OAC or VPC origin. For private content, CloudFront signed URLs / signed cookies scope access to specific principals for specific durations. Firewall Manager pushes baseline WAF policy across all public endpoints in the organization so no tenant-account endpoint ships without WAF.

Q6 — How do GuardDuty and Detective work together?

GuardDuty detects; Detective investigates. GuardDuty raises a finding — "role X accessed from Tor exit node" — and in minutes, the analyst pivots to Detective, which shows that role's 30-day activity graph: every resource it touched, every IP that assumed it, every related role with similar behavior. Detective is read-only and does not generate findings itself; it consumes CloudTrail, VPC Flow Logs, GuardDuty findings, EKS audit logs. Both are delegated-admin from the security account, and both should be enabled on day zero of a greenfield.

Q7 — Is Shield Advanced worth $3,000/month for a new SaaS?

Usually yes for any business-critical workload with SLAs. Benefits: 24/7 engagement with AWS Shield Response Team during attacks, DDoS cost protection (scaling costs during DDoS are refunded), advanced application-layer DDoS detection, WAF at no extra cost on protected resources. For a B2B SaaS with enterprise SLAs, one DDoS-related outage costs far more than $3,000. On the exam, "business-critical workload with availability SLA, concerned about DDoS" is a Shield Advanced answer.

Q8 — How do I centralize CloudTrail logs for 50 accounts?

Create an organization trail from the Organizations management account. Deliver to a single S3 bucket in the Log Archive account. Enable S3 Object Lock (compliance mode) and MFA delete. Enable log file integrity validation. Enable CloudWatch Logs delivery for real-time monitoring. SCPs prevent member accounts from creating their own trails that could be tampered with or that duplicate charges. The Log Archive account has no human users; access for investigation is via break-glass roles audited separately. This is the canonical pattern; the SAP-C02 exam expects it.

Q9 — What is the role of Amazon Verified Permissions in a new SaaS design?

Verified Permissions handles application-layer authorization — not "can user authenticate" (that is Cognito or the IdP) but "can this authenticated user perform this action on this resource." Define policies in Cedar. The application calls the Verified Permissions API with the principal, action, resource, and context; gets a permit/deny decision. Use cases: tenant users with fine-grained roles (admin, editor, viewer), feature-flag-gated capabilities, attribute-based access control (this user from this department can edit this document class). Verified Permissions replaces homegrown RBAC databases and shares the Cedar language with Verified Access — one authorization grammar across the stack.

Q10 — How do permission boundaries let 80 developers self-service without risk?

Central security defines a PlatformDeveloperBoundary that caps permissions — allows Lambda, DynamoDB, S3 on specific patterns; denies IAM admin, Organizations, CloudTrail modification. Developer permission sets grant iam:CreateRole but with a condition requiring the new role to attach the boundary. Developers can create any role they want, but that role's effective permissions are bounded. Combined with SCPs preventing deletion of the boundary policy and Access Analyzer detecting unintended external access, 80 developers operate at speed without privilege-escalation risk. This is the scale-safe delegation pattern every greenfield needs.

Further Reading — Official AWS Documentation for New Solutions Security Design

For depth beyond SAP-C02 scope: AWS Well-Architected Security Pillar whitepaper (conceptual anchor), AWS Verified Access documentation (Cedar policies, trust providers, logging), Amazon VPC Lattice documentation (auth policies, mTLS, service networks), AWS KMS Developer Guide (key policies, grants, multi-region keys, encryption context), AWS Private Certificate Authority documentation (CA hierarchy, RAM sharing, certificate templates), AWS SaaS Tenant Isolation Strategies whitepaper (silo/pool patterns and hybrids), AWS WAF / Shield / CloudFront documentation (edge layering), GuardDuty / Detective / Security Hub / Config / Macie / Access Analyzer user guides, and the AWS Security Reference Architecture (SRA) whitepaper.

The AWS Security Reference Architecture is mandatory reading — it codifies the account structure (Management / Log Archive / Security / Shared Services / Workload OUs) that every SAP-C02 greenfield scenario implicitly assumes. re:Invent and re:Inforce recorded sessions from the last two years cover Verified Access, VPC Lattice, Verified Permissions, and KMS at scale with real customer architectures.

Summary — New Solutions Security Design Decision Tree

On exam day for new solutions security design scenarios, run this decision tree:

1. Is the scenario "users accessing internal web applications without traditional VPN"? → AWS Verified Access + Identity Center + Cedar policies.
2. Is the scenario "service-to-service Zero Trust across VPCs and accounts"? → VPC Lattice with auth policies, ACM Private CA for mTLS if cryptographic peer identity is required.
3. Is the scenario "encryption at scale for many tenants"? → KMS hierarchy with pool CMKs + encryption context for base tier, dedicated CMKs for premium tier, Grants for service-level delegation, MRKs for DR.
4. Is the scenario "multi-tenant SaaS isolation"? → Hybrid: account-per-tenant for compliance/premium, VPC-per-tenant for mid-tier, namespace + row-level + envelope-encryption-per-tenant for base tier.
5. Is the scenario "public edge protection for compliance-bound SaaS"? → CloudFront + WAF (managed rules) + Shield Advanced + signed URLs + Firewall Manager baseline.
6. Is the scenario "threat detection from day zero across all accounts"? → GuardDuty (all protection plans, delegated admin, auto-enable) + Detective + Security Hub (FSBP/CIS/PCI/NIST) + Inspector + Macie.
7. Is the scenario "compliance scoring and continuous audit"? → Security Hub standards + Config aggregator with organization conformance packs + Audit Manager frameworks.
8. Is the scenario "immutable logging for audit"? → Organization CloudTrail to Log Archive S3 with Object Lock compliance mode + VPC Flow Logs + WAF logs + lifecycle to Glacier Deep Archive.
9. Is the scenario "human identity for 80 engineers across accounts"? → IAM Identity Center federated from corporate IdP + permission sets + permission boundaries for delegated role creation.
10. Is the scenario "tenant users' in-app authorization"? → Amazon Verified Permissions with Cedar policies.

Master these ten branches and you will answer every new solutions security design question on SAP-C02 Task 1.2 correctly. New solutions security design rewards architectural breadth more than deep single-service knowledge — study how the services compose, and the right new solutions security design will always emerge from the stem's explicit and implied requirements.