Ага, расскажи зачем она вам там, если можешь)
Ну короче.
В паблик-клауде инстансы надо двигать между машинами. Например потому что клиенты их выключают, а потом включают через год. Ну и много еще других причин, хороших и плохих.
То есть, фактически надо уметь в VM mobility, пусть и не реалтайм (хотя реалтайм тоже). Что, как известно, сложно.
Для этого надо per vm state либо на всей сети, либо какими-то кусками. И чтоб это скейлилось до сотен тысяч инстансов — ну, это непросто.
Мы над этим работаем, но в свое время (я тогда еще в Москве жил) ребята решили, что как-то это все будет чересчур долго и сложно, и придумали менять инстансам адрес при миграции, а чтоб, значит, публичный адрес не менялся, натить это все 1:1, и менять трансляции при смене адреса для инстанса.
Спорный вопрос, насколько в 2013/14 году это было правильное решение, но, скажем так, я понимаю, почему так было сделано, и не знаю, смог ли бы я тогда сделать лучше. Кстати DO для целей floating ip с некоторых пор делает то же самое.
Для целей ната 1:1 ребята тогда написали dpkd-based движок, который назвали Наташей.
Некоторое время назад (чуть меньше года) все это хозяйство перешло под управление департамента, которым я и мой начальник Микаэль (нет, он не арменин) творчески руководим. Какое-то время новые ребята въезжали в код, потом взяли грубый рашпиль, малость обточили до состояния «более-менее», накатили в прод, пофиксили пару вылезших багов, после чего пришла мысль выложить это в опенсорц. Ну, типа, да, вещь специфическая, но перформанс вполне достойный — почему нет, может, кому надо (в MX, в конце концов, есть inline 1: 1 nat). Микаэль эту идею особенно поддержал, топнул на ребят ногой, мол, не ссыте, ну и вот.