익명 18:47

Is reusing old ENI IP for new Domain Controller in AWS EC2 a safe and correct ap...

Is reusing old ENI IP for new Domain Controller in AWS EC2 a safe and correct approach? [closed]

We need to upgrade a Domain Controller in AWS EC2 from Windows Server 2016 to Windows Server 2025, and want to validate the approach to avoid any production issues.

Current Setup

  • Windows Server 2016 DC (EC2)
  • AD DS, DNS, LDAP/LDAPS
  • Applications use this single DC for authentication
  • DC has a specific private IP via its primary ENI

Target Setup

  • New EC2 instance with Windows Server 2025
  • Will be promoted as an additional Domain Controller
  • Eventually will replace the existing DC

Goal

  • Keep the same hostname and IP for the new DC
  • Avoid DNS/IP changes on application side

Planned Approach

  • Build new server and join domain
  • Promote it as a Domain Controller
  • Transfer FSMO roles
  • Validate replication and authentication
  • Demote old DC (while it has its ENI and IP)
  • Stop old EC2 instance
  • Detach old ENI from old instance
  • Attach that ENI to new server as secondary ENI

Configure new server so that:

  • AD/DNS uses the IP from the old ENI
  • Primary ENI IP is NOT used or registered in DNS
  • Rename new server to match old DC hostname

Questions

Is it a supported and safe approach to run AD DS using an IP from a secondary ENI instead of the primary ENI?

Are there any risks with:

  • DNS registration (multiple IPs getting registered)?
  • Kerberos / LDAP / LDAPS behavior?
  • DC locator issues (SRV records)?

Is there any chance of issues if the DC is multi homed with the primary ENI has a different IP and the DC is bound to a non-primary interface?

Are there recommended alternatives for achieving same IP continuity and zero application changes?

What should I verify/change to ensure that only the old IP is used for AD/DNS, and no duplicate or incorrect DNS records exist?

I want to avoid breaking authentication, DNS inconsistencies, and manually updating application configs.

Environment

  • AWS EC2 (same VPC/subnet)
  • No load balancer in front of DC
  • Direct application-to-DC communication (LDAP/LDAPS)

If someone has implemented a similar approach or can validate best practices for this, it would really help.



Top Answer/Comment:

Comment: That is not a good approach. Renaming a DC is not a typical or supported or recommend operation. Of course it is possible, but it is more difficult and unnecessarily convoluted when further deviations are present that severely limit or constrain your options. Additionally, applications with username and password auth using "LDAP" without TLS will fail with Windows Server 2025. This may be a good time to step back and ask what you are doing and why you are doing it this way. If the objective is simply to upgrade the Windows version of the DC from 2016 to 2025, this is not the correct method.

상단 광고의 [X] 버튼을 누르면 내용이 보입니다