Does anyone know a nice way of running a fixed auto-scaling group of 1 (to keep an instance up & running) but ensure that its primary network interface (ENI) referenced in the launch template is using one that already exists/setup?
It doesn’t seem like it’s possible in AWS?
(the console moans/blocks and terraform errors when trying to apply)
Still as true in 2024 as it was in 201X?! iirc we were stuck with using user data + shell scripting to achieve the same effect…was hoping it improved over time.
Yeah, that what I was thinking, I’ll look to try and keep the primary ENI as a dummy (unused) and then as part of the user data, detach (if needed) & attach the fixed ENI I need for the server and then update the server’s routing to make sure the secondary ENI essentially handles all the server traffic.
Bit of a pain, but hopefully that’ll work, thanks.
It would be lovely it they supported ASG=1’s with special conditions to allow us to do this without all the hurdles :shrug:
It always felt gross because you can end up in a situation of losing that host and getting a replacement, but the old one takes forever to die and release the damn ENI.
So then you loop for N minutes hoping to outrun it. 
I guess that less of a concern if the ENI is a secondary rather than a primary, eh?
i.e., you can force detach a secondary, whereas it wouldn’t presumably let you do that with the primary (you’d have to wait until it was terminated)
Yeah we just ignored the primary and set all routing through the secondary. These telephony proxies have been running for a long time now unhindered.
Awesome ok, sounds like that’s the way to go with this, I appreciate you taking the time for me, all the best
No worries, familiar tiger traps inspire both warm and terrifying memories.
I just wish there was a more AWS-friendly and most of all less invasive way.
Not meaning to be flippant, but why would you want a persistent ENI to be attached/removed to an instance in an ASG?
Not at all… it’s for a NAT instance where the ENI is the terraform’ed resource that already has the security groups/elastic IP setup.
I figured that was the cleanest way of sorting it out (i.e., rather than updating routes, just attach the ENI to the server which should be acting as the NAT G/W for the private subnets)
If you know a better way though I’m all ears!
There a reason you’re not using AWS NAT gateways?
AWS has enough money? 
NLB were just coming out at the time I needed to build this rat’s nest, maybe that’s a more modern alternative. Still not free, but neither are EIP.
Fair, and yes the NAT gateways still charge way to much especially if you have a lot of traffic. We decided the reliability of the AWS gateway was worth it for us.
Back when we used nat instances, we had 2 static instances - one in each AZ, but there was a script to check the health of them and take over the other AZ’s routes if it detected a network or aws health failure, which was a bit more common in those days. The modern instances have very few outages, though.
If I had to do what you’re doing, I’d just have a userdata script for the incoming instance un-associate the IP from whatever owned it, then associate it with whatever ENI came up with it, and update the route table for its AZ and not deal with ENIs itself.
No school like the old school, I guess.
