Feature Request: random IP from CIDR range

[bschaatsbergen]

It would be nice to have a resource that generates random IPv4 or IPv6 addresses within a specified CIDR range.

Why:
I'm sure this can serve various purposes, as people are more creative than I am.

Use cases I can think of:

• Helpful to combine with the terraform test framework, performing egress network connectivity tests against a set of generated IP addresses in a range I'm actively denying or allowing.

Example usage

Basic:

resource "random_ip" "example" {}

IPv4:

resource "random_ip" "example" {
  cidr_range   = "192.168.0.0/24"
}

IPv6:

resource "random_ip" "example" {
  cidr_range   = "2001:db8::/32"
}

Using a count:

resource "random_ip" "example" {
  count        = 5
  cidr_range   = "2001:db8::/32"
}

output "random_ipv6_addresses" {
  value = random_ip.example[*].result
}

Using a count followed by a distinct:

resource "random_ip" "example" {
  count        = 50
  cidr_range   = "192.168.1.0/28"
}

output "random_distinct_ipv4_addresses" {
  value = distinct(random_ip.example[*].result)
}

I'm would love to contribute this new resource if it aligns with the vision of this provider and is something we intend to support. :)

[bschaatsbergen]

What are your thoughts on this @bendbennett?

[austinvalle]

Hey there @bschaatsbergen 👋, thanks for raising this issue!

Just wanted to quickly point out, since the random provider is so heavily used by the community, one of the main design goals is stability over features. That's not to say we won't accept any new feature, but rather we want to ensure that new features aren't being added without ample design consideration. Another piece of consideration was mentioned by @bendbennett, which is interest from the community.

The feature requested here is an expansion of what the random provider does today and it does feel like it could lead the provider down a "slippery slope" of new features related to context-specific random strings. (random time, dates, IPs, emails, etc.)

Use cases I can think of:

Helpful to combine with the terraform test framework, performing egress network connectivity tests against a set of generated IP addresses in a range I'm actively denying or allowing.

If this is the main drive behind this new resource, that might make a good candidate to live in a new provider that focuses on generating realistic mock test data, a Terraform sibling of something like faker-js. The recent addition of test mocking in Terraform 1.7 might make providers that produce realistic fake data like that more desirable.

I see a couple others have upvoted this issue in particular, so if there are any use-cases for random IPs that are not mocking/test data specific, we would be interested to hear about those as well.

[bschaatsbergen]

Hey @austinvalle, appreciate the detailed feedback on the requested feature. I understand the importance of prioritizing stability over additional features, and I agree that we should carefully consider which resources to incorporate into this provider. Has a realistic mock data Terraform Provider been discussed before? If the DevEx team is keen on having this, I would love to kick start this - generating realistic mock data such as dates, IPs, and email addresses. What's your take on this?

[austinvalle]

Has a realistic mock data Terraform Provider been discussed before?

I'm not 100% sure, although my team isn't as involved with the Terraform module testing functionality recently released. I'd imagine folks closer to that community would have a better idea on how useful a provider would really be there. (vs. just hardcoding test data)

If the DevEx team is keen on having this...

The providers our team supports are more focused on RFC-backed functionality (like time (RFC3339), dns, http, tls, etc.) and we don't currently have any plans on expanding that scope. It's possible that could change in the future, but I'd say if you're interested in that type of functionality (mock test data) from a provider then it'd be more appropriate to create a community provider.

[ciffelia]

I’d like to chime in with another potential use case for the random_ip resource that I think could be quite valuable, especially in the context of AWS.

One common scenario involves deploying EC2 instances where we need to ensure a stable public IP (or, in the case of IPv6, a stable address) across instance replacements or redeployments. For example, with IPv4 EIP (Elastic IP), we can assign a static public IP to an instance that remains consistent even during instance recreation.

However, when working with IPv6, there isn’t always a direct equivalent of an EIP for IPv6. I’m thinking the random_ip resource could be used as a stable IPv6 address source, avoiding the need to manually hardcode one while still ensuring that the IP doesn't change across instance recreations.

Here’s how it could look in practice:

resource "aws_instance" "main" {
  ipv6_addresses = [random_ip.main.address]
}

resource "random_ip" "main" {
  cidr_range = aws_subnet.public.ipv6_cidr_block
}

resource "aws_route53_record" "main" {
  zone_id = "..."

  name    = "www"
  type    = "AAAA"
  ttl     = 300
  records = [random_ip.main.address]
}

This would allow for a dynamic yet stable IPv6 setup, which could be particularly useful in VPC use cases where you’re deploying many instances but want predictable IP addressing without needing to hardcode specific IPv6 addresses upfront.

Thanks for considering this perspective!

[austinvalle]

Thanks for the use-case @ciffelia 👋🏻

---

For any future travelers of this feature request, the current status of this issue is the maintainers would like to see more use-cases for how this random_ip resource would improve your general workflow today. Even better would be to see more examples of use-cases in a couple different of our main CSP providers (aws, azurerm, google). If we can show there is broad applicable uses for something like random_ip, then it's more likely to be accepted.

Some additional things to consider including (@ciffelia has a great example as well, providing a use-case):

• What are the workarounds you have to write in Terraform config today to achieve a similar result?
• Is this something that the specific provider (for example, aws and their EIP IPv6 situation) would be better off solving?
• Any additional pain points you think may be relevant 🙂

[kaspergrubbe]

I used it for Hcloud (Hetzner) and their private networks, I wanted to ensure that my instances had a different IP, I had to do an ugly workaround with random_integer and using keepers and interpolation.

This would make it 100 times more smooth.