Failure when creating Proxy CF about terraform-aws-next-js

[ofhouse]

Haha, yes CloudFront is a configuration monster 🙈

As soon as Hashicorp has merged the support for Origin & Cache policies we plan to move to a more modular structure of this module, so that it is possible use it together with an external CloudFront resource.
We already have support for passing custom origins and cache behaviours to the internal CloudFront distribution, but I think for the most developers it would make more sense to integrate the module into an existing CloudFront setup.

Anyway thanks for testing and reporting the bug caused by using multiple AWS profiles.
I created a follow up ticket for it here #50 so I close this ticket.

[ofhouse]

Hi, thanks for reaching out!
ad7047c is an unreleased change, so it should have no impact when installing the module from the Terraform registry as you did here (source = "dealmore/next-js/aws").

The code of the latest version from the Terraform registry can be found here: Tag/v0.6.2.

We mostly use eu-central-1 here, so I am a bit surprised that eu-west-1 behaves differently.
Normally no additional provider configuration (pass-through) in the module should be necessary, since we initialize an additional us-east-1 alias provider inside the module for the CloudFront deployment.

Anyway, I will take a look by tomorrow and test some deployment configurations in eu-west-1 region to see if I can reproduce it.

[tricoder42]

The problem isn't different region, but different aws profile.

// main.tf
provider "aws" {
  profile = "my-profile"
}

// dealmore/terraform-aws-next-js/provider.tf
provider "aws" {
  region = "us-east-1"
  // profile is missing and terraform uses `default` profile
}

I've just confirmed that those missing resources from proxy-config module were created in my personal AWS account and not my client's account.

Using AWS_PROFILE environment variable instead of profile inside provider block is one possible workaround.

EDIT: Workaround is actually using AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY because s3-put command doesn't seem to read AWS_PROFILE env var.

---

I'll check later if there's another way how to pass profile to providers in modules. I guess passing providers explicitly to submodules would solve the issue as well.

In more complex situations there may be multiple provider configurations, or a child module may need to use different provider settings than its parent. For such situations, you must pass providers explicitly — Passing Providers Explicitly (last paragraph above the title)

[tricoder42]

Unfortunately, I'm gonna drop this module because we simply have too specific requirements for origins and behaviors. Feel free to close this issue.

Thank you anyway! This module has very interesting deployment approach. Pity that cloudfront in terraform doesn't allow more granular management of resources.