Unfortunately there is not a single source of truth about attestation. I'll try to make it as clear as possible and cite when necessary.

TL;DR: The Endorsement Key is used to prove that you are talking to a real TPM. However, it cannot be used for signing. The AK can be used for signing and is associated with the EK.

Endorsement Key

You can consider the Endorsement Key (EK) fixed per TPM. Actually, the EK is the primary key of the endorsement hierarchy. As such, it depends on the Endorsement Primary Seed (EPS) which is really fixed for the lifetime of the TPM and a so-called template which e.g. determines if the EK is a RSA or a ECC key.

              EPS (random, can never be changed)
               |
            +-----+
template  ->| KDF |
            +-----+
               |
               V
               EK

Assuming, you use the default template, the EK is unique and not changeable for the TPM. You cannot change it ever. This raises privacy concerns which I will cover later. Also note, that the EK private key will never be disclosed by the TPM.

Additionally, a TPM typically provides an Endorsement Certificate (chain) which is saved on the TPM storage (e.g. ECC EK certificate: NV index 0x01c0000a, see TCG EK Credential Profile). This EK certificate contains the EK public key and is signed by the manufacturer. With that certificate you can verify, that the EK public key is associated with a genuine hardware TPM produced by the manufacturer.

I mentioned earlier, that disclosing the EK public key would violate our privacy (since we can never change it). Therefore, the TPM will not allow us to use the EK for signing. That is the reason why we need an Attestation Key (AK), previously also called Attestation Identity Key (AIK).

Storage Root Key

The Storage Root Key (SRK) is easy. It is the primary key of the owner hierarchy, that is the "father of all (normal) keys". All keys used by the owner of the TPM for signing and encryption are usually associated with the owner hierarchy and thus children (or grandchildren etc.) of the SRK. In fact, being a child of the SRK means internally being encrypted (= wrapped) by the SRK.

Attestation Keys

Now comes the tricky part. The term Attestation Key (AK), previously Attestation Identity Key (AIK) is defined very loosely. Basically any (restricted) signing key can be an AK.

TPM Spec Part 1, 25.3.1

A restricted signing key is occasionally referred to in this specification as an Attesting or Attestation Key.

The purpose of AKs is to sign data (e.g. PCR values) to prove that they originate from a real TPM (without having been tampered with). Remember, we cannot use the EK for signing directly.

There are two types of AKs I know of.

AK with AK Certfificate

First, the AK specified in the TPM Spec Part 1, 9.5.3.1. Basically, there is a trusted third party called Attestation CA with an own root key and a root certificate. The Attestation CA does a) verify the if a TPM is genuine via its EK Certificate and b) issue AK certificates if a TPM is genuine.

Now, different AKs and their corresponding AK Certificates can be used for attestation for different services (e.g. Google, Facebook). The service providers use the Attestation CA root certificate to verify if the TPM is genuine.

An external entity called an "Attestation CA" attests to an asymmetric key pair [AK] in a TPM in order to vouch that a key is protected by an unidentified but genuine TPM and has particular properties. This attestation takes the form of a credential [AK Certificate] that vouches for information including the public key of the key pair.

Usually, this type of AK is associated with the owner hierarchy and thus a child (or grandchild etc.) of the SRK.

I think this tutorial might be helpful.

AK associated with the Endorsement Hierarchy

There is second approach to AKs. As I explained, the EK cannot be used for signing directly. However, it can be used to wrap (= encrypt) other keys. Therefore, you can create a signing key (AK) associated with the endorsement hierarchy.

Again, the service provider needs a mechanism to prove that a TPM is associated with a good EK / EK Certificate. In this case, the AK used is encrypted (= wrapped) by the EK. Only if a TPM can load (= decrypt) the AK under its unique EK and use it to sign data, it is a genuine TPM. In this case, the TPM loses its anonymity since the service provider needs to know its EK.

This approach is briefly described in this talk at LCA 2020 by Matthew Garrett.