6 docs tagged with "s3"

Terraform module to provision an AWS CloudFront CDN with an S3 origin.

Terraform module designed to easily backup EFS filesystems to S3 using DataPipeline. The workflow is simple: * Periodically launch resource (EC2 instance) based on schedule * Execute the shell command defined in the activity on the instance * Sync data from Production EFS to S3 Bucket by using `aws-cli` * The execution log of the activity is stored in `S3` * Publish the success or failure of the activity to an `SNS` topic * Automatically rotate the backups using `S3 lifecycle rule`

This module creates an S3 bucket with support for versioning, lifecycles, object locks, replication, encryption, ACL, bucket object policies, and static website hosting. For backward compatibility, it sets the S3 bucket ACL to `private` and the `s3_object_ownership` to `ObjectWriter`. Moving forward, setting `s3_object_ownership` to `BucketOwnerEnforced` is recommended, and doing so automatically disables the ACL. This module blocks public access to the bucket by default. See `block_public_acls`, `block_public_policy`, `ignore_public_acls`, and `restrict_public_buckets` to change the settings. See [AWS documentation](https://docs.aws.amazon.com/AmazonS3/latest/dev/access-control-block-public-access.html) for more details. This module can optionally create an IAM User with access to the S3 bucket. This is inherently insecure in that to enable anyone to become the User, access keys must be generated, and anything generated by Terraform is stored unencrypted in the Terraform state. See the [Terraform documentation](https://www.terraform.io/docs/state/sensitive-data.html) for more details The best way to grant access to the bucket is to grant one or more IAM Roles access to the bucket via `privileged_principal_arns`. This IAM Role can be assumed by EC2 instances via their Instance Profile, or Kubernetes (EKS) services using [IRSA](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html). Entities outside of AWS can assume the Role via [OIDC](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html). (See [this example of connecting GitHub](https://aws.amazon.com/blogs/security/use-iam-roles-to-connect-github-actions-to-actions-in-aws/) to enable GitHub actions to assume AWS IAM roles, or use [this Cloud Posse component](https://github.com/cloudposse/terraform-aws-components/tree/main/modules/github-oidc-provider) if you are already using the Cloud Posse reference architecture.) If neither of those approaches work, then as a last resort you can set `user_enabled = true` and this module will provision a basic IAM user with permissions to access the bucket. We do not recommend creating IAM users this way for any other purpose. If an IAM user is created, the IAM user name is constructed using [terraform-null-label](https://github.com/cloudposse/terraform-null-label) and some input is required. The simplest input is `name`. By default the name will be converted to lower case and all non-alphanumeric characters except for hyphen will be removed. See the documentation for `terraform-null-label` to learn how to override these defaults if desired. If an AWS Access Key is created, it is stored either in SSM Parameter Store or is provided as a module output, but not both. Using SSM Parameter Store is recommended because that will keep the secret from being easily accessible via Terraform remote state lookup, but the key will still be stored unencrypted in the Terraform state in any case.

This module creates an S3 bucket suitable for receiving logs from other `AWS` services such as `S3`, `CloudFront`, and `CloudTrails`. This module implements a configurable log retention policy, which allows you to efficiently manage logs across different storage classes (_e.g._ `Glacier`) and ultimately expire the data altogether. It enables [default server-side encryption](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-encryption.html). It [blocks public access to the bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-control-block-public-access.html) by default. As of March, 2022, this module is primarily a wrapper around our [s3-bucket](https://github.com/cloudposse/terraform-aws-s3-bucket) module, with some options preconfigured and SQS notifications added. If it does not exactly suit your needs, you may want to use the `s3-bucket` module directly. As of version 1.0 of this module, most of the inputs are marked `nullable = false`, meaning you can pass in `null` and get the default value rather than having the input be actually set to `null`. This is technically a breaking change from previous versions, but since `null` was not a valid value for most of these variables, we are not considering it a truly breaking change. However, be mindful that the behavior of inputs set to `null` may change in the future, so we recommend setting them to the desired value explicitly.

## Deprecated **As of July, 2023 this module is deprecated.** `terraform-aws-s3-website` offers little value beyond [ the `terraform-aws-s3-bucket` module](https://github.com/cloudposse/terraform-aws-s3-bucket), so Cloud Posse is phasing out support for this project. Users are advised to migrate to [terraform-aws-s3-bucket](https://github.com/cloudposse/terraform-aws-s3-bucket) to manage the S3 bucket (including logging) and [terraform-aws-route53-alias](https://github.com/cloudposse/terraform-aws-route53-alias) to register the website hostname in Route53. Feature requests should be directed to those modules. Terraform module to provision S3-backed Websites. **IMPORTANT:** This module provisions a globally accessible S3 bucket for unauthenticated users because it is designed for hosting public static websites. Normally, AWS recommends that S3 buckets should not publicly accessible in order to protect S3 data from unauthorized users.

Terraform module to provision an S3 bucket to store `terraform.tfstate` file and a DynamoDB table to lock the state file to prevent concurrent modifications and state corruption. The module supports the following: 1. Forced server-side encryption at rest for the S3 bucket 2. S3 bucket versioning to allow for Terraform state recovery in the case of accidental deletions and human errors 3. State locking and consistency checking via DynamoDB table to prevent concurrent operations 4. DynamoDB server-side encryption https://www.terraform.io/docs/backends/types/s3.html __NOTE:__ The operators of the module (IAM Users) must have permissions to create S3 buckets and DynamoDB tables when performing `terraform plan` and `terraform apply` __NOTE:__ This module cannot be used to apply changes to the `mfa_delete` feature of the bucket. Changes regarding mfa_delete can only be made manually using the root credentials with MFA of the AWS Account where the bucket resides. Please see: https://github.com/terraform-providers/terraform-provider-aws/issues/629