v0.70.0

Add support for a custom cache policy for ordered cache @linhkikuchi (#169)

what

• To add support for a custom cache policy for ordered cache

v0.69.0

Add support for CloudFront functions @alexjurkiewicz (#167)

what

This follows the naming of Terraform's AWS provider. Lambda@Edge
functions are "lambda functions", whereas CloudFront functions are
simply "functions".

references

• https://github.com/hashicorp/terraform-provider-aws/releases/tag/v3.41.0
• https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/cloudfront_distribution#function-association
• https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/cloudfront_function

v0.68.0

Use bucket.website_endpoint instead of bucket.website_domain @Zyava (#166)

what

There is currently a bug introduced in version v0.64.0 which prevents CloudFront from connecting to the bucket. bucket.website_domain = "s3-website-<region>.amazonaws.com" (see AWS provider source code https://github.com/hashicorp/terraform-provider-aws/blob/ac06ced75cba0daf09fef2938752ad13cc6fff6e/aws/resource_aws_s3_bucket.go#L1747). In https://github.com/cloudposse/terraform-aws-cloudfront-s3-cdn/blob/master/main.tf#L319 local.bucket_domain_name is used in CloudFront origin, but since it is "s3-website.eu-central-1.amazonaws.com" (in our case) - CloudFront gets a redirect to https://aws.amazon.com/s3/ and nothing works...

v0.67.0

Fix: Deployment Principal ARNs @korenyoni (#164)

what

• Add test for deployment_principal_arns
• Fix order of nested functions when rendering bucket policy for deployment_principal_arns — otherwise an error occurs when comparing types.
• Fix snippet: all prefixes must begin in forward slash or otherwise the bucket policy JSON will be invalid.
• Fix snippet passing incorrect variable name.
• Programatically fix missing leading forward slash for prefixes in Bucket Policy

(misc)

• Fix typo in tfvars fixtures in example.
• Add enablement toggles to all resources in example
• Fix minimum_protocol_version being passed when it won't be honored by AWS i.e. when s3_access_log_bucket_name is true as a result of acm_certificate_arn being unset.
• Fix default for s3_access_log_bucket_name — it is supposed to be empty and there is a check for its length in locals{} that assumes it is empty by default, but it is not empty by default.

why

• deployment_principal_arns was not working and examples/complete was not testing for it

references

• #160

v0.66.0

Add support for realtime log config @linhkikuchi (#162)

what

• To add support for realtime log config for default cache

v0.65.0

Greater control over Access Logging @Nuru (#161)

what

• More clearly distinguish between S3 Access Logging and Cloudfront Access Logging
  • Deprecate:
    • access_log_bucket_name
    • logging_enabled
    • log_include_cookies
    • log_prefix
  • Replace with variables prefixed with s3_access_log and cloudfront_access_log to indicate which access logs they apply to
• Provide independent feature flags for S3 Access Logging and Cloudfront Access Logging
• Provide ability to configure independent logging object prefixes for S3 Access Logging and Cloudfront Access Logging
• Provide ability to direct Cloudfront Access Logging to an existing S3 bucket
• Fix issues causing module to fail when enabled was set to false
• Add tests

why

• This module (potentially) creates an S3 Bucket to use as the Cloudfront Origin, and a Cloudfront Distribution. Both S3 Buckets and Cloudfront Distributions provide the ability to generate Access Logs and save them to an S3 bucket. However, the variables in the module referred only to "log" or "logging", which made it non-obvious whether they applied to S3 Access Logs or Cloudfront Access Logs. The new naming largely removes the confusion, while the old variables are still supported for backward compatibility.
• Explicit flags enabling and disabling logging (rather than implicit based on providing a destination bucket name) avoids Terraform problems with plan depending on results of apply when S3 Bucket is created in the same root module that calls this module.
• The user was stuck with the prefix this module generated for S3 Access Logs, which may not have been what they wanted.
• This module always created a new S3 bucket for Cloudfront Access Logging when Cloudfront Access Logging was enabled, which did not allow users to store logs for multiple distributions in the same bucket.
• All Cloud Posse modules should plan and apply without error and without creating resources when enabled is set to false
• Ensure module behaves properly when enabled is set to false. Verify that the same S3 Bucket can be supplied for both sets of access logs

v0.64.0 Undo Breaking Change

There is no (recent) breaking change if you update from a version prior to 0.61.0 to this version (0.64.0) or later.

Breaking change:

• If you had set website_enabled = true prior to v0.61.0, this module would create a publicly accessible S3 website. v0.61.0 introduced a change to attempt to block that public access (see README for details). If you wanted the S3 website to be publicly available (bypassing Cloudfront), that release broke it.

Breaking back:

• Release v0.64.0 preserves the feature, but makes it optional with the variable s3_website_password_enabled and by setting that to default to false, restores the previous default.

Add deployers, bug fixes, general cleanup @Nuru (#160)

what

• Add deployment_principal_arns and deployment_actions
• Add s3_website_password_enabled
• Restore template parsing of additional_bucket_policy removed by #141. Closes #153
• Only create referer password when needed. Supersedes and closes #159
• General cleanup, enhance README. Fixes #151

why

• Along with creating the S3 bucket, enable selected IAM Principals (such as CI/CD) to upload content to it.
• PR #105 made it difficult to directly access the S3 Website created with website_enabled = true. This was a breaking change, as before the S3 Website was public. Adding s3_website_password_enabled to make the #105 change optional and default it to false to retain backward compatibility.
• PR #141 was only supposed to remove the obsolete implementation of the feature, not the feature itself.
• Best practice is not to create unneeded resources.
• The effect of website_enabled was not well documented. The code was quite confusing to follow due to conditionals scattered throughout.

v0.63.0

Add support for a custom cache policy @dmattia (#140)

what

• AWS has a relatively new CloudFront feature named Cache Policies: https://aws.amazon.com/blogs/networking-and-content-delivery/amazon-cloudfront-announces-cache-and-origin-request-policies/
• This adds support for the default cache to set an explicit cache policy
• This also sets restrictions on not allowing some other params to be set if the cache policy is specified, as is consistent with the AWS Console's wizard when creating a distribution.

This module could also create a cache policy itself if desired, I would gladly make that change.

Note: I support a module for creating cache policies: https://registry.terraform.io/modules/transcend-io/cache-policy/aws/latest

why

• Cache Policies are the easiest (only?) way to add brotli compression in CloudFront

v0.62.0

Allow creating a policy for an existing S3 bucket @emyller (#154)

what

• Fix creating a S3 bucket policy when using an existing S3 bucket.

why

• The code was only considering the bucket object managed by this module.

references

• Closes #152.

v0.61.0 Breaking change

Breaking change:

• If you had set website_enabled = true prior to this release, this module would create a publicly accessible S3 website. This release introduces a change to attempt to block that public access (see README for details). If you wanted the S3 website site to be publicly available (bypassing Cloudfront), this release will break it.

Breaking back:

• Release v0.64.0 preserves the feature, but makes it optional with the variable s3_website_password_enabled and by setting that to default to false, restores the previous default.

Make S3 website private; add S3 origin @jmcgeheeiv (#105)

What

In this PR I added these enhancements:

• Make the S3 website accessible only via CloudFront. You may prefer that I add a variable to make this optional. Let me know.
• Add S3 origins, which are different from the currently-supported custom origins
• Change http_port and https_port to numbers merely to dissuade observers from attempting to use null. null causes a very, very hard-to-diagnose error that does not reveal the line number.

I will further note that Terraform insists that the complete data structure appearing in variables.tf be specified for custom_origin and s3_origin variables. Thus lookup() with default values is immaterial.

Why

The reasons are included in the list of enhancements above. I hope it is more readable that way.