source_dest_check inconsistent behaviour

[kempy007]

Description

The source_dest_check is inconsistent when you explicitly set network_interface. It fails to apply to the instance, but does apply to the ENI's. I have also found that using the implicit networking type before the explicit type leaves something in the module that make the explicit behave as expected. please see the embedded plan to reproduce this issue.

• [X] ✋ I have searched the open/closed issues and my issue is not listed.

Versions

Terraform v1.8.2 on darwin_arm64

• provider registry.terraform.io/hashicorp/aws v5.51.1

• Module version [Required]: ~> 5.0

Reproduction Code [Required]

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region = "eu-west-1"
}

resource "aws_vpc" "example" {
  cidr_block = "10.0.0.0/16"
  tags = {
    Name      = "Project VPC"
    Terraform = "true"
  }
}

resource "aws_subnet" "public_subnets" {
  vpc_id            = aws_vpc.example.id
  cidr_block        = "10.0.0.0/28"
  availability_zone = "eu-west-1c"
}

resource "aws_subnet" "private_subnets" {
  vpc_id            = aws_vpc.example.id
  cidr_block        = "10.0.4.0/24"
  availability_zone = "eu-west-1c"
}

resource "aws_network_interface" "public_eni" {
  subnet_id = aws_subnet.public_subnets.id
  tags = {
    Name = "Public ENI for VMX"
  }
}

resource "aws_network_interface" "private_eni" {
  subnet_id = aws_subnet.private_subnets.id
  tags = {
    Name = "Private ENI for VMX"
  }
}

// Explicit Networking
// does not work for src/dst on the instance only set for ENI.
// "network_interface": conflicts with vpc_security_group_ids & subnet_id
module "ec2-ex" {
  # depends_on = [ module.ec2-im ] // comment out to test the ordering affects.
  source  = "terraform-aws-modules/ec2-instance/aws"
  version = "~> 5.0"
  name    = "test-explicit-net"
  ami           = "ami-0776c814353b4814d"
  instance_type = "t3.medium"
  network_interface = [
    { device_index = 0, network_interface_id = aws_network_interface.public_eni.id, availability_zone = "eu-west-1c" },
    { device_index = 1, network_interface_id = aws_network_interface.private_eni.id, availability_zone = "eu-west-1c" }
  ]
  source_dest_check = false
}

// Implicit Networking
// This works for src/dst on the instance only.
// "subnet_id": conflicts with network_interface
module "ec2-im" {
  depends_on = [ module.ec2-ex ] // comment out to test the ordering affects. 
  source  = "terraform-aws-modules/ec2-instance/aws"
  version = "~> 5.0"
  name    = "test-implicit-net"
  ami           = "ami-0776c814353b4814d"
  instance_type = "t3.medium"
  subnet_id            = aws_subnet.public_subnets.id 
  source_dest_check = false
}


output "ids" {
  description = "List of IDs of instances"
  value       = [  module.ec2-ex.id, module.ec2-im.id ]
}

output "public_dns" {
  description = "List of public DNS names assigned to the instances"
  value       = [  module.ec2-ex.public_dns, module.ec2-im.public_dns ]
}


// Outcome of this plan without depend_on
// Implicit ENI Src/Dst check is disabled (enable unticked), Explicit ENI Src/Dst check is enabled (enabled ticked)
// Implicit Instance Src/Dst check is disabled (stop ticked), Explicit Instance Src/Dst check is disabled (stop ticked)
//
// Expected the explicit instance to be enabled (stop unticked) so the outcome was a surprise, However if run with implicit commented out it will be enabled (stop unticked) as expected. 
// In the plan where we have a problem, the explicit method is called early before any implicits, and it looks like this is the other way around with implicit called first.
// Added depends_on so order can be switched to show the inconsistent behaviour with explicit then implicit order. 
// So if the implicit is called before the explicit we get the correct behaviour, so something must be activated in the module that is still set for later blocks in their execution.

Steps to reproduce the behavior:

Use plan listed above terraform apply --auto-approve in aws > ec2 > instances > networking > Change Source / destination check. Expect this value to be ticked for all instances.

Expected behavior

Change Source / destination check. Expect this value to be ticked for all instances.

Actual behavior

Value is not applied consistently, you can reverse the order and see that it is applied as expected.

[github-actions[bot]]

This issue has been automatically marked as stale because it has been open 30 days with no activity. Remove stale label or comment or this issue will be closed in 10 days

[github-actions[bot]]

This issue was automatically closed because of stale in 10 days

[github-actions[bot]]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.