Skip to main content
This lesson focuses on securing object storage — specifically Amazon S3 — as part of our “turning up security on storage services” series. We cover practical controls, access patterns, and configuration choices for securely storing user-uploaded images for a mobile application. Topics include pre-signed URLs, server-side encryption options, policy evaluation, logging, Object Lock, VPC endpoints, and recommended best practices. Scenario A startup plans to use S3 to store user-uploaded images for a new mobile app. Requirements:
  • Images must be stored securely (encrypted at rest).
  • Only authorized consumers should be able to access images.
  • Images must be retrievable quickly by the mobile app.
Exam-style options
  1. Store the images in a public S3 bucket and use IAM roles to restrict access to only the application servers.
  2. Store the images in a private S3 bucket, enable server-side encryption, and use pre-signed URLs for temporary access.
  3. Store the images in an S3 bucket with public read access and use bucket policies to restrict access based on IP addresses.
  4. Store the images in a private S3 bucket without encryption and use IAM credentials embedded in the application for access.
Recommended answer Option 2 is best practice: keep buckets private, enable server-side encryption, and provide short-lived access using pre-signed URLs or other temporary credential mechanisms. Avoid public buckets and never embed long-lived IAM credentials in client applications. Enable default encryption when creating buckets (or explicitly set it on existing buckets). How pre-signed URLs work Pre-signed URLs give temporary, scoped access to a specific S3 object without exposing AWS credentials to the client. Typical flow:
  • An authenticated backend (for example, API Gateway → Lambda, or a web server) verifies the user and generates a pre-signed URL using AWS SDKs and its AWS credentials.
  • The backend returns the pre-signed URL to the client.
  • The client uploads or downloads the object directly to/from S3 using the pre-signed URL. The URL contains a signature and an expiry; S3 validates these and performs the scoped operation.
Schematic flow:
  • Application authenticates the user or verifies authorization.
  • Application requests or generates a pre-signed URL for a specific object and action from an AWS component (Lambda/API).
  • The pre-signed URL is returned to the user.
  • The user performs the object upload / download directly against S3 using the pre-signed URL. The URL includes a signature and expiry that S3 validates to allow the scoped operation without the client holding AWS credentials.
Server-side encryption (SSE) options S3 supports multiple server-side encryption mechanisms. Choose based on your compliance and key management requirements. Distinction: server-side vs client-side encryption
  • Server-side encryption: send plaintext to S3; S3 (SSE-S3/SSE-KMS/SSE-C) encrypts data at rest.
  • Client-side encryption: encrypt data within the client before upload; S3 stores encrypted objects and never sees plaintext.
Policy evaluation and access layers for S3 S3 evaluates multiple permission sources simultaneously. A Deny anywhere blocks access. Conceptually there are four layers: S3 uses implicit deny by default: nothing is allowed unless explicitly permitted, and any explicit Deny overrides Allows.
A diagram of AWS S3 policy evaluation showing "Start With DENY" and arrows through IAM Policy, Endpoint Policy, Access Point Policy, and Bucket Policy/ACL, leading to either an Explicit Allow (green) or Explicit Deny (red). Icons above each policy label illustrate the decision flow.
Identity-based policy example A typical IAM policy that grants a principal permission to list buckets and fully access a specific bucket (replace YOUR-BUCKET with your bucket name):
ACLs and Block Public Access
  • ACLs are legacy and generally discouraged in favor of IAM policies and bucket policies.
  • Block Public Access settings (account-level or bucket-level) are a safety net to prevent accidental public exposure and should be enabled unless you have an explicit public use case.
A screenshot of an AWS S3 access control infographic listing four layers (IAM policies, bucket policies, ACLs, and block public access). On the right is the "Block public access" account settings panel showing several checkbox options and Save/Cancel buttons.
Exam-style question: order of evaluation You don’t need to configure an evaluation sequence; AWS evaluates all relevant policies together. Key points for exam and practice:
  • S3 uses implicit deny; nothing is allowed unless explicitly allowed.
  • An explicit Deny in any evaluated policy or setting overrides Allows.
  • Block Public Access can prevent public exposure even if a policy allows it.
  • When diagnosing access issues, review identity policies, resource policies, endpoint/access point policies, ACLs, and Block Public Access settings.
S3 logging, auditing, and encryption at rest S3 offers several auditing and logging features:
  • Server access logging: request-level logs for a bucket, delivered to another bucket.
  • CloudTrail data events: capture S3 object-level API operations for audit trails.
  • AWS Config: monitors and records configuration changes.
  • S3 Inventory + Amazon Athena: generate manifests and run queries for large-scale analysis.
  • S3 Batch Operations: perform bulk actions based on inventory manifests.
Best practices for logging:
  • Deliver server access logs to a separate, private logging bucket (do not deliver logs to the bucket being logged).
  • Secure the logging bucket with encryption and restrictive policies; consider Object Lock for tamper-evidence.
  • Use CloudTrail data events for detailed, auditable object access records when required by compliance.
S3 server access logging example entry Server access logs include requester, request type, bucket, HTTP status, bytes transferred, user agent, and more. Example (trimmed):
Exam-style logging question (answer summary) Enable S3 server access logging and deliver logs to a separate secured S3 bucket. Optionally complement with CloudTrail data events for management and additional object-level auditing.
A screenshot of an AWS exam-style question about an e-commerce company using Amazon S3 that wants to enable secure logging and analysis of bucket access. Four numbered answer options are shown proposing solutions like enabling S3 server access logging to another bucket, using CloudTrail, or AWS Config.
Object Lock and retention modes S3 Object Lock provides WORM (Write Once, Read Many) protection with two modes:
  • Compliance mode: Objects are immutable for the retention period. Even the root user cannot overwrite or delete them until the retention expires. Use this when regulatory or legal requirements demand absolute immutability.
  • Governance mode: Enforces retention but allows users with the s3:BypassGovernanceRetention permission to change or remove retention settings. Use when controlled exceptions by privileged users are acceptable.
Always enable versioning alongside Object Lock to strengthen immutability. Object Lock is stronger for tamper-proof retention than relying only on IAM or bucket policies.
A quiz-style slide asking which Amazon S3 Object Lock modes a pharmaceutical company should use to meet data retention and exception requirements. It shows four numbered answer options recommending combinations of Compliance mode, Governance mode, IAM exceptions, or using standard S3 policies.
Exam-style Object Lock question (summary) If some data must be absolutely immutable while other data allows controlled exceptions:
  • Use Compliance mode for data that must be retained and cannot be deleted or modified.
  • Use Governance mode for data that needs protection but allows controlled exceptions for privileged users.
S3 recovery and analytics workflow (two-account pattern) A robust recovery pattern is to replicate objects to a protected destination account and bucket that has Object Lock enabled. Typical workflow:
  • Replicate (cross-account) objects to a destination bucket with Object Lock and versioning.
  • Enable S3 Inventory in the destination bucket and run Athena queries to produce manifests.
  • Use S3 Batch Operations to copy objects into recovery buckets for remediation or investigation.
  • Integrate CloudWatch alarms and EventBridge rules to detect anomalies and optionally disable or modify replication workflows when suspicious activity is detected.
This two-account pattern increases resilience and ensures you have an immutable copy for forensic analysis or recovery.
A two-account AWS architecture diagram (us_east_1) showing a Source Account where a CloudWatch alarm → EventBridge rule → Lambda disables S3 replication after an anomaly. The Destination Account shows a protected S3 bucket with Object Lock using S3 Inventory, AWS Athena and S3 Batch Operations to generate an object manifest and copy objects into a recovery bucket.
Exam-style legal/retention question (summary) When you must prevent deletion or modification of documents for a specific retention period — even by administrators — enable S3 Object Lock in Compliance mode with versioning enabled. This meets strict legal/retention requirements.
An infographic slide showing a scenario where a legal firm must prevent deletion/overwriting of Amazon S3 documents, asking which S3 feature to use. It lists four options (e.g., enable S3 Versioning, S3 Object Lock with retention/compliance mode, Transfer Acceleration, and S3 Inventory).
VPC endpoints for S3 (privatize traffic) To keep traffic off the public internet, access S3 via VPC endpoints. Two common endpoint types:
  • Gateway endpoint: route-table based, supports S3 and DynamoDB, does not consume IP addresses in subnets. Suitable for most S3 private-access use cases.
  • Interface endpoint (AWS PrivateLink): creates ENIs in subnets and consumes IP addresses; supports many services via PrivateLink and is needed when a question or requirement explicitly demands PrivateLink.
Use cases:
  • Use a gateway endpoint when you require private S3 access without consuming subnet IPs.
  • Use an interface endpoint (PrivateLink) when service integration requires PrivateLink features or when explicitly required.
A cloud architecture diagram showing an on-premises data center and applications connected via AWS Direct Connect or VPN to an AWS VPC. The VPC contains in-VPC applications and VPC endpoints (gateway and interface/PrivateLink) providing access to an AWS S3 bucket.
Exam-style VPC endpoint question (summary) If EC2 instances in a VPC must access S3 without traffic going over the public internet, create an S3 VPC endpoint and add the necessary route to the route table. For S3, a gateway endpoint is typically the default. If a question explicitly requires AWS PrivateLink, choose an interface endpoint. Exam nuance: PrivateLink vs gateway PrivateLink uses interface endpoints (ENIs) and is distinct from gateway endpoints. Gateway endpoints are route-table based and are the standard choice for S3/DynamoDB when you want private access without ENIs. Final recommendations and best practices
  • Keep buckets private by default. Provide client access with pre-signed URLs or short-lived credentials.
  • Enable default encryption (SSE-S3 or SSE-KMS). Use AWS KMS customer-managed keys for stronger controls and auditing.
  • Use Object Lock + versioning for immutable storage and retention requirements.
  • Centralize logging: deliver server access logs or CloudTrail data events into a separate, secured logging bucket.
  • Use VPC endpoints to keep traffic on the AWS backbone when required by compliance or security.
  • Prefer IAM policies and bucket policies over ACLs. Enable Block Public Access to avoid accidental exposure.
  • For recovery and forensics, consider cross-account replication into a protected destination account with Object Lock enabled.
When designing S3 security, think in layers: identity, resource policy, network controls (VPC endpoints), encryption, logging, and immutable storage. Apply defense-in-depth and choose mechanisms that match your compliance and operational needs.
Links and references

Watch Video