The terraform-aws-s3-bucket module represents a centralized Terraform abstraction for provisioning Amazon S3 buckets with a breadth of configuration options that maps closely to the capabilities exposed by the Terraform AWS provider. The module is positioned as a complete solution for creating and managing S3 buckets with an extensive range of configurations and features. It abstracts the complexity of S3 bucket management while providing fine-grained control over bucket properties, security settings, and integration with other AWS services. The module is designed to be comprehensive, handling nearly all S3 bucket configurations supported by the AWS provider for Terraform.
The module is organized around several core components that work together to provision and configure S3 buckets. The module uses local variables and conditional logic to determine which resources should be created based on the provided configuration. This conditional creation model allows users to enable or disable specific aspects of bucket configuration without maintaining separate modules.
Module Overview and Core Purpose
The terraform-aws-s3-bucket module creates an S3 bucket on AWS with all or almost all features provided by the Terraform AWS provider. The direct fact is that the module wraps provider resources into a single reusable interface. The impact layer for users is reduced boilerplate and consistent defaults across environments. The contextual layer connects this to the broader Terraform module ecosystem where reusable patterns reduce drift and accelerate delivery.
The module supports a comprehensive set of S3 bucket features across multiple categories. The module enables users to provision buckets with security, lifecycle, and access control settings in a single declaration. The module is designed to be comprehensive, handling nearly all S3 bucket configurations supported by the AWS provider for Terraform.
Feature Set and Supported Configurations
The module advertises support for the following feature categories.
| Feature Category | Supported Features | Configuration Variable |
|---|---|---|
| Basic Configuration | Bucket creation, naming, force destroy | bucket, bucketprefix, forcedestroy |
| Access Control | ACLs, Object Ownership, Public Access Block | acl, grant, objectownership, blockpublic_acls |
| Encryption | SSE-S3, SSE-KMS, Encryption policies | serversideencryption_configuration |
| Storage Management | Versioning, Lifecycle rules, Intelligent tiering | versioning, lifecyclerule, intelligenttiering |
| Website Hosting | Index/error docs, redirects, routing rules | website |
| Integrations | CORS, Logging, Replication, Notifications | corsrule, logging, replicationconfiguration |
| Monitoring | Metrics, Inventory, Analytics | metricconfiguration, inventoryconfiguration, analytics_configuration |
| Security Policies | TLS |
The table above provides a direct mapping of feature categories to configuration variables. The impact layer is that teams can reason about bucket capability by category rather than individual resource arguments. The contextual layer is that these categories align with AWS Well-Architected pillars of security, operational excellence, and cost optimization.
The module documentation lists specific supported capabilities:
- static web-site hosting
- access logging
- versioning
- CORS
- lifecycle rules
- server-side encryption
- object locking
- Cross-Region Replication (CRR)
- ELB log delivery bucket policy
- ALB/NLB log delivery bucket policy
- WAF log delivery bucket policy
- Account-level Public Access Block
- S3 Directory Bucket
- S3 Table Bucket
- S3 Vectors
Each capability represents a distinct use case. Static web-site hosting allows serving content directly from S3 with index and error documents. Access logging provides audit trails for bucket requests. Versioning enables keeping multiple versions of an object. CORS supports cross-origin resource sharing for web applications. Lifecycle rules automate transitions and expiration. Server-side encryption protects data at rest. Object locking provides WORM compliance. Cross-Region Replication maintains copies across regions. Log delivery bucket policies enable integration with ELB, ALB/NLB, and WAF for centralized logging. Public Access Block provides account-level controls. S3 Directory Bucket, S3 Table Bucket, and S3 Vectors address modern data and AI workloads.
Security Posture and Compliance
A comprehensive Terraform module for creating and managing AWS S3 buckets with advanced security, lifecycle management, and access control features is described in related community work. The security first stance emphasizes encryption by default, secure bucket policies, and IAM integration.
Multi-bucket support enables creation and management of multiple S3 buckets with different configurations from a single module call. Lifecycle management provides automated object transitions and deletion policies. Access control supports bucket policies, access points, and CORS configuration. Consistent naming integrates with cloudposse/terraform-null-label for standardized resource naming. Monitoring ready capabilities include CloudTrail and CloudWatch integration. Highly configurable options allow extensive customization for different use cases.
Enterprise-grade security claims include:
- Perfect Security Score: 227/227 Checkov security checks passed
- Zero Vulnerabilities: No failed security checks
- Enterprise Ready: CIS Benchmarks, PCI-DSS, HIPAA compliant
- Encryption by Default: AES256 or KMS encryption for all buckets
- Secure Access Controls: Least privilege IAM policies, no hardcoded credentials
- Automatic Cleanup: 7-day default for incomplete multipart uploads
- TLS Enforcement: Secure transport required for all operations
The direct fact is the security score and compliance statements. The impact layer is reduced audit friction and faster approval for regulated workloads. The contextual layer connects these claims to the module's configuration variables for serversideencryptionconfiguration, blockpublic_acls, and object ownership controls.
Validation of security compliance can be performed with:
checkov -d
The command enables automated policy scanning against the generated Terraform code.
Usage Patterns and Configuration Examples
Basic usage demonstrates creation of a private bucket with versioning and object ownership controls.
module "s3_bucket" {
source = "terraform-aws-modules/s3-bucket/aws"
bucket = "my-s3-bucket"
acl = "private"
control_object_ownership = true
object_ownership = "ObjectWriter"
versioning = {
enabled = true
}
}
The direct fact is the module source and arguments. The impact layer is immediate enforcement of private ACL and versioning for data durability. The contextual layer shows how controlobjectownership and object_ownership parameters ensure proper object ownership controls, while versioning enables keeping multiple versions of an object.
A log delivery bucket pattern uses force_destroy and policy attachment.
module "s3_bucket_for_logs" {
source = "terraform-aws-modules/s3-bucket/aws"
bucket = "my-s3-bucket-for-logs"
acl = "log-delivery-write"
force_destroy = true
control_object_ownership = true
object_ownership = "ObjectWriter"
attach_elb_log_delivery_policy = true
}
The direct fact is the acl log-delivery-write and attachelblogdeliverypolicy. The impact layer is that ELB logs can be delivered without manual bucket policy creation. The contextual layer links to the feature set for ELB log delivery bucket policy.
An expanded log delivery configuration adds ALB/NLB support.
module "s3_bucket_for_logs" {
source = "terraform-aws-modules/s3-bucket/aws"
bucket = "my-s3-bucket-for-logs"
force_destroy = true
control_object_ownership = true
object_ownership = "ObjectWriter"
attach_elb_log_delivery_policy = true
attach_lb_log_delivery_policy = true
}
The direct fact is the addition of attachlblogdeliverypolicy. The impact layer is unified logging for both classic and modern load balancers. The contextual layer shows how the module consolidates multiple log delivery policies.
A WAF log bucket example starts with bucket definition.
module "s3_bucket_for_waf_logs" {
source = "terraform-aws-modules/s3-bucket/aws"
bucket =
The partial snippet indicates a pattern for WAF log delivery bucket policy attachment.
S3-Based Module Distribution
Storing Terraform modules in S3 buckets is a practical choice for organizations that are already invested in AWS and want a simple, private module distribution mechanism. You do not need a Terraform Registry or Git server. Just package your module as a zip file, upload it to S3, and reference it in your configuration. AWS IAM handles authentication, and S3 versioning can help protect module objects from accidental overwrites or deletions.
This guide covers how to package, upload, and reference S3-hosted modules.
How S3 Module Sources Work
Terraform can download modules from S3 buckets using the s3:: prefix. When it encounters this source, it downloads the archive from S3, extracts it, and uses the contents as the module code.
A basic S3 module source example is:
module "vpc" {
source = "s3::https://my-terraform-modules.s3.amazonaws.com/vpc/v1.0.0.zip"
vpc_cidr = "10.0.0.0/16"
environment = "production"
}
Terraform expects the S3 object to be a zip archive containing the module's .tf files.
Packaging a Module for S3
First, you need to create a zip archive of your module
The direct fact is the s3:: prefix and zip requirement. The impact layer is private module distribution without external dependencies. The contextual layer connects to the terraform-aws-s3-bucket module itself, which can be stored in S3 and consumed via s3:: source.
Getting Started and Prerequisites
This guide provides instructions for quickly getting started with the AWS S3 bucket Terraform module. It covers basic setup, common usage patterns, and essential configurations. For comprehensive feature details, see Features and Capabilities.
Before using this module, ensure you have:
The following diagram illustrates how the terraform-aws-s3-bucket module integrates with your Terraform configuration and AWS.
The simplest way to use the module is to create a basic S3 bucket:
For a more secure configuration with versioning enabled:
The controlobjectownership and object_ownership parameters ensure proper object ownership controls, while versioning enables keeping multiple versions of an object.
S3 buckets are commonly used for storing logs from various AWS services:
Secure your S3 bucket with encryption, access controls, and security policies:
For more comprehensive security configurations, refer to Security Configurations.
Configure your S3 bucket for static website hosting:
Configure lifecycle rules to automatically transition or expire objects:
You can conditionally create a bucket using the create_bucket parameter:
This is useful when you need to manage bucket creation based on environment variables or other conditions.
You can create multiple similar buckets in two ways:
for_each meta-argument:
Refer to the wrappers directory in the module repository for detailed implementation.
After mastering the basics, you can explore:
Integration and Operational Patterns
The module supports integrations with CORS, Logging, Replication, and Notifications. The direct fact is the configuration variable corsrule, logging, replicationconfiguration. The impact layer is reduced manual resource definitions for cross-service data flows. The contextual layer connects to the feature category Integrations from the feature table.
Monitoring capabilities include metrics, inventory, and analytics configurations. The direct fact is metricconfiguration, inventoryconfiguration, analytics_configuration. The impact layer is observability without additional modules. The contextual layer ties to enterprise security posture where monitoring is required for compliance.
Storage management includes versioning, lifecycle rules, and intelligent tiering. The direct fact is versioning, lifecyclerule, intelligenttiering. The impact layer is cost optimization and data retention policy enforcement. The contextual layer aligns with lifecycle rules feature listed in source 1.
Access control includes ACLs, Object Ownership, and Public Access Block. The direct fact is acl, grant, objectownership, blockpublic_acls. The impact layer is prevention of unintended public exposure. The contextual layer links to Account-level Public Access Block feature.
Encryption supports SSE-S3, SSE-KMS, and Encryption policies. The direct fact is serversideencryption_configuration. The impact layer is data protection at rest by default. The contextual layer connects to Encryption by Default claim of AES256 or KMS.
Website hosting supports index/error docs, redirects, routing rules via website configuration. The direct fact is website variable. The impact layer is low-cost static site deployment. The contextual layer matches static web-site hosting feature.
Conclusion
The terraform-aws-s3-bucket module consolidates a large surface area of S3 configuration into a single reusable Terraform construct. The module covers basic configuration, access control, encryption, storage management, website hosting, integrations, monitoring, and security policies. It supports specialized bucket types such as S3 Directory Bucket, S3 Table Bucket, and S3 Vectors, reflecting AWS service evolution.
Security claims of 227/227 Checkov checks passed, CIS Benchmarks, PCI-DSS, HIPAA compliance, encryption by default, least privilege IAM, automatic multipart cleanup, and TLS enforcement provide an enterprise-ready baseline. The module's conditional logic and local variables allow fine-grained resource creation without duplication.
Usage patterns demonstrate private buckets with versioning, log delivery buckets with force_destroy and policy attachments, and S3-hosted module distribution via s3:: prefix. Getting started guidance emphasizes basic bucket creation, secure configurations with versioning and object ownership, log storage, static website hosting, and lifecycle rules.
The combination of feature breadth, security posture, and integration patterns positions the module as a central building block for infrastructure as code teams that require consistent, auditable, and scalable S3 provisioning across development, staging, and production environments.