In D12959#366803, @bartek wrote:

Accepting because according to your test plan, it worked. It should work as long as aws-cli-v2 is used because it supports AWS_DEFAULT_REGION.

But be aware that AWS_REGION env takes precedence over AWS_DEFAULT_REGION in the CLI and generally the former should be used. This script will fail if somebody sets AWS_REGION to something else.

More context: https://stackoverflow.com/a/75670789 and https://docs.aws.amazon.com/sdkref/latest/guide/feature-region.html
It's unfortunate that SO has better explanation than official docs ¯\_(ツ)_/¯

include default blank landing domain

full review feedback

review feedback. use secrets.json approach instead of .env

In D12906#365084, @bartek wrote:

Nice! The code structure looks neat!
In the future we can do a similar thing to our ECS services - modules can help avoid lots of duplication.

The only thing I have mixed feelings is the name node_service - I think of it as a Node.js service (in fact it is) 😅 Could it be sth like keyserver_node_service? IDK

P.S. Have you tried terraform state mv or just killed old resources and restarted? :D Just curious, I'd do the latter

Planning to change .env to secrets.json approach

In D12928#366013, @bartek wrote:

General question:
What's the advantage of sops-encrypting new .env files instead of reusing our sops_file resource for secrets.json, having webapp-specific config inside it, and then doing

webapp_environment_vars = merge(local.secrets.webapp_secrets,  { ... })

?

I'm not saying your approach is bad, I just want to understand the motivation

rebase

In D12623#357165, @bartek wrote:

This was triggered recently and might've been a websocket health check or something related.

It's worth checking if clients aren't broken and they do send the message

rebase

rebase

update descriptions for landing and webapp security groups

review feedback and rebase

rebase