Let me know if it is possible, it will be very helpful.
Thank you for the clarification. I believe you meant using stateless managed instance groups as explained in this document. It is currently not possible to modify the naming convention of stateless managed instance groups as it randomizes the suffix when creating new instances from the instance template (Replication happens based on the instance template and not existing instances).
The only exception is when you manually add an instance with any name as explained earlier by my colleague and per this document. Quoting from the document, “The names that you assign to these managed instances persist if the MIG recreates the VM.” This is in autohealing events and not when autoscaling. If the instance failed a health check, autohealing would recreate it with the same name.
To explain, stateless managed instance groups should not persist data on the instances. Generally they should be used as front-end applications. Meaning that autoscaler would create and destroy instances per configurations while data should persist on a backend database or a storage solution. Usually the group should be behind a load balancer, and the traffic would be directed to the instances without worrying about instance names. This document should explain more about load balancers.
However, I agree that you may have a good use-case to change the naming convention. As such, I suggest creating a feature request as per this document. Please provide a detailed explanation about the use-case when creating it. This would help the product team prioritize the request accordingly.
Another workaround and if you do not require an autoscaler, is utilizing unmanaged instance groups. You can manually create any non-identical instances and add them to the group as explained in this document.
I hope this helps.