Security Hardening: KMS, Least-Privilege IAM, and Network isolation

Lessons 01 to 13 built a lake that works: buckets, formats, Iceberg, ingestion, a catalog, transformation, a query layer, a warehouse, orchestration, Lake Formation governance, and PII handling. Everything you built is also a set of decisions an attacker can read and a misconfiguration can undo. A CMK whose key policy never delegated to the account, a bucket policy that pins traffic to a VPC endpoint nobody uses, an SCP written with the strict operator instead of IfExists, a rotation Lambda missing one KMS action: each fails in a way that names the last hop in the error, not the broken control.

This lesson hardens the lakehouse in the order AWS's own security guidance lays it out: keys → identities → storage defaults → network → organisation guardrails → secrets → audit. The teaching rule: default is not enforced, allowed is not reachable, and reachable is not audited. Every number below is dated to October 2026, and every policy sketch is one you can paste into a sandbox before it touches production.

In this lesson you will:

• choose between customer managed, AWS managed and AWS owned keys for each lakehouse data class, and justify it with audit and blast-radius needs;
• compose key policy and IAM correctly, delegation first, identity allow second, explicit deny always winning, and write the grant + grant token flow that Lake Formation and Glue automation needs;
• do the bucket-key cost math and show what rotation does and does not re-encrypt;
• pick multi-Region keys only for the two patterns they exist for: cross-Region replication and cross-Region consumers;
• apply service roles, external ID, condition keys, session policies and boundaries as one least-privilege system;
• build S3 access control in construction order: Object Ownership, account-level Block Public Access, deny-insecure statements, network pinning, prefix scoping;
• price gateway endpoint vs interface endpoint vs NAT for the same S3 traffic, with October 2026 numbers;
• write data-perimeter SCPs (Region deny, unencrypted-PutObject deny, public-ACL deny) with the IfExists operators that keep them from breaking Athena and Glue;
• wire Secrets Manager rotation for Glue JDBC credentials, including the KMS grant that everyone forgets;
• ship four worked JSON artifacts: a least-privilege Glue job role, a cross-account S3+KMS role with external ID, an SCP set, and a scoped CloudTrail data-event selector with its bill;
• study Siemens's 800-account Security Lake, a sourced October 2026 update box, three interactive checks, six diagrams and eleven exam-style questions.

---

1. What a hardened lake is defending against

AWS's own framing for the control set in this lesson is blunt: the threat is "UNINTENDED DATA DISCLOSURE DUE TO MISCONFIGURATIONS", not a novel exploit, but a bucket policy someone copied, a key policy someone never edited, a region somebody left open (AWS re:Inforce 2023 session IAM301, d1.awsstatic.com deck, accessed 2026-10-11). A data perimeter is "a set of preventive controls that helps ensure that only your trusted identities are accessing trusted resources from expected networks", and it has exactly three areas, identity, resource and network (AWS Security Blog, Establishing a data perimeter on AWS, page date 2025-08-28).

Two habits make the rest of this lesson work. First, write denies, not just allows, the S3 team's own re:Invent guidance is "Always block the access ('Deny') when… the request doesn't match your policy" (STG304, re:Invent 2024 deck, accessed 2026-10-11). Second, test in a non-production account first, AWS's data-perimeter posts say so explicitly: "We recommend that you test and deploy these policies in a test account before you apply them in a production account" (AWS Security Blog, 2024-11-13).

---

2. KMS for lakes: CMKs, AWS managed, AWS owned

2.1 The three ownership tiers, on the axes that matter for a lake

AWS's KMS documentation draws the tiers by ownership and visibility, not by strength: "AWS KMS keys (KMS keys) are the fundamental logical entities of AWS KMS"; "AWS owned keys are KMS keys that AWS services use to protect your data… You can't view or manage AWS owned keys"; and "Resource policies for AWS managed keys are managed by the corresponding AWS service" (KMS Developer Guide: Concepts, accessed 2026-10-11).

The lakehouse rule: CMK when you must prove who decrypted what class of data; AWS managed when convenience is enough and no one will ask you to enumerate decrypts. Never expect an AWS owned key to appear in your key list; that absence is by design, not a bug (KMS concepts, accessed 2026-10-11).

• 📚 Did you know? The AWS managed tier in the console is partly legacy: AWS's KMS docs say "The AWS managed keys that you see in the console are legacy AWS managed keys… AWS services use a different set of AWS managed keys than the ones that appear in the console", and legacy keys carry the aws/service alias pattern. That is why you can see aws/s3 in a console list yet still find services quietly encrypting with keys you will never be shown (KMS concepts, accessed 2026-10-11).

2.2 Key policy is the gate; IAM is the second gate

Four sentences from the key-policies guide decide almost every KMS support ticket you will ever work:

1. "Key policies are the primary way to control access to KMS keys."
2. "Every KMS key must have exactly one key policy, which is created when you create the KMS key."
3. "An IAM principal in the same account as the KMS key can use IAM policies to allow access to the KMS key only if the key policy for the KMS key allows the principal."
4. "…an IAM deny statement in an IAM policy takes precedence… you can use IAM deny statements in IAM policies to prevent principals in the same AWS account from using the KMS key, even if the key policy allows it." (KMS Developer Guide: Key policies, accessed 2026-10-11)

Read it as two gates that compose rather than stack: the key policy answers "is this account or role allowed to use this key at all?"; IAM answers "may this specific caller use it for this action right now?" Cross-account use is always via the key policy: an identity policy in the other account is inert until the producer's key policy names it. And an IAM deny bites regardless of what the key policy said.

Worked example E1: a key policy that actually delegates (S3 + Glue + a cross-account reader)

Note the shape: arn:aws:iam::<account>:root means this account, via its IAM policies, not "the root user is privileged"; service principals get aws:SourceAccount/aws:SourceArn conditions so the delegate cannot be pointed at someone else's bucket; and the cross-account reader receives decrypt only, never kms:*. If you replaced the first statement's principal with "*" you would have the canonical hole. If you had only an IAM allow in account 444455556666 and no statement four, the analyst would fail with an error that names kms:Decrypt and teaches them nothing (F1-class failure: "I enabled the CMK but the service still can't encrypt").

2.3 Grants and grant tokens: the machine-to-machine layer

Grants are the temporary-permission channel that services and SDK flows use instead of rewriting your key policy: "A grant is an alternative way to set permissions for AWS KMS keys"; "Each grant applies to only one KMS key"; "You can't use a grant to deny access"; and "CreateGrant is the only AWS KMS API operation that returns a grant token" (KMS Developer Guide: Grants, accessed 2026-10-11).

The token exists because grantee and encryption-context changes are eventually consistent: "A grant token… makes the permissions specified in a grant available immediately rather than after eventual consistency", and the full grant list settles "within five minutes". Pass the token into the follow-on Encrypt/GenerateDataKey call or your brand-new grant will appear broken for minutes.

Worked example E2: the CreateGrant + token flow for a Lake Formation / Batch re-encrypt job

The call sequence matters more than the JSON:

Use grants for exactly three lakehouse patterns: S3 Batch Operations re-encrypts, service flows that need GenerateDataKey for ten minutes, and Lake Formation / metastore-adjacent automation where you cannot afford to edit a key policy per run. AWS's own guidance is to pair them with IAM and key policies rather than replace them: "We recommend using IAM policies and key policies together… Consider using grants to give temporary permissions to applications that are running on EC2 instances" (KMS, key policy vs IAM policy, accessed 2026-10-11). A forgotten grant is a standing privilege, and RetireGrant/RevokeGrant are the cleanup APIs, nobody audits what they never list.

• 📚 Did you know? KMS deliberately splits encrypt-side and decrypt-side permissions so that a "write-only" pipeline is expressible: GenerateDataKeyWithoutPlaintext returns only the wrapped data key, and the plaintext use still needs kms:Decrypt by the caller (AWS KMS service authorization reference, accessed 2026-10-11). That is why a Glue job role usually needs kms:Decrypt and kms:GenerateDataKey, while an ingestion role that only ever wraps can be given the narrower pair.

2.4 Bucket keys: the highest-ROI toggle on any analytics bucket

"By default, Amazon S3 encrypts all new data when it is written to an S3 bucket": with SSE-S3 since 2023-01-05, at no additional cost, but objects under a KMS default-encryption key "are charged at the KMS request rate of $0.03 per 10,000 requests, plus the standard S3 request charge, even when the encryption is applied automatically" (S3: data protection; S3: Using SSE-KMS, accessed 2026-10-11). The bucket key exists to collapse those calls: "Using a bucket-level key for SSE-KMS can reduce AWS KMS request costs by up to 99 percent by decreasing the request traffic from Amazon S3 to AWS KMS" (S3: Reducing the cost of SSE-KMS with Amazon S3 Bucket Keys, accessed 2026-10-11).

Worked example E3: bucket-key cost math on a hot dashboard read path (as of Oct 2026)

Smaller volumes still show the shape: 5,000 encrypted object GETs cost $0.015 in KMS requests without a bucket key: trivial; which is exactly why teams forget to enable the toggle until the dashboard traffic arrives. Two exclusions to memorise: bucket keys are not supported for DSSE-KMS, and DSSE-KMS is not supported for S3 Replication (S3: bucket-key and Using SSE-KMS pages, accessed 2026-10-11), so you cannot stack "maximum encryption" features.

2.5 Rotation: three different meanings, only one of them re-encrypts anything

AWS states the limit flatly: "key rotation will not mitigate the effect of a compromised data key" (KMS, Rotating AWS KMS keys, accessed 2026-10-11). Eligibility is also a wall, not a preference: automatic rotation supports only symmetric encryption KMS keys with key material AWS KMS generated (KeySpec SYMMETRIC_DEFAULT, KeyOrigin AWS_KMS), asymmetric, HMAC, imported material and custom key stores need manual or on-demand rotation. Two operational notes worth carrying: backing keys accumulate so old ciphertext keeps decrypting, and "the first two rotation generations of backing keys incur a full monthly key charge" (same page), so a long-lived CMK fleet is a small but non-zero monthly line.

2.6 Multi-Region keys: for CRR and cross-Region consumers, nothing else

"Multi-Region keys are AWS KMS keys that have the same key material and the same key ID in different AWS Regions"; you create a primary in one Region and "replicate the MRK into the same AWS account in other AWS Regions"; you cannot convert an existing key into a multi-Region key or back again; and "each multi-Region key counts as one KMS key in your account for AWS KMS quotas and for calculating your AWS KMS costs" (KMS: Multi-Region keys, accessed 2026-10-11). Replicas carry the mrk- prefix in their key IDs.

The S3 cross-Region replication payoff: "AWS S3 encrypts each object version with a data key that is encrypted with the KMS key in the source Region… If you use a related multi-Region key, Amazon S3 decrypts and re-encrypts the data keys in the destination Region": the plaintext data key never leaves the destination Region, and you avoid the cross-Region key hop you would otherwise pay for when replicating to a different key.

Worked example E4: MRK bill and CRR decision (as of Oct 2026)

Two hard edges: an SSE-KMS key must be in the same Region as the bucket ("when you use SSE-KMS encryption with an S3 bucket, the AWS KMS keys must be in the same Region as the bucket": S3, accessed 2026-10-11), and MRK key material cannot be exported. If your replication is same-Region, stop reading this subsection and keep single-Region keys.

2.7 The per-service KMS matrix

Read this table as "who must be in the key policy, and what the caller needs in IAM". Service principals and recommended ARN patterns come from the KMS service-integration page (accessed 2026-10-11).

• 📚 Did you know? One Glue security configuration is four separate encryptables, and teams routinely cover three: S3 intermediate data, CloudWatch Logs, job bookmarks (SSE-KMS only), and Spark shuffle/spill (SSE-S3 only). The bookmarks are the sleeper: a bookmark is the pointer to what has already been processed, so leaving it on the default is both a correctness risk and a leak surface (Glue security-configuration docs, accessed 2026-10-11).

---

3. IAM patterns: service roles, external ID, condition keys, sessions, boundaries

3.1 Service roles: the trust policy is the permission

Every engine in this course runs under a service role whose trust policy names one service principal. The pattern is identical across the stack: the principal glue.amazonaws.com for jobs, lakeformation.amazonaws.com for the registered-location role, encryption.athena.amazonaws.com for workgroup result encryption, redshift.amazonaws.com for cluster paths, logs.amazonaws.com for log-group encryption. The identity policy then does the scoping; this is the division of labour: trust decides who can create the session; identity policy decides what the session may do.

Lake Formation's role is the clearest example: "Lake Formation supplies temporary credentials that the caller, such as Amazon Athena, uses to access the data", and for LF-registered locations "You must specify an IAM role… This role is called the registered-location IAM role" (LF Developer Guide: Underlying data access permissions, accessed 2026-10-11). The consumers (Athena, Redshift Spectrum, QuickSight) call lakeformation:GetDataAccess, and that action must carry Resource: "*" because "AWS Lake Formation does not support specifying a resource ARN in the Resource element of the IAM policy" (LF service authorization reference, accessed 2026-10-11).

3.2 External ID: the confused-deputy guard, in the trust policy

"The confused deputy problem is a security issue that can arise when one service is tricked into using its permissions on behalf of another principal", and "The external ID helps prevent a confused deputy problem when you use the AssumeRole operation" (IAM User Guide: Providing access to third parties, accessed 2026-10-11). Two properties decide where it belongs:

• AWS "does not treat the external ID as a secret… it is not a secret, it's a shared identifier… it should be unique to the customer", so it authenticates intent, not identity. Real authentication remains the trusted principal in the trust policy.
• Length is 2–1,224 characters (IAM quotas, accessed 2026-10-11).
• It lives in the role trust policy under sts:ExternalId: never in the KMS key policy and never in an identity policy. Putting it in the key policy is the single most common placement error (F20-class).

Worked example E5: the cross-account S3 + KMS role with external ID

Three documents must agree: the producer's bucket policy, the producer's key policy, and the consumer's role trust plus identity policy. Nothing else needs editing.

The producer side (not repeated here) is two statements in the style of E1: a bucket policy allowing s3:GetObject/s3:PutObject on arn:aws:s3:::shared-bronze/ingest/* to arn:aws:iam::444455556666:role/lake-reader, and a key policy delegating kms:Decrypt/kms:GenerateDataKey/kms:DescribeKey to that same role ARN. The partner then calls:

If your consumer is your own second account rather than a third party, the external ID is optional, but it is cheap hygiene, and it is 2 to 1,224 characters, unique per customer, and not a secret (IAM, third-party access, accessed 2026-10-11). What it is not: an authentication factor. The trusted principal ARN does the authenticating; the external ID stops a partner from being tricked into assuming your role when it meant another customer's.

3.3 The condition keys this lesson actually uses

The wildcard rule from the IAM condition-key page is non-negotiable: "Don't use wildcard values (*) with aws:SecureTransport, aws:SourceIp, aws:SourceVpce, aws:SourceVpc, aws:PrincipalOrgID" (IAM: condition operators and keys, accessed 2026-10-11).

3.4 Session policies and permission boundaries: the intersection rule

All three "maximum permission" filters behave the same way, and AWS's wording is precise:

• Permission boundary: "an advanced feature for using a managed policy to set the maximum permissions that an identity-based policy can grant to an IAM identity"; "An entity's permissions boundary doesn't give the entity any permissions" (IAM: permissions boundaries, accessed 2026-10-11).
• Session policy: passed on AssumeRole, applies to that session only.
• SCPs: "they specify the maximum permissions for member accounts"; "SCPs don't grant permissions… they filter" (Organizations: SCPs, accessed 2026-10-11).

Evaluation: final permissions = identity ∩ resource ∩ session ∩ boundary ∩ SCP, and any explicit deny in any applicable policy wins. Boundaries are how you let a platform team create roles without letting them escalate to iam:* or kms:*; session policies are how a job-runner role can be handed a tighter context for one run.

Worked example E6: boundary + session policy as a real intersection

The documented trap: "NotPrincipal… when you use NotPrincipal in a deny statement together with a permissions boundary… the deny statement might apply unexpectedly" (IAM: permissions boundaries, accessed 2026-10-11). Prefer positive Principal scoping or aws:PrincipalArn conditions over NotPrincipal denies.

3.5 Worked example E7: the least-privilege Glue job role, end to end

One job, one role, four encryptables, zero wildcards. This is the identity half of a Glue security configuration; the security configuration itself (S3 SSE-KMS + CloudWatch SSE-KMS + bookmark SSE-KMS, all on the same CMK, all in the same Region as the job) is the encryption half.

Trust policy for the same role, and the one line that makes the whole thing assumable:

What makes it least-privilege rather than "a policy with some ARNs in it": one key ARN, two bucket roots with a s3:prefix condition on the List, a log-group prefix that matches only this job's security configuration, a single Glue database, and one secret. Add a permissions boundary (E5's ceiling) on top and even a compromised job cannot mint itself iam:*. The KMS statement is not optional: without it the job dies on the first encrypted read with an error naming kms:Decrypt rather than the missing grant (F1-class).

---

4. S3 hardening, in construction order

Access control on a lake bucket is not a checklist you complete in any order; it is a stack where each layer assumes the one below it. The order below is the S3 team's own re:Invent order (STG304, accessed 2026-10-11): account and bucket Block Public Access, Access Analyzer to find exposure, Object Ownership with ACLs disabled, bucket keys for SSE-KMS, gateway endpoints, and deny-first policies.

4.1 Object Ownership: ACLs off, bucket owner owns everything

"Object Ownership is a bucket-level setting that you can use to disable access control lists (ACLs)… When Object Ownership is set to Bucket owner enforced, ACLs are disabled, and the bucket owner owns every object" (S3: Object Ownership, accessed 2026-10-11). The recommended use case in AWS's own words includes "data lakes". Two consequences: an upload carrying ACL headers returns AccessControlListNotSupported (a delightful "why did my copy job start failing" incident), and cross-account object ownership disputes stop existing because there is nothing left to dispute.

4.2 Block Public Access: four settings, account level, organisation level

The four settings are BlockPublicAcls (ACLs at bucket and object level), IgnorePublicAcls (S3 ignores public grants it finds), BlockPublicPolicy (bucket policies that go public are rejected with "Access Denied"), and RestrictPublicBuckets ("even if the bucket policy allows public access… Amazon S3 doesn't allow public access", while same-account access is not blocked) (S3: Block public access, accessed 2026-10-11). Two scope rules decide whether your control actually exists: account-level settings "are applied to all buckets in the account, even those created after the settings are turned on", and "You can apply all Block Public Access settings as a single, unified policy at the AWS Organizations level". Leaving org-level BPA off means every future bucket starts potentially public until four toggles are flipped by someone who remembers.

4.3 The deny-first bucket policy

Read the last two statements together: aws:SourceVpce is present only when the call came through an endpoint, and aws:SecureTransport/aws:SourceIp/s3:TlsVersion are redacted when AWS services call S3 on your behalf: "To avoid this behavior, include the aws:PrincipalIsAWSService condition key set to false in the same statement as the condition keys" (S3: Amazon S3 policy keys, accessed 2026-10-11). Without that carve-out you either break Athena/Glue/Lake Formation silently or believe you have a TLS-only bucket that your service path ignores. And remember: default encryption is not enforcement: "Default ≠ enforced"; only the DenyUnencryptedPutObject statement makes SSE-KMS mandatory.

---

5. Network isolation: gateway endpoints, PrivateLink, NAT and endpoint policies

5.1 The three paths out of a VPC, priced

Gateway endpoints are "a virtual routing device… you access the endpoint using a route in your route table", and you attach an endpoint policy to allow or deny (VPC: Gateway endpoints, accessed 2026-10-11). Interface endpoints are billed differently: "Endpoints are billed for each hour they are available in each Availability Zone, with a full hour charged regardless of usage" (AWS PrivateLink pricing, accessed 2026-10-11).

Worked example E8: NAT vs gateway endpoint for 500 GB/month of S3 traffic (as of Oct 2026)

That is the classic lakehouse saving: free, and it buys you a condition key. Keep the NAT for non-S3 egress only.

Worked example E9: the private stack's real bill (3 interface endpoints)

Mix deliberately: gateway for S3 and DynamoDB, interface only where no gateway exists, and never assume "VPC endpoint = free": only S3 and DynamoDB get the free tier.

5.2 Endpoint policies: a fifth deny surface

An endpoint policy applies to calls that traverse that endpoint, independent of the identity policy, which makes it the natural home for "no key deletions from this VPC" or "only this secret". AWS's own Secrets Manager example "allows secretsmanager:GetSecretValue on a specific secret ARN and denies secretsmanager:DeleteSecret" (Secrets Manager, VPC endpoints, accessed 2026-10-11). For Lake Formation, the endpoint service name is com.amazonaws.region.lakeformation, and endpoint policies landed alongside PrivateLink support on 2021-10-11, the sample scopes lakeformation:GetDataAccess, the very call that mints temporary S3/KMS credentials (LF, Connecting via PrivateLink, accessed 2026-10-11).

The foot-gun here is real: an endpoint policy is deny-by-default in effect: omit lakeformation:GetDataAccess from an LF endpoint and the lakehouse stops vending credentials; deny s3:GetObject on the wrong bucket ARN and every query fails. Test in a sandbox (the data-perimeter posts' own instruction).

---

6. Data perimeters: SCPs, RCPs and the three control areas

6.1 The model

"A data perimeter is a set of preventive controls… identity, resource, and network", enforced through "AWS Organizations service control policies (SCPs), AWS IAM resource control policies (RCPs), and… VPC endpoint policies", and AWS is explicit that it is "not a substitute for… fine-grained authorization" (AWS Security Blog, 2025-08-28; IAM, Data perimeter policies, accessed 2026-10-11). The three perimeters map to three questions:

SCPs are the load-bearing mechanics, and their semantics are what people get wrong: "SCPs don't grant permissions, they filter… an SCP never grants permissions"; they "don't affect resource-based policies"; they "don't apply to users or roles in the management account"; and they "don't apply to service-linked roles… or service principals" (Organizations: Service control policies, accessed 2026-10-11).

6.2 The IfExists discipline

The canonical network SCP from the AWS Security Blog (2024-11-13) is built from three non-strict operators for one documented reason: "aws:SourceVpc and aws:SourceVpce are only present in the request context if the call was made through a VPC endpoint". Strip IfExists out and you deny every AWS-service call and every non-VPC call; which is precisely how a data perimeter takes down Athena, Glue and Lake Formation on a Friday.

Worked example E10: the four-statement SCP set (paste into a non-production OU first)

Three teaching points on this document. First, statement one's NotAction allow-list of global services (CloudFront, IAM, Organizations, Route 53, Support, STS) is the exact shape of both the IAM docs' Region-deny example and the Control Tower guardrail, "AWS Control Tower provides a region deny policy… You cannot exclude your home Region" (Control Tower, primary Region deny policy, accessed 2026-10-11). Second, statement two pairs StringNotEquals with Null: true so that a client sending no encryption header is also denied, the two conditions together cover "wrong algorithm" and "no algorithm". Third, Deny on s3:PutBucketPublicAccessBlock prevents disabling BPA rather than enabling it; do not confuse the direction. AWS ships curated versions of all of these in aws-samples/service-control-policy-examples, whose README says the examples are "a starting point… test in a non-production environment", fork those, never hand-write Deny * on a production organisation.

---

7. Secrets rotation for Glue JDBC credentials

A Glue JDBC connection should never hold a plaintext password: store it in AWS Secrets Manager, encrypt it with a CMK, and let the rotation schedule do the work. Rotation is a four-step staging-label protocol, and the order is not cosmetic:

1. createSecret: Lambda creates the new version and moves the AWSCURRENT staging label to it;
2. setSecret: Lambda tells the database to change the credentials;
3. getSecretValue with AWSCURRENT: Lambda retrieves and tests the new credentials;
4. removeSecret: the AWSPREVIOUS label and the old version are deleted.

(Secrets Manager: Rotating secrets that use AWS Lambda, accessed 2026-10-11.)

Worked example E11: the rotation Lambda role for a Glue JDBC source

The failure drill worth running once in a sandbox: revoke the KMS statement, trigger rotation, and watch it fail at step 3 with an error that names the secret or the database rather than the key. Then restore it. That single experiment teaches F25 better than any table.

---

8. Audit: one org trail, selective data events, and the bill you must scope

CloudTrail is the evidence plane, and its pricing has one trap: management events are cheap, data events are not. "By default, CloudTrail doesn't log data events"; "Data events… are often high-volume activities… you are charged an additional fee for logging data events"; and you select them with advanced event selectors, "You can't mix basic event selectors and advanced event selectors in a trail" (CloudTrail, Logging data events, accessed 2026-10-11).

Worked example E12: scoped data events and what they cost

• 📚 Did you know? GuardDuty S3 protection and your own audit trail are different objects. GuardDuty "evaluates CloudTrail management events and CloudTrail data events for S3" and "enables its own trail for S3 protection, you don't need to configure CloudTrail data events yourself" (GuardDuty, S3 protection, accessed 2026-10-11). So a bucket can be monitored while your evidence trail logs nothing: detection ≠ evidence retention. Keep your own org trail with scoped selectors, ship it to a separate log account, and protect the log bucket with an SCP that denies s3:DeleteBucketPolicy and cloudtrail:StopLogging (Section 6.2).

---

2026 Updates (as of October 2026)

---

Real-World Case Studies

AWS publishes what these controls look like at production scale. Every figure below is customer- or AWS-claimed and unaudited, with the source and date named so you can check it: the examinable point is the pattern, not the marketing.

Case A, Siemens: an 800-account security data lake that pays for itself

The lesson for this course is structural: Siemens's funnel is your Section 8 audit design: an organisation-wide collection point on S3, an endpoint-and-policy-filtered path out, and a per-prefix decision about what gets the expensive treatment. Note also what the case does not claim: Security Lake is a security-log aggregation service, not AWS Lake Formation. Governance stories (IAS, FanDuel) belong to Lesson 12; this one is about volume, retention and the cost of evidence.

Case B, USAA: measure the perimeter before you enforce it

Read the 70% as a case datum from a public deck, not an industry benchmark. The durable lesson is the sequence: analyse first (CloudTrail Lake or Athena over your own events: remember to enable the S3 data events, or the analysis has nothing to read), then enforce, then re-measure.

---

Practice Questions