Multiple replicas of subnet router

[begemotik]

I noticed that the recent major release removed the possibility to configure multiple replicas.
What is the rationale behind that?

[Gowiem]

@begemotik we typically only use one subnet router that we deploy into each VPC or if we're using a Transit Gateway, we deploy a single subnet router into the centrally shared VPC that then routes through to all the others. We typically don't see the need to deploy two since the resiliency of the subnet router is accomplished through the auto-scaling group if something goes wrong. Were you deploying multiple subnet routers and found that useful? Want to describe your reasoning a bit more? We're not opposed to making this configurable, so happy to accept a PR to change this up!

[wurbanski]

Hi @Gowiem,

I'm not the original reporter but I've recently found that I want to deploy multiple routers in separate VPCs, but as it stands SSM-related resources create collisions within the same account:

Error: creating IAM Policy (ssm): operation error IAM: CreatePolicy, https response error StatusCode: 409, RequestID: (...), EntityAlreadyExists: A policy called ssm already exists. Duplicate names are not allowed.

Error: creating KMS Alias (alias/session_logging): operation error KMS: CreateAlias, https response error StatusCode: 400, RequestID: (...), AlreadyExistsException: An alias with the name arn:aws:kms:<region>:<accountid>:alias/session_logging already exists

Error: creating SSM Document (SSM-SessionManagerRunShell-Tailscale): operation error SSM: CreateDocument, https response error StatusCode: 400, RequestID: (...), DocumentAlreadyExists: Document with same name SSM-SessionManagerRunShell-Tailscale already exists

currently there's no way of creating them only once or simply controlling the names to skip duplicate names error. I would love to create a PR to get it in - do you have any preferences of the approach?

Update: KMS Alias can already be renamed so I think it makes sense to follow the scheme for the rest of the resources, WDYT?

[gberenice]

@wurbanski thank you for reporting this issue!
You're right - the current implementation creates naming conflicts when deploying multiple Tailscale subnet routers in the same AWS account.
The best approach would be to follow the KMS alias scheme and make these resource names configurable while providing defaults that include the current module's values, e.g.:

locals {
  ssm_policy_name = coalesce(var.ssm_policy_name, "ssm")
  ...
}

module "ssm_policy" {
  name  = local.ssm_policy_name
  ...
}

variable "ssm_policy_name" {
  default     = null
  type        = string
  description = <<EOF
  Name for the IAM policy that provides SSM access for the SSM Agent.
  This is only applied if `ssm_state_enabled` = true.
  EOF
}

I'd be happy to review your PR!

[Gowiem]

@begemotik @wurbanski quick follow up with you two as I'd like to understand if we want some action here or if you two still found this was needed or found viable workarounds?