#refarch - February 2024

The CloudPosse style seems to prefer “singleton” components (e.g. lambda component deploys a single lambda, sns-topic deploys one topic). The exception to this is ssm-parameters , I guess because one terraform workspace per parameter would be painful to access via remote-state and slow to deploy.

I am considering creating “plural” component variants to maximise DRYness and reduce workspace sprawl for a few deployments. For example, an sns-topics component

# format TBC, not convinced the `try` is required if the "default/global" vars have null or empty defaults

module "sns_topic" {
  source  = "cloudposse/sns-topic/aws"
  version = "0.20.1"

  for_each = var.sns_topics

  subscribers = try(coalesce(each.value.subscribers, var.subscribers), {})
  ...
  kms_master_key_id   = try(coalesce(each.value.kms_master_key_id, var.kms_master_key_id), null)
  encryption_enabled  = try(coalesce(each.value.encryption_enabled, var.encryption_enabled), null)
  ...
  context = module.this.context
}

This seems like an OK idea to me, assuming that the resources have similar lifecycles, and in cases where you want to access outputs downstream in remote-state it would make that YAML cleaner. I notice that CloudPosse don’t seem to ever do this in the core component library, perhaps there is a very good reason why not… Is there a downside to this approach?

DynamoDB: Add support for the import_table block

https://github.com/cloudposse/terraform-aws-dynamodb/pull/120

A preemptive PR for refarch: https://github.com/cloudposse/terraform-aws-components/pull/981