EC2 ASG component — Anything In-Flight?

[jaguer0]

Per the component development docs, checking if there's an EC2 ASG component in-flight before we build one.

Context on what we're after: An EC2 ASG component supporting two workload types for Windows & Linux

• Service — Accepts requests, ideally with auto-constructed hostnames to mimic the behavior of ECS cluster domains & app-on-ecs-v2
  (ex ALB (public/internal) or VPC-only via private DNS )
• Worker — No ingress, no domains; processes queues / background tasks

Currently piecing things together from bits of these, so figured I'd check before reinventing the wheel:

• terraform-aws-ec2-autoscale-group
• aws-spacelift-worker-pool-asg
• aws-bastion
• app-on-ecs-v2 — porting the domain & env var logic

Questions:

1. Anything existing (public or not yet upstreamed) we should know about?
2. If not, any recommended design patterns or approaches we might be missing? Specifically around component archetypes vs. mixins for the workload types, and achieving ECS-like domain/hostname parity on EC2 ASG.

Appreciate any guidance !

[milldr]

Hey @jaguer0. If I understand correctly, you're looking to build a platform or application on EC2 with Auto Scaling Groups, similar to the ECS approach.

When deciding how to structure your components, think about the lifecycle of the deployment. Will different parts ever be deployed independently, or are they always deployed together? Are different teams responsible for different pieces? If everything moves as a single unit, then a single component makes sense. Given how specific and tightly coupled this sounds, a custom component is the right call.

That said, you don't need to start from scratch. You can reuse existing modules like terraform-aws-ec2-autoscale-group as the foundation.

For the ALB, you have options. You could deploy it separately using the ALB component and wire it up to the ASG, or bundle it all into your single component. Either approach works, and neither is an anti-pattern.

[jaguer0]

okay I'll look into the custom component route with module terraform-aws-ec2-autoscale-group

still tryna wrap my head around like reusing the auto domain construction logic , I want to avoid hardcoding domain strings in the EC2 component if a standardized 'auto-construction' logic already exists for Atmos

for example the ecs compoonent has the following

alb_configuration:
  public: # name of the ALB to be referred to by other configurations
    internal_enabled: false # sets it to public
    # resolves to *.public-platform.<environment>.<stage>.<tenant>.<domain>.<tld>
    route53_record_name: "*.public-platform"
  private:
    internal_enabled: true
    route53_record_name: "*.private-platform"

then in app-on-ecs-v2 has the base_domains that auto construct the domain / creates the route53 records

older aws-ecs-service component has like this

import:
  - catalog/ecs-services/defaults

components:
  terraform:
    # The service itself
    ecs/platform/service/echo-server:
      metadata:
        component: ecs-service
        inherits:
          - ecs-services/defaults
      vars:
        enabled: true
        name: echo-server # the name, also part of the full domain name
        cluster_attributes: [platform]
        alb_configuration: "public"

like do I need to Create a shared "DNS logic" component that both ECS services and EC2 asg components to consume instead of ecs cluster component? or is there better ways via the !tfstate substitutions

[milldr]

You don't need a separate shared "DNS logic" component. The domain auto-construction in the ECS components isn't magic built into the ECS cluster. It comes from two things that are already available to any component:

1. context.tf (via module.this from terraform-null-label) which gives you a formatted name from your namespace, tenant, environment, stage, name, and attributes.
2. Remote-state lookup on the dns-delegated component, which outputs default_domain_name (e.g. use2.dev.plat.example.com).

You combine them with a simple format() call. Here's how you can do it in your custom EC2 ASG component:

# Pull in the domain from dns-delegated via remote-state
module "dns_delegated" {
  source  = "cloudposse/stack-config/yaml//modules/remote-state"
  version = "1.8.0"

  component = var.zone_component # e.g. "dns-delegated"

  context = module.this.context
}

locals {
  zone_domain = module.dns_delegated.outputs.default_domain_name

  # Auto-construct the full domain from the label context + the zone
  # This produces something like: my-service.use2.dev.plat.example.com
  full_domain = format("%s.%s", module.this.id, local.zone_domain)
}

# Create the Route53 record pointing to your ALB (or instance private IP)
resource "aws_route53_record" "this" {
  zone_id = module.dns_delegated.outputs.default_dns_zone_id
  name    = local.full_domain
  type    = "A"

  alias {
    name                   = module.alb.dns_name   # or however you reference the ALB
    zone_id                = module.alb.zone_id
    evaluate_target_health = true
  }
}

The ECS service component does the same thing. Take a look at how aws-ecs-service uses module.service_domain to remote-state lookup dns-delegated and then constructs local.full_domain using format() with the label context.

So the pattern for your EC2 ASG component is the same: include context.tf, look up dns-delegated via remote-state, and use format() to build the hostname. No !tfstate substitutions needed for this. Just standard Terraform remote-state.

For your Worker workload type, you just skip the domain/Route53 bits entirely (controlled by a variable like domain_enabled or workload_type).

[jaguer0]

@milldr Thanks for the clarification! I definitely had my wires crossed because the Atmos docs and Claude skills favor the newer approach using !terraform.state, whereas the aws-ecs-service and Ref Arch docs still had remote-state.tf.

I was trying to force the newer pattern, but re-reading the state-sharing guide alongside your example really helped it click for when to choose which method.

FWIW this is what the claude skill had (under /skills/developing-components)

Note on remote-state.tf: Avoid creating remote-state.tf files for new components. Instead, use Atmos functions
(!terraform.state) in stack YAML to pass values from other components. This keeps components simpler and moves
cross-component wiring to the stack configuration layer.

Thanks!