Floating IP billing change

Would you please consider a change in your floating ip billing to only charge at the hourly rate, up to the monthly rate, when the ip is not being used? Or at least allow this change in billing for a few limited number of ip's before converting to the full monthly rate at all times?

There seems to be precedence for this by other vendors. (Digital Ocean, on their pricing, also described on their blog: https://blog.digitalocean.com/floating-ips-start-architecting-your-applications-for-high-availability/)

Thank you for a great service. I am a new user, but am very impressed.


  • But If it's allocated to you, it's a resource you are holding. What difference does it make if you're using it or not?

    Anyway, I'm not sure what you mean about billing. The IP's are charged at the hourly rate... The quoted monthly rate is how much that adds up to over a month.

    There is a minimum time of 24 hours to owning one, but after that you can close it when you like - you only pay at the hourly rate.
  • To answer your question for clarification: When I deploy a server instance, I am assigned an IP, and I assume I can use that same IP until the server instance is destroyed. I do not have to pay extra to use the IP that I was assigned. I am holding the IP resource while my server is deployed, and I am paying for it through my monthly or hourly server charge.

    If I request a floating IP, I pay an hourly rate for it regardless of whether it is being used by a server instance or not. When I am reserving the IP and not using it for a server, it makes sense why there is a charge because the resource is being used, even if not attached to a server instance. However, if I use the floating IP as the only IP for a deployed server, then it would be like paying twice to be permitted access to 1 IP resource: paying once through the normal billing for a server instance that includes an IP, and a second time for the floating ip reservation.

    The only thing that I might be misunderstanding, that would explain your response, is if the floating ip is assigned as a second external ip. If a server instance has 2 external ipv4 addresses, then, of course, it would make sense to pay for both ip's. However, my assumption was that a floating ip would become the only external ipv4 of a server instance.

    The simple use case is: if I have a server deployed with an ip, then I destroy it for some reason. At that point, I would normally lose the ip and get a new one. Instead, I would pay to reserve the floating ip while the server is destroyed. Once I deploy a new server, and start paying for it, it would be assigned the floating ip as it's only external ipv4, so that external references to the server would still work.

    If an ip is never taken away from a deployed instance, based on the current pricing, it would be equivalent to always pay for the smallest server to hold 1 ip, and act as a router through the internal network to new servers deployed at the same data center. This would effectively be the same for the use case described, for about the same cost. However, it might allocate more resources away from the Vultr infrastructure than needed, since the fixed ip is the wish, not the additional computation resources.

    Anyways, it is just an idea for "Features and ideas". I'm not complaining. I just saw the way that digital ocean does it, and after reflection, thought it made sense. As I said above though, I could be misunderstanding that floating ip is actually an additional ip for servers. Regardless of whether anything changes, I fully intend to continue to be a vultr customer--it's just a suggestion. Perhaps the cost of bookkeeping the floating ip has a minimum cost that needs to be recovered, and that is the overhead charged to the customer. I can understand that as well.
  • Thanks Jamie, your suggestion worked. I reserved an ip, destroyed my server, waited 24 hours, deployed a server, attached the reserved ip, then destroyed the ip reservation. The minimum 24 hr ip reservation made it take 2 days to test, but it worked like you said. It just required more steps to do it manually.
  • edited June 2018

    Ahhh, I get you now!

    It was always my understanding that the hosts always had one IP address allocated from the usual pool, and that the reserved IP was indeed an extra one you added as required - as you deduced in your reply!

    If this is not the case, what you say does indeed make sense - although to me it would seem easier to keep the reserved IP charge as is, and have an "IP-less" server option at a discount, so then you'd know where you stand regarding "when it's charged, when it's not".

    ..... Just did a test. You are right! A reserved address can be attached to a new instance without any other IP. I'd never done it that way before! But yeah, why are you paying for what are effectively IP-less servers (I mean in the sense that you are only pulling in your IP you are already paying for) the same price as ones with an IP?

    Sorry for the confusion.
  • @john44

    Thanks Jamie, your suggestion worked. I reserved an ip, destroyed my server, waited 24 hours, deployed a server, attached the reserved ip, then destroyed the ip reservation. The minimum 24 hr ip reservation made it take 2 days to test, but it worked like you said. It just required more steps to do it manually.

    No problem! I'm assuming from that that you only needed the reserved IP whilst you transitioned from machines, waiting for the DNS to catch up, at which time you could drop the reserved IP for the new one.... Makes sense.

    And yeah, a bit convoluted, but my guess is that (and this is just a guess!) a reserved IP is more special than an ordinary one, in that is has to be one than can easily be routed to any server on-site.

    You are now back to using an ordinary IP - if the reserved address wasn't charged when attached (i.e. it was paid for via the instance subscription) you'd be still using only that one, and holding a more critical reserved IP at no more cost to you than if you were using an ordinary one.

    Or maybe, simply, vultrs work in mysterious ways!
  • @jamie

    (I'm just writing this in case someone else is trying to do the same thing.)

    One step I left out: When I reserved an ip, I actually reserved the ip that I was already using. There is an option to do that.

    In this way, I was able to keep the ip the same, even though I destroyed my server instance.

    When I destroyed the ip reservation, I didn't lose use of that ip by the server it was attached to.

    So it seems that reserved ip's are not "special". Any ip can become reserved. It can be reserved from any existing ip that you already have. It can also be assigned to any server instance. I assume that it could be limited to one data center, though I haven't tested it. If the reserved ip could cross data center boundaries, that would allow you to migrate a server from 1 location to another and still keep the same ip... (that would be a cool feature) However, that's not something I was trying to do, for now.

    The only thing that would be really convenient, is if Vultr would just say the minimum charge to reserve an ip was $0.11 (hourly rate *24hr), but let me destroy the reserved ip before 24 hours was over, so that I wouldn't have to set a reminder in my calendar to come back and do it. (Technical support said the system does not allow ip reservation destruction before 24hrs, so I trusted them and didn't try.)
  • @john44

    Oh! Thanks for that - I didn't know you could reserve your current IP like that. In that case, my guess was wrong, and your suggestions make perfect sense...

    Seems vultr does work in mysterious ways!

    Fixed IP's are bound to the data centre though. I don't think global routing tables are allowed for anything less than a /24 (256 address-block!)

    Totally agree on being able to schedule a deletion immediately (even if it's queued to not run until after the 24 hours.) I wrote similar on another thread :-)

    Oh, I tried to delete after about 4 hours - it didn't work - it said I "needed to wait the minimum of 24 hours, and I should have believed them like John did"

    (ok, only half that last sentence is true! :-) )

  • edited January 2019
    This thread was very helpful. Today, I learned two things:
    1) How to transfer an IP address by Reserving an existing one, destroying that instance, then assigning it when I launch a new instance.
    2) That I didn't need to do all that because I could have just used the Settings for that instance to Change the OS…which reinstalls from scratch. That would have saved me a few steps as I replaced Ubuntu 14.04 with 18.04.

    No worries, as it let me have fun tinkering. All in all, a good day. Thanks!
  • Sorry to wake up old thread - just got here by Google search.

    The pricing by Vultr does seem to be punitive and discourage folks from using this feature.

    I know AWS also charge the more reasonable way described above --- you have an hourly charge for keeping the IP ***only*** if it is not attached to an instance (makes sense since you get a 'free' IP with an instance anyway).

    Its a shame that Vultr charge always - as mentioned, it just encourages folks to go for the smallest instance to lock down the IP

Sign In or Register to comment.