62 docs tagged with "terraform"

Terraform module to request an ACM certificate for a domain and add a CNAME record to the DNS zone to complete certificate validation

Terraform module to provision API Gatway resources. The root module creates an API Gateway [REST API](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-rest-api.html) along with configuring tracing, logging, and metrics. The module also consists of the following submodules: - [account-settings](https://github.com/cloudposse/terraform-aws-api-gateway/tree/main/modules/account-settings) - to provision account-level settings for logging and metrics for API Gateway

Terraform module to provision [AWS Backup](https://aws.amazon.com/backup), a fully managed backup service that makes it easy to centralize and automate the back up of data across AWS services such as Amazon EBS volumes, Amazon EC2 instances, Amazon RDS databases, Amazon DynamoDB tables, Amazon EFS file systems, and AWS Storage Gateway volumes. > [!NOTE] > The syntax of declaring a backup schedule has changed as of release `0.14.0`, follow the instructions in the [0.13.x to 0.14.x+ migration guide](https://github.com/cloudposse/terraform-aws-backup/tree/main/docs/migration-0.13.x-0.14.x+.md). > [!WARNING] > The deprecated variables have been fully deprecated as of `1.x.x`. Please use the new variables as described in the [0.13.x to 0.14.x+ migration guide](https://github.com/cloudposse/terraform-aws-backup/tree/main/docs/migration-0.13.x-0.14.x+.md).

Terraform module to create AWS [`CodePipeline`](https://aws.amazon.com/codepipeline/) with [`CodeBuild`](https://aws.amazon.com/codebuild/) for [`CI/CD`](https://en.wikipedia.org/wiki/CI/CD) This module supports three use-cases: 1. **GitHub -> S3 (build artifact) -> Elastic Beanstalk (running application stack)**. The module gets the code from a ``GitHub`` repository (public or private), builds it by executing the ``buildspec.yml`` file from the repository, pushes the built artifact to an S3 bucket, and deploys the artifact to ``Elastic Beanstalk`` running one of the supported stacks (_e.g._ ``Java``, ``Go``, ``Node``, ``IIS``, ``Python``, ``Ruby``, etc.). - http://docs.aws.amazon.com/codebuild/latest/userguide/sample-maven-5m.html - http://docs.aws.amazon.com/codebuild/latest/userguide/sample-nodejs-hw.html - http://docs.aws.amazon.com/codebuild/latest/userguide/sample-go-hw.html 2. **GitHub -> ECR (Docker image) -> Elastic Beanstalk (running Docker stack)**. The module gets the code from a ``GitHub`` repository, builds a ``Docker`` image from it by executing the ``buildspec.yml`` and ``Dockerfile`` files from the repository, pushes the ``Docker`` image to an ``ECR`` repository, and deploys the ``Docker`` image to ``Elastic Beanstalk`` running ``Docker`` stack. - http://docs.aws.amazon.com/codebuild/latest/userguide/sample-docker.html 3. **GitHub -> ECR (Docker image)**. The module gets the code from a ``GitHub`` repository, builds a ``Docker`` image from it by executing the ``buildspec.yml`` and ``Dockerfile`` files from the repository, and pushes the ``Docker`` image to an ``ECR`` repository. This is used when we want to build a ``Docker`` image from the code and push it to ``ECR`` without deploying to ``Elastic Beanstalk``. To activate this mode, don't specify the ``app`` and ``env`` attributes for the module. - http://docs.aws.amazon.com/codebuild/latest/userguide/sample-docker.html

Terraform module to provision CloudFormation Stack.

Terraform Module that implements a CloudFront Distribution (CDN) for a custom origin (e.g. website) and [ships logs to a bucket](https://github.com/cloudposse/terraform-aws-log-storage). If you need to accelerate an S3 bucket, we suggest using [`terraform-aws-cloudfront-s3-cdn`](https://github.com/cloudposse/terraform-aws-cloudfront-s3-cdn) instead.

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

Terraform module for enabling [`flow logs`](http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/flow-logs.html) for `vpc` and `subnets`.

Terraform module for creation of CloudWatch Log Streams and Log Groups. Useful in combination with Fluentd/Fluent-bit for shipping logs.

Terraform module to create AWS CodeBuild project for AWS CodePipeline.

Terraform module to configure [Datadog AWS integration](https://docs.datadoghq.com/api/v1/aws-integration/).

Terraform module to provision an [`Amazon DocumentDB`](https://aws.amazon.com/documentdb/) cluster.

Terraform module to provision public and private [`subnets`](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Subnets.html) in an existing [`VPC`](https://aws.amazon.com/vpc) __Note:__ This module is intended for use with an existing VPC and existing Internet Gateway. To create a new VPC, use [terraform-aws-vpc](https://github.com/cloudposse/terraform-aws-vpc) module. __Note:__ Due to Terraform [limitations](https://github.com/hashicorp/terraform/issues/26755#issuecomment-719103775), many optional inputs to this module are specified as a `list(string)` that can have zero or one element, rather than as a `string` that could be empty or `null`. The designation of an input as a `list` type does not necessarily mean that you can supply more than one value in the list, so check the input's description before supplying more than one value. The core function of this module is to create 2 sets of subnets, a "public" set with bidirectional access to the public internet, and a "private" set behind a firewall with egress-only access to the public internet. This includes dividing up a given CIDR range so that a each subnet gets its own distinct CIDR range within that range, and then creating those subnets in the appropriate availability zones. The intention is to keep this module relatively simple and easy to use for the most popular use cases. In its default configuration, this module creates 1 public subnet and 1 private subnet in each of the specified availability zones. The public subnets are configured for bi-directional traffic to the public internet, while the private subnets are configured for egress-only traffic to the public internet. Rather than provide a wealth of configuration options allowing for numerous special cases, this module provides some common options and further provides the ability to suppress the creation of resources, allowing you to create and configure them as you like from outside this module. For example, rather than give you the option to customize the Network ACL, the module gives you the option to create a completely open one (and control access via Security Groups and other means) or not create one at all, allowing you to create and configure one yourself. ### Public subnets This module defines a public subnet as one that has direct access to an internet gateway and can accept incoming connection requests. In the simplest configuration, the module creates a single route table with a default route targeted to the VPC's internet gateway, and associates all the public subnets with that single route table. Likewise it creates a single Network ACL with associated rules allowing all ingress and all egress, and associates that ACL with all the public subnets. ### Private subnets A private subnet may be able to initiate traffic to the public internet through a NAT gateway, a NAT instance, or an egress-only internet gateway, or it might only have direct access to other private subnets. In the simple configuration, for IPv4 and/or IPv6 with NAT64 enabled via `public_dns64_enabled` or `private_dns64_enabled`, the module creates 1 NAT Gateway or NAT Instance for each private subnet (in the public subnet in the same availability zone), creates 1 route table for each private subnet, and adds to that route table a default route from the subnet to its NAT Gateway or Instance. For IPv6, the module adds a route to the Egress-Only Internet Gateway configured via input. As with the Public subnets, the module creates a single Network ACL with associated rules allowing all ingress and all egress, and associates that ACL with all the private subnets. ### Customization for special use cases Various features are controlled by `bool` inputs with names ending in `_enabled`. By changing the default values, you can enable or disable creation of public subnets, private subnets, route tables, NAT gateways, NAT instances, or Network ACLs. So for example, you could use this module to create only private subnets and the open Network ACL, and then add your own route table associations to the subnets and route all non-local traffic to a Transit Gateway or VPN. ### CIDR allocation For IPv4, you provide a CIDR and the module divides the address space into the largest CIDRs possible that are still small enough to accommodate `max_subnet_count` subnets of each enabled type (public or private). When `max_subnet_count` is left at the default `0`, it is set to the total number of availability zones in the region. Private subnets are allocated out of the first half of the reserved range, and public subnets are allocated out of the second half. For IPv6, you provide a `/56` CIDR and the module assigns `/64` subnets of that CIDR in consecutive order starting at zero. (You have the option of specifying a list of CIDRs instead.) As with IPv4, enough CIDRs are allocated to cover `max_subnet_count` private and public subnets (when both are enabled, which is the default), with the private subnets being allocated out of the lower half of the reservation and the public subnets allocated out of the upper half.

Terraform module to provision a DynamoDB table with autoscaling. Autoscaler scales up/down the provisioned OPS for the DynamoDB table based on the load. ## Requirements This module requires [AWS Provider](https://github.com/terraform-providers/terraform-provider-aws) `>= 4.22.0`

Terraform module to provision DynamoDB autoscaler. Autoscaler scales up/down the provisioned OPS for a DynamoDB table based on the load.

Terraform Module for providing a server capable of running admin tasks. Use `terraform-aws-ec2-admin-server` to create and manage an admin instance.

This repo contains a terraform module that creates two lambda functions that will create AMI automatically at regular intervals. It is based on the code at <https://serverlesscode.com/post/lambda-schedule-ebs-snapshot-backups/> and <https://serverlesscode.com/post/lambda-schedule-ebs-snapshot-backups-2/>.

Terraform module to easily generate AMI snapshots to create replica instances

Terraform Module for provisioning a general purpose EC2 host. Included features: * Automatically create a Security Group * Option to switch EIP attachment * CloudWatch monitoring and automatic reboot if instance hangs * Assume Role capability

Terraform module to provision an [`AWS ECR Docker Container registry`](https://aws.amazon.com/ecr/).

Terraform module to provision a Public [`AWS ECR Docker Container registry`](https://docs.aws.amazon.com/AmazonECR/latest/public/public-repositories.html/).

Terraform module to provision an AWS [`EFS`](https://aws.amazon.com/efs/) Network File System. **NOTE**: Release `0.32.0` contains breaking changes. To preserve the SG, follow the instructions in the [0.30.1 to 0.32.x+ migration path](https://github.com/cloudposse/terraform-aws-efs/tree/main/docs/migration-0.30.1-0.32.x+.md).

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`

Terraform module to provision AWS Elastic Beanstalk application

Terraform module to provision AWS Elastic Beanstalk environment ## Searching for Maintainer! The Cloud Posse team no longer utilizes Beanstalk all that much, but this module is still fairly popular. In an effort to give it the attention it deserves, we're searching for a volunteer maintainer to manage this specific repository's issues and pull requests (of which a number are already stacked up). This is a great opportunity for anyone who is looking to solidify and strengthen their Terraform skillset while also giving back to the SweetOps open source community! [You can learn more about being a SweetOps contributor on our docs site here](https://docs.cloudposse.com/community/contributors/). If you're interested, reach out to us via the `#terraform` channel in [the SweetOps Slack](https://slack.sweetops.com/) or directly [via email @ [email protected]](mailto:[email protected])

Terraform module to provision an [`ElastiCache`](https://aws.amazon.com/elasticache/) Memcached Cluster

Terraform module to provision an [`ElastiCache`](https://aws.amazon.com/elasticache/) Redis Cluster

Terraform module to provision an Elastic MapReduce (EMR) cluster on AWS.

Terraform module to provision two IAM roles and two IAM groups for assuming the roles provided MFA is present, and add IAM users to the groups. - Role and group with Administrator (full) access to AWS resources - Role and group with Readonly access to AWS resources To give a user administrator's access, add the user to the admin group. To give a user readonly access, add the user to the readonly group.

Terraform Module to provision a basic IAM system user suitable for CI/CD Systems (_e.g._ TravisCI, CircleCI) or systems which are *external* to AWS that cannot leverage [AWS IAM Instance Profiles](http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2_instance-profiles.html) or [AWS OIDC](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html). We do not recommend creating IAM users this way for any other purpose. By default, IAM users, groups, and roles have no access to AWS resources. IAM policies are the means by which privileges are granted to users, groups, or roles. It is recommended that IAM policies be applied directly to groups and roles but not users. **This module intentionally attaches an IAM policy directly to the user and does not use groups** 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 module outputs are stored in plaintext in the Terraform state file.

Terraform module for generating or importing an SSH public key file into AWS.

Terraform module designed to generate consistent names and tags for resources. Use `terraform-null-label` to implement a strict naming convention. There are 6 inputs considered "labels" or "ID elements" (because the labels are used to construct the ID): 1. namespace 1. tenant 1. environment 1. stage 1. name 1. attributes This module generates IDs using the following convention by default: `{namespace}-{environment}-{stage}-{name}-{attributes}`. However, it is highly configurable. The delimiter (e.g. `-`) is configurable. Each label item is optional (although you must provide at least one). So if you prefer the term `stage` to `environment` and do not need `tenant`, you can exclude them and the label `id` will look like `{namespace}-{stage}-{name}-{attributes}`. - The `tenant` label was introduced in v0.25.0. To preserve backward compatibility, it is not included by default. - The `attributes` input is actually a list of strings and `{attributes}` expands to the list elements joined by the delimiter. - If `attributes` is excluded but `namespace`, `stage`, and `environment` are included, `id` will look like `{namespace}-{environment}-{stage}-{name}`. Excluding `attributes` is discouraged, though, because attributes are the main way modules modify the ID to ensure uniqueness when provisioning the same resource types. - If you want the label items in a different order, you can specify that, too, with the `label_order` list. - You can set a maximum length for the `id`, and the module will create a (probably) unique name that fits within that length. (The module uses a portion of the MD5 hash of the full `id` to represent the missing part, so there remains a slight chance of name collision.) - You can control the letter case of the generated labels which make up the `id` using `var.label_value_case`. - By default, all of the non-empty labels are also exported as tags, whether they appear in the `id` or not. You can control which labels are exported as tags by setting `labels_as_tags` to the list of labels you want exported, or the empty list `[]` if you want no labels exported as tags at all. Tags passed in via the `tags` variable are always exported, and regardless of settings, empty labels are never exported as tags. You can control the case of the tag names (keys) for the labels using `var.label_key_case`. Unlike the tags generated from the label inputs, tags passed in via the `tags` input are not modified. There is an unfortunate collision over the use of the key `name`. Cloud Posse uses `name` in this module to represent the component, such as `eks` or `rds`. AWS uses a tag with the key `Name` to store the full human-friendly identifier of the thing tagged, which this module outputs as `id`, not `name`. So when converting input labels to tags, the value of the `Name` key is set to the module `id` output, and there is no tag corresponding to the module `name` output. An empty `name` label will not prevent the `Name` tag from being exported. It's recommended to use one `terraform-null-label` module for every unique resource of a given resource type. For example, if you have 10 instances, there should be 10 different labels. However, if you have multiple different kinds of resources (e.g. instances, security groups, file systems, and elastic ips), then they can all share the same label assuming they are logically related. For most purposes, the `id` output is sufficient to create an ID or label for a resource, and if you want a different ID or a different format, you would instantiate another instance of `null-label` and configure it accordingly. However, to accomodate situations where you want all the same inputs to generate multiple descriptors, this module provides the `descriptors` output, which is a map of strings generated according to the format specified by the `descriptor_formats` input. This feature is intentionally simple and minimally configurable and will not be enhanced to add more features that are already in `null-label`. See [examples/complete/descriptors.tf](https://github.com/cloudposse/terraform-null-label/tree/main/examples/complete/descriptors.tf) for examples. All [Cloud Posse Terraform modules](https://github.com/cloudposse?utf8=%E2%9C%93&q=terraform-&type=&language=) use this module to ensure resources can be instantiated multiple times within an account and without conflict. The Cloud Posse convention is to use labels as follows: - `namespace`: A short (3-4 letters) abbreviation of the company name, to ensure globally unique IDs for things like S3 buckets - `tenant`: _(Rarely needed)_ When a company creates a dedicated resource per customer, `tenant` can be used to identify the customer the resource is dedicated to - `environment`: A [short abbreviation](https://github.com/cloudposse/terraform-aws-utils/#introduction) for the AWS region hosting the resource, or `gbl` for resources like IAM roles that have no region - `stage`: The name or role of the account the resource is for, such as `prod` or `dev` - `name`: The name of the component that owns the resources, such as `eks` or `rds` **NOTE:** The `null` originally referred to the primary Terraform [provider](https://www.terraform.io/docs/providers/null/index.html) used in this module. With Terraform 0.12, this module no longer needs any provider, but the name was kept for continuity. - Releases of this module from `0.23.0` onward only work with Terraform 0.13 or newer. - Releases of this module from `0.12.0` through `0.22.1` support `HCL2` and are compatible with Terraform 0.12 or newer. - Releases of this module prior to `0.12.0` are compatible with earlier versions of terraform like Terraform 0.11.

Terraform module to provision AmazonMQ resources on AWS

Terraform module for multi-AZ [`subnets`](http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Subnets.html) provisioning. The module creates private and public subnets in the provided Availability Zones. The public subnets are routed to the Internet Gateway specified by `var.igw_id`. `nat_gateway_enabled` flag controls the creation of NAT Gateways in the public subnets. The private subnets are routed to the NAT Gateways provided in the `var.az_ngw_ids` map. If you are creating subnets inside a VPC, consider using [cloudposse/terraform-aws-dynamic-subnets](https://github.com/cloudposse/terraform-aws-dynamic-subnets) instead.

Terraform module for named [`subnets`](http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Subnets.html) provisioning.

Terraform module to provision AWS Network Firewall resources.

Terraform module to create an IAM Group and Policy to grant permissions to delegated IAM users in the Organization's master account to access a member account https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_access.html

Terraform module to create an IAM Role to grant permissions to delegated IAM users in the master account to access an invited member account https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_access.html

Terraform module to provision Datadog resources. The module consists of the following submodules: - [monitors](https://github.com/cloudposse/terraform-datadog-platform/tree/main/modules/monitors) - to provision Datadog [monitors](https://docs.datadoghq.com/api/v1/monitors/) - [synthetics](https://github.com/cloudposse/terraform-datadog-platform/tree/main/modules/synthetics) - to provision Datadog [synthetics](https://docs.datadoghq.com/synthetics/) - [permissions](https://github.com/cloudposse/terraform-datadog-platform/tree/main/modules/permissions) - to look up all available Datadog [permissions](https://docs.datadoghq.com/account_management/rbac/permissions/) - [roles](https://github.com/cloudposse/terraform-datadog-platform/tree/main/modules/roles) - to provision Datadog [roles](https://docs.datadoghq.com/account_management/rbac) - [slo](https://github.com/cloudposse/terraform-datadog-platform/tree/main/modules/slo) - to provision Datadog [Service Level Objectives](https://docs.datadoghq.com/monitors/service_level_objectives/) - [child_organization](https://github.com/cloudposse/terraform-datadog-platform/tree/main/modules/child_organization) - to provision Datadog [child organizations](https://docs.datadoghq.com/account_management/multi_organization/) - [organization_settings](https://github.com/cloudposse/terraform-datadog-platform/tree/main/modules/organization_settings) - to manage Datadog organization's settings __Notes on Datadog child organizations:__ * Users can be added to the parent-organization and/or multiple child-organizations and switch between them from the user account settings menu * The parent-organization can view the usage of individual child-organizations, allowing them to track trends in usage * The Multi-organization account feature is not enabled by default. Contact Datadog support to have it enabled * Free and Trial organizations cannot enable SAML * We can only create Datadog child organizations with terraform, but cannot destroy them. When trying to destroy, the following error is thrown: ``` Warning: Cannot delete organization. Remove organization by contacting support (https://docs.datadoghq.com/help). ```

Terraform module to provision AWS [`RDS`](https://aws.amazon.com/rds/) instances

Terraform module to provision an [`RDS Aurora`](https://aws.amazon.com/rds/aurora) cluster for MySQL or Postgres. Supports [Amazon Aurora Serverless](https://aws.amazon.com/rds/aurora/serverless/).

Terraform module to provision an [`RDS Aurora`](https://aws.amazon.com/rds/aurora) instance group for MySQL or Postgres along with a dedicated endpoint. Use this module together with our [`terraform-aws-rds-cluster`](https://github.com/cloudposse/terraform-aws-rds-cluster) to provision pools of RDS instances. This is useful for creating reporting clusters that don't impact the production databases. Supports [Amazon Aurora Serverless](https://aws.amazon.com/rds/aurora/serverless/).

Terraform module to provision an Amazon [RDS Proxy](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-proxy.html) for MySQL or Postgres.

Terraform module to provision AWS [`RDS`](https://aws.amazon.com/rds/) replica instances. These are best suited for reporting purposes. **IMPORTANT** It is not possible to create a read replica for a DB Instance that belongs to an Aurora DB Cluster.

Terraform module that implements "vanity" host names (e.g. `brand.com`) as `ALIAS` records to another Route53 DNS resource record (e.g. ELB/ALB, S3 Bucket Endpoint or CloudFront Distribution). Unlike `CNAME` records, the synthetic `ALIAS` record works with zone apexes.

Terraform module to define a consistent AWS Route53 hostname

Terraform module to easily define consistent cluster domains on `Route53`.

Terraform module to provision Route 53 Resolver DNS Firewall, domain lists, firewall rules, rule groups, and logging configurations.

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 create AWS Security Group and rules.

Terraform module to provision Simple Email Service on AWS.

Terraform module to provision CloudWatch alarms for SNS

Terraform module to provision SNS topic

Terraform module read ssm paramters managed with Chamber.

Terraform module to provision [AWS Step Functions](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html).

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

Terraform module to provision a VPC with Internet Gateway. Contains a submodule for provisioning Interface and/or Gateway VPC Endpoints. This module also supports provisioning additional CIDR blocks for the VPC, with or without using [IPAM](https://docs.aws.amazon.com/vpc/latest/ipam/what-it-is-ipam.html).

Terraform module to create a peering connection between two VPCs

Terraform module to create a peering connection between any two VPCs existing in different AWS accounts. This module supports performing this action from a 3rd account (e.g. a "root" account) by specifying the roles to assume for each member account. **IMPORTANT:** AWS allows a multi-account VPC Peering Connection to be deleted from either the requester's or accepter's side. However, Terraform only allows the VPC Peering Connection to be deleted from the requester's side by removing the corresponding `aws_vpc_peering_connection` resource from your configuration. [Read more about this](https://www.terraform.io/docs/providers/aws/r/vpc_peering_accepter.html) on Terraform's documentation portal.

Terraform module to provision a [site-to-site](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html) [VPN connection](https://docs.aws.amazon.com/vpc/latest/userguide/vpn-connections.html) between a VPC and an on-premises network. The module does the following: - Creates a Virtual Private Gateway (VPG) and attaches it to the VPC - Creates a Customer Gateway (CGW) pointing to the provided IP address of the Internet-routable external interface on the on-premises network - Creates a Site-to-Site Virtual Private Network (VPN) connection and assigns it to the VPG and CGW - Requests automatic route propagation between the VPG and the provided route tables in the VPC - If the VPN connection is configured to use static routes, provisions a static route between the VPN connection and the CGW