The replacement node is either based off an image recorded when the system is first deployed, or an updated image after a software upgrade. The replacement node has the same secondary IP, elastic IP, and identifiers as the replaced node. The primary IP address of the replacement node will be new. However, if you had allocated an elastic IP address to each node when you deployed your instance, the public IP address should be the same after the node recovery. The secondary private IP addresses will be the same regardless of the elastic IP address settings you chose when you deployed the instance. At least one free IP address in the subnet is required.
You must create a new system image after a software upgrade. If you do not create this image, the software on the recovered instance will not match and the database cannot start if a node failure occurs.
Node failure recovery is handled differently than on-premises systems. Unless you want failed nodes to continue running for diagnostic purposes, you should terminate the instance. If AWS Support cannot diagnose the issue, contact Teradata Customer Support.
There is a cost associated with keeping this downed node running. You have the option of stopping or terminating the instance after the new node is brought online. You can also configure the instance to stop or terminate before a node failure.
Node failure recovery takes longer than a typical reset. There are dozens of reasons for a node failure and it may be difficult for you to determine the cause. However, if your instance does not automatically restart after 10 minutes, first check the alerts in Teradata Server Management or Teradata Viewpoint. You must create the alerts before the node failed. If you cannot resolve the node failure after reviewing the alerts, contact Teradata Customer Support.