The difference is that
tls_aes_128_gcm_sha256 is TLS 1.3 and
tls_ecdhe_rsa_with_aes_128_gcm_sha256 is used for the older TLS 1.2. The first cipher suite doesn't specify the key agreement algorithm and the authentication mechanism. Those are likely used, but they are specified / configured elsewhere in the TLS handshake.
TLS 1.3 is basically TLS-done-right; the two protocols aren't compatible, even if the last part of the cipher suite matches. It can however use the same key agreement and authentication mechanisms (and thus the same server certificate and key).
To quote OpenSSL:
SSL_CTX_set_ciphersuites() is used to configure the available TLSv1.3 cipher suites for ctx. This is a simple colon (":") separated list of TLSv1.3 cipher suite names in order of preference. Valid TLSv1.3 cipher suite names are:
OK, so we're talking TLS 1.3 here, let's look there:
Although TLS 1.3 uses the same cipher suite space as previous
versions of TLS, TLS 1.3 cipher suites are defined differently, only
specifying the symmetric ciphers, and cannot be used for TLS 1.2.
Similarly, cipher suites for TLS 1.2 and lower cannot be used with
So we have two cipher suites that are largely identical to the message encryption / authentication used. However, one is for TLS 1.2 and also specifies the key agreement and the other is specific to TLS 1.3 and only specifies the message encryption / authentication.
For TLS 1.3 the reason why the other components are not specified is that they are negotiated during the handshake. This makes TLS 1.3 more flexible as it doesn't seem to specify all possible combinations in the cipher suite. However, you should remind yourself that the cipher suite is far from the only configuration parameter.
From TLS 1.3, section 4.1.1, Cryptographic Negotiation:
In TLS, the cryptographic negotiation proceeds by the client offering
the following four sets of options in its
A list of cipher suites which indicates the AEAD algorithm/HKDF
hash pairs which the client supports.
A "supported_groups" (Section 4.2.7) extension which indicates the
(EC)DHE groups which the client supports and a "key_share"
(Section 4.2.8) extension which contains (EC)DHE shares for some
or all of these groups.
A "signature_algorithms" (Section 4.2.3) extension which indicates
the signature algorithms which the client can accept. A
"signature_algorithms_cert" extension (Section 4.2.3) may also be
added to indicate certificate-specific signature algorithms.
so basically the ECDHE option is now in
supported_groups (DH is required for TLS 1.3) and RSA is in
signature_algorithms, if present.
Short explanation of the components in the cipher suite:
tls : the protocol;
ecdhe : ephemeral-ephemeral elliptic curve diffie hellman for key agreement, which brings forward security;
rsa : signature algorithm when certificate authentication is used (for the server);
aes-128-gcm : block cipher & cipher mode to keep the messages confidential & authenticated;
sha256 : hash algorithm used for the PRF (used for key derivation).
Note that TLS 1.3 uses HKDF instead of a proprietary HMAC based mechanism in TLS 1.2 for the PRF. So although the TLS 1.2 and 1.3 cipher suites you mention may use the same primitives, the protocols differ somewhat (as explained in the initial section of this answer).