Nope, certificates are issued for CNs(Common Name), also known as FQDNs (Fully qualified domain names). Something such as *.google.com, not IP addresses.
If they were issued for IP addresses they would have to reissue the certificate every time they spun up a new server. Also it's why if you spin up another server and make DNS point google.com to that server, it would not pass verification since the certificate you will be using on that server is not issued to *.google.com, but rather some other domain you own. The IP address plays no role in certificates.
Nit: a CN (stored in the Subject field of a cert) is not an FQDN, though historically web browsers treated them as such. This practice is now deprecated. Modern practice is for the domain name(s) to be placed in the Subject Alternative Name (SAN) field.
The Subject field is not consulted so long as the SAN field is present, and can in theory be any X.500 Distinguished Name, of which Common Name is one possible attribute, which may be any freeform string of a limited length (though it is typically set to the primary domain the cert is issued for, for easy identification).
Certificates can be issued to IP addresses (at least on SAN level, not sure if they are allowed in CN in CA/B baseline requirements), like https://crt.sh/?id=15492507462
If they were issued for IP addresses they would have to reissue the certificate every time they spun up a new server. Also it's why if you spin up another server and make DNS point google.com to that server, it would not pass verification since the certificate you will be using on that server is not issued to *.google.com, but rather some other domain you own. The IP address plays no role in certificates.