A bit off-topic, but have you been in touch with PlayFab with regards to this issue? I.e. so they can actively ask for new instances if they get instances in the (Russia) banned IP-range.
Or is there something you can do at your side? AFAIK (by just looking at code, not testing, assuming you use the Lua SDK provided by PlayFab), the implementation of
IPlayFabHttps.MakePlayFabApiCall seems to be responsible for the actual API-call. (see https://github.com/PlayFab/LuaSdk/blob/master/PlayFabClientSDK/PlayFab/IPlayFabHttps.lua for interface, which I’m assuming that you are using)
Should it not be possible to catch SSL-errors and force a try on all IP-addresses related to the FQDN? This would get a bit technical though, since you would have to separate the TCP connection, the TLS-handshake, and the HTTP-requests (remember that HTTP + TLS == HTTPS, they can be separated). And since you would ideally force a TCP-connection on an IP-address base rather than a FQDN, you would have to manually trust the CA (in this case the Amazon CA which the *.playfabapi.com certificate is anchored by).
This approach would get rid of the problem of trusting the naming and routing provision of the access-provider (i.e. ISP in most cases), which sometimes is necessary, without tunnelling or similar overhead or static setup of hosts files (i.e. forcing 5107.playfabapi.com to resolve to a specific non-blocked IP).
See http://notebook.kulchenko.com/programming/https-ssl-calls-with-lua-and-luasec for a basic example on how to separate IP-host from URL-host (Internet knowledge 101, the FQDN of the url in the http-request need not resolve to the IP-address of the server for a HTTP over TLS over TCP over IP connection to work…).
- Write custom http(s) client capable of separating host and url
- Resolve all A-records for FQDN (ex by
- Trust amazon CA for IP-based TLS-connections (see https://www.amazontrust.com/repository/)
- Loop through all IPs.
- Use above as fallback when the first IP returned by the OS DNS resolved is not routable (i.e. using built-in LuaSec https-client).
- (ideally it would be possible to route everywhere, but for now that is not possible)