Storage & Encryption

S3, KMS, and Secrets Manager all live in the DataStack, added the same way DynamoDB and messaging are: pass a config array, get a construct, and read identifiers back from SSM. The security rule is absolute — only ARNs/identifiers reach SSM, never secret material.

S3 — AtfS3

Buckets default to secure settings (versioning on, public access blocked). DataStack writes s3/{baseName}/bucketArn and s3/{baseName}/bucketName to SSM.

KMS — AtfKms

Created CMKs default to key rotation on and are aliased. DataStack writes kms/{baseName}/keyArn and kms/{baseName}/keyId.

Secrets Manager — AtfSecretsManager

Only the secret ARN is written to SSM (secrets/{baseName}/secretArn) — the secret value is never written to a parameter and never appears in a synthesised template. Consumers resolve the value at runtime from the ARN via the Secrets Manager API or a CDK grant. Writing secret material into an SSM String parameter would expose it in plaintext, a five-pillars security violation.

Known limitation: created-CMK encryption of tables/buckets

There is currently no DataStack hook to use an AtfKms-created key as a Dynamo or S3 encryptionKey. The created key object only exists after AtfKms runs at synth, and the static config arrays can’t carry the runtime IKey. To encrypt a table/bucket with a created CMK today, wire it in raw CDK in your own stack. This is a tracked framework gap, not a docs gap.

Where to go next

• Security Perimeter for WAF and SES.
• Importing Existing Resources to reference an existing bucket/secret/key by ARN.