During TLS negotiation (at least in 1.2 and below, I'm not sure how 1.3 changes things), the client and server agree a "ciphersuite". Basically the client sends a list of ciphersuites in order of preference and the server picks one, the server is supposed to respect the client's preferences but not all do. The server must pick a ciphersuite that is compatible with a certificate it has (servers can have multiple certificates for different ciphersuites).
Ciphersuites can be divided into "traditional" and "emphemeral". In a traditional ciphersuite the server's long-term secret is used directly in the process of establishing the shared secret. For example in a traditional RSA ciphersuite the client generates the shared secret and encrypts it with the public key from the certificate. The server then decrypts the shared secret using the corresponding private key. In a non-ephemeral DH ciphersuite (rarely if ever used) the certificate would contain a diffie-hellman public key which the client would use in the diffie-hellman process to agree the shared secret.
In ephemeral ciphersuites the shared secret is agreed using "ephemeral" keys and the long term key from the certificate is used to sign the key exchange. This means that if the servers long term key is compromised it cannot be used to decrypt passively sniffed connections, only to perform MITM attacks. It would in-principle be possible to design a cipersuite based on ephemeral RSA keys but this is not done because RSA keys are relatively expensive to generate.
RSA keys can be used for both encryption and signing, so a RSA certificate can be used with both traditional (TLS_RSA_*) and ephemeral (TLS_DHE_RSA_* and TLS_ECDHE_RSA_*) ciphersuites.
ECDSA keys on the other hand can only bs used for signing and thus ECDSA certs can only be used with ephemeral ciphersuites (TLS_ECDHE_ECDSA_*).