Self-Hosted ServiceNow Platform on AWS Auto Scaling Groups: How to Implement

This guide covers running the self-hosted ServiceNow platform on EC2 using AWS Auto Scaling Groups. The terraform-asg-servicenow repo implements launch templates, placement, health, and scaling for the platform instance—not mid-servers.

Why use an ASG for self-hosted ServiceNow?

Self-hosting customers run the ServiceNow platform on their own infrastructure. A single EC2 instance is a single point of failure; if it goes down, the platform is unavailable. An ASG keeps a desired number of instances running, restarts failed ones, and can scale out when you need more capacity. You get resilience and optional scaling without managing each server by hand.

Launch template and AMI

Use a launch template that specifies the ServiceNow versioned AMI, instance type (sized for the platform), IAM role, and user data (or a config management hook). The AMI should contain the platform build approved for self-hosting. Pre-baking the AMI ensures every instance runs the same version. Give instances an IAM role with access to Secrets Manager (or Parameter Store) for database URLs, admin credentials, and license-related config. Example (Terraform):

resource "aws_launch_template" "servicenow" {
  image_id      = data.aws_ami.servicenow_versioned.id
  instance_type = "m5.xlarge"
  iam_instance_profile { arn = aws_iam_instance_profile.servicenow.arn }
  vpc_security_group_ids = [aws_security_group.servicenow.id]
  user_data = base64encode(templatefile("${path.module}/userdata.sh", {}))
}

resource "aws_autoscaling_group" "servicenow" {
  min_size         = 2
  max_size         = 10
  desired_capacity = 2
  launch_template { id = aws_launch_template.servicenow.id }
  vpc_zone_identifier = var.private_subnet_ids
}

Full Terraform: terraform-asg-servicenow.

Placement and networking

Spread instances across multiple Availability Zones so a single AZ failure doesn't take out the platform. Put them in private subnets and put an Application Load Balancer in front so users (and optionally mid-servers or integrations) reach the platform over HTTPS. Use a NAT Gateway (or NAT instances) for outbound traffic (updates, external APIs). Restrict security groups: allow ALB → instances on the app ports; allow instances → RDS or other database.

Scaling and health

Set min and max size (e.g. min 2 for HA, max 10). Use target tracking scaling on CPU or a custom metric if your deployment supports it. For health, the ASG can use EC2 status checks and/or an ELB health check. Point the ALB at the instance app port; the ASG replaces instances that fail the health check. Ensure user data or startup scripts configure the platform (e.g. DB connection, cluster identity) so new instances join correctly.

Summary

Running the self-hosted ServiceNow platform on an ASG gives you high availability and optional scaling. Use a launch template with the ServiceNow versioned AMI and IAM role, place instances in private subnets across AZs, put an ALB in front for user access, and let the ASG handle replacement and scaling. Keep credentials and config in Secrets Manager. The terraform-asg-servicenow repo provides the Terraform for this self-hosting pattern.