Amazon S3 Bucket Policy and KMS Condition Reference

When connecting Amazon S3 to Data 360, you configure permissions across multiple AWS policy layers: the S3 bucket policy, the KMS key policy, and the IAM user policy. These are quick-lookup tables for required permissions, condition placement, and common error resolution.

Server-Side Encryption with AWS Key Management Service (SSE-KMS) encrypts your S3 objects at rest by using customer-managed KMS keys. When your S3 bucket uses SSE-KMS, Data 360's access flow involves two AWS services: S3 for object retrieval and Key Management Service (KMS) for decryption.

When Data 360 retrieves an SSE-KMS encrypted object from your S3 bucket, two API calls happen in sequence. Both calls share the principal (the Data 360 IAM user), but they differ in which one physically calls the API and what network context the request carries.

The Data 360 IAM user calls the S3 GetObject API to retrieve your object. This request travels through your VPC endpoint, so it carries VPC context attributes such as aws:SourceVpce and aws:SourceVpc. Your bucket policy can evaluate these attributes to enforce network restrictions.

S3 detects that the object is encrypted with SSE-KMS and automatically calls the KMS Decrypt API to retrieve the data key. While S3 is the caller that physically makes this API request, the principal on the KMS request remains your Data 360 IAM user (S3 is acting on their behalf). This is why your KMS key policy must grant Decrypt access to the Data 360 IAM user, not to the S3 service.

However, because the call originates in S3's service infrastructure (not the IAM user's client), the request doesn't carry your VPC's network context. This means aws:SourceVpce and aws:SourceVpc conditions on the KMS key policy will not match, even though the principal is correct.

Your Data 360 IAM user is the principal on the KMS request, but S3 is the caller that physically makes the API call. Identity-based conditions (who is requesting) work correctly on the KMS key policy. Network-based conditions (where the request originates) don't, because the call originates from S3's infrastructure, not from your VPC endpoint.

This figure describes data flow from the Data 360 IAM user through your VPC endpoint to S3, then S3's service-to-service call to KMS for decryption. The IAM user is the principal on both calls, but only the S3 call carries VPC context.

Don't add aws:SourceVpce or aws:SourceVpc conditions to the KMS key policy. Adding these conditions causes encrypted object retrieval to fail with an AccessDenied error. When S3 decrypts objects that use SSE-KMS, S3's service infrastructure makes the KMS API call. This call doesn't carry your VPC context, so VPC conditions evaluate to false and KMS denies the request.

If your security team verifies whether the configuration satisfies VPC-scoped access requirements, this table summarizes how each control layer contributes.

There's no path for the Data 360 IAM user to decrypt data outside your VPC. Your bucket policy denies requests that don't originate from your VPC endpoint, and your KMS key policy restricts decryption to the S3 service only. These two controls together enforce VPC-scoped access without requiring a VPC condition on the KMS key policy.

Your bucket policy controls who can reach S3. Your KMS key policy controls what can trigger decryption. Don't conflate the two. VPC endpoint restrictions belong at the S3 layer. Scope KMS access to the S3 service via kms:ViaService, not via network conditions.

Activation requires all ingestion permissions plus write and delete access.

Use this table to verify that you apply each condition and permission to the correct policy layer.