How can I move EC2 instances to a different subnet?

Question

I have a VPC set up in AWS. we have created 2 subnets (A/24 and B/24), straight using all the IP having no IP's/Subnets for further usage.

We find that the b/24 is not totally utilized and we are wasting the Ip address in that.

Now we want to reduce the subnet size and move the instances from B/24 to A/24. and create 4 smaller subnets from B/24 and of /28 range and move back the servers to one of the smaller subnets created.

Please advise what are the suggested best practices we can apply in a way that we should be able to keep our available servers in B/24 and create multiple subnets as well.

Britteny

This question might do better on the ServerFault site – Cao

I effecitvely did this by cheating - i wanted to move my EC2 instance from my public subnet to a private one. Essentially I changed by SUBNET - by making the public subnet private - and vice versa. – Cyclamate

Answer 1

Creating smaller subnets is pretty straight forward. Delete the subnet and create new subnets. However, you'll want to transition off the boxes in B/24 before you delete it.

Now, moving a running machine between subnets is not possible*. Depending on your application and your requirements, I imagine that shutting it down, taking an image of the machine, then launching a new instance of that machine in the other subnet will work.

*As an aside, I wondered if you could attach a new network interface from a new subnet and then remove your old network interface, effectively moving subnets without having the take the box down. As it turns out, you cannot remove the network interface at index 0, which means this does not work.

Benefic

thanks for ur response, Well it is not possible to remove the primary interface from the instance. – Britteny

As far as the old and new subnets are in the same Availability Zone. Detach volume from old and attach to the new instance, including the root volume. – Cadence

Answer 2

Maybe you only need to "access" a different subnet...

It's true that you will never get the AWS web console to display any other value for "Subnet ID" in the instance details. Others have explained how to create new instances that will "be on" the desired subnet. I needed to take an existing server running software that was licensed to "one non-transferable Host ID" and "put it on" a different subnet. (Of course when I say licensed software, I'm talking about Windows software from a vendor who "doesn't support AWS"!) I solved this by:

1. Create a new network interface (AWS > EC2 > Network Interfaces) on the desired subnet and the same availability zone as the machine.
2. Attach the new nic to the machine. (AWS > EC2 > Actions > Networking > Attach Network Interface)
   • In Windows the interface just appeared!
3. Set the "Metric" ("priority" integer, lowest wins) of each Network Connection (Control Panel > Network and Internet > Network Connections > [double-click connection name] > Properties [button] > TCP\IPv4 > Properties [button] > Advanced [button] > Automatic Metric [uncheck] > Interface metric)
4. To confirm the routing table call route print from the command line.

Now everything the machine does is on the desired subnet. It is still reachable on the old IP (and previous subnet) as well as on the new IP (and desired subnet).

This is a pretty narrow case, but I hope it helps someone.

Kernite

You can also disable the adapter and skip 3 & 4. – Copolymerize

I prefer this new answer to my old one. – Copolymerize

+1 This answer is underrated. For a Linux machine, simply stopping the instance and attaching the secondary ENI was sufficient to resolve private IPs on the public EC2 instance - PS: don't actually do this for production workloads! – Respect

Answer 3

Only way is to stop then create AMI, then launch from the image in AZ of your choice (as of Apr 2015)

Copolymerize

this is not the only way, you can move the EBS volume without needing a new AMI but it has to be in the same AZ – Knocker

There is no way if the machine uses an ephemeral storage as os hdd – Jemmy

Answer 4

You can create new instance in the target subnet, but same AZ, and then detach/reattach the EBS volumes from the original (including the root volume) to the new instance. This may result in a shorter downtime because you can create the new instance will the original is running but is a bit more complex to carry out.

Rampant

Answer 5

For some specific use cases, like moving an instance from a public subnet to a private one, where you are not too tied to a particular subnet, and just looking to make changes for routing purposes and all, one approach can be to just change the route table associated with the subnet.

For example, I had created an instance in a public subnet, which I later realised, needed to be private. There weren't any other instances in either subnet. So, I simply reassigned the route table, which was associated with the private subnet (the one which only had entries for the local subnet, and for the NAT Gateway) to the public subnet. Similarly, I changed the private subnet to now point to the public subnet route table (one which had the entries for the Internet Gateway, along with the local subnet).

This didn't change the subnet mask or the IP address range for my EC2 instance, since the subnets remained the same. But in terms of network reachability, the subnets were reversed, and my EC2 instance effectively moved from a public subnet to a private one.

Pittman