Working with Amazon S3: File Sharing with IAM & SNS

Summary & architecture

The lab builds a small file-sharing system. An external user uploads or deletes product images inside cafe-23melo23/images/. Every mutation triggers an SNS notification that emails the admin. The interesting parts are which events fire (created / removed only, not get-object) and which operations the external user is denied (anything outside the prefix, anything that changes ACLs or bucket-level metadata).

Task 1 — CLI Host, bucket creation & initial sync

Configure the AWS CLI on the pre-provisioned CLI Host with the lab's voclabs credentials, create the share bucket, and push the three seed images into the images/ prefix.

Configure the CLI

aws configure was run with the lab's Access Key / Secret Access Key, region us-west-2, output format json. Standard step, no evidence needed — the next commands prove the profile is active.

Create the bucket and sync the seed images

Bucket name chosen: cafe-23melo23 (must start with cafe-, lowercase only, globally unique). Three product images were synced from ~/initial-images/ under the images/ prefix: Cup-of-Hot-Chocolate.jpg, Donuts.jpg, Strawberry-Tarts.jpg.

aws s3 mb s3://cafe-23melo23 --region 'us-west-2'

aws s3 sync ~/initial-images/ s3://cafe-23melo23/images

aws s3 ls s3://cafe-23melo23/images/ --human-readable --summarize

Task 2 — IAM: the mediaco group & least privilege

The lab pre-creates a group called mediaco with two attached policies: IAMUserChangePassword (AWS-managed, lets the user rotate their own password) and mediaCoPolicy (custom, the interesting one). mediacouser is a member of the group and inherits both.

The three Sid statements in mediaCoPolicy

Sign-in evidence as mediacouser

An access key was minted for mediacouser (kept for Task 5's CLI tests) and the console sign-in link was used in an incognito session to keep both identities active in parallel.

Task 3 — Testing permissions: happy path & the expected deny

Three authorized operations from the console as mediacouser, then the unauthorized case that the policy is designed to block.

Task 4 — SNS event notifications

Four moving parts: create the SNS topic, give S3 permission to publish to it, subscribe an email endpoint, and finally attach the event configuration to the bucket. No console screenshots from this segment — the JSON below is the evidence, and Task 5 closes the loop with the delivered emails.

4.1 — Create the topic

A Standard SNS topic named s3NotificationTopic was created in the same region as the bucket. The topic's ARN was copied for the next two JSON files.

4.2 — Topic access policy (S3PublishPolicy)

The topic needs an access policy that lets the S3 service principal (s3.amazonaws.com) publish messages, but only when those messages originate from this bucket. The ArnLike condition on aws:SourceArn is what enforces that scoping.

{
  "Version": "2008-10-17",
  "Id": "S3PublishPolicy",
  "Statement": [
    {
      "Sid": "AllowPublishFromS3",
      "Effect": "Allow",
      "Principal": {
        "Service": "s3.amazonaws.com"
      },
      "Action": "SNS:Publish",
      "Resource": "arn:aws:sns:us-west-2:587674602776:s3NotificationTopic",
      "Condition": {
        "ArnLike": {
          "aws:SourceArn": "arn:aws:s3:*:*:cafe-23melo23"
        }
      }
    }
  ]
}

4.3 — Email subscription

Created an Email subscription to the topic with a personal address as the endpoint. AWS sent the standard confirmation email — clicking Confirm subscription activated the endpoint. From this point on the topic has one confirmed deliverable subscriber.

4.4 — Wire the bucket to the topic

The event-notification configuration JSON was written into s3EventNotification.json on the CLI Host. It subscribes to two event families and filters on the images/ prefix only — anything outside images/ is silently ignored by the rule.

{
  "TopicConfigurations": [
    {
      "TopicArn": "arn:aws:sns:us-west-2:587674602776:s3NotificationTopic",
      "Events": ["s3:ObjectCreated:*", "s3:ObjectRemoved:*"],
      "Filter": {
        "Key": {
          "FilterRules": [
            { "Name": "prefix", "Value": "images/" }
          ]
        }
      }
    }
  ]
}

aws s3api put-bucket-notification-configuration \
  --bucket cafe-23melo23 \
  --notification-configuration file://s3EventNotification.json

Immediately after attaching the configuration, S3 sent a sanity-check event: a payload with "Event": "s3:TestEvent" arrived at the mailbox. That message confirms the topic-access-policy chain works end-to-end before any real object event fires.

Task 5 — End-to-end test from mediacouser via CLI

Switched the CLI Host's profile to mediacouser's access keys (second aws configure pass) and exercised put, get, delete, and the deny case for put-object-acl. Only put and delete generate SNS emails — get does not, because the filter only matches ObjectCreated:* / ObjectRemoved:*.

Errors & expected denials — the proof

Three documented failures during the lab. The first is a real user mistake worth keeping as a lesson. The other two are the policy doing its job.

Concepts & takeaways

• Prefix-scoped IAM policies are how S3 implements multi-tenant buckets without splitting buckets. The wildcard arn:aws:s3:::cafe-*/images/* on Sid 3 is what isolates mediacouser from anything outside the contract.
• S3 cannot send email. The canonical pattern for "notify me on bucket change" is S3 event notification → SNS topic → email subscription. The topic's access policy + the bucket's notification configuration are the two halves of the link; both must be in place.
• The ArnLike condition on aws:SourceArn inside the SNS access policy prevents the confused-deputy problem — only this specific bucket can publish to this topic, not any other S3 bucket in the account.
• Event filters are part of the design. Subscribing to s3:ObjectAccessed:* would have generated one email per read, drowning the admin in noise. Choosing only ObjectCreated:* and ObjectRemoved:* is the correct trade-off for an audit-of-changes use case.
• Default deny in IAM means a missing action in the policy behaves the same as an explicit deny. The mediacouser case study shows three examples: bucket metadata, ACL mutation, root-of-bucket uploads — none of them require an explicit Deny statement to be blocked.

CLI reference