EAP-TLS authentication can take the "subject" or "identity" being authenticated, either from the Subject CN, or the Subject Alternative Name. Contrary to https connections, the SAN is not mandatory or as important here. ISE will expect a non-empty Subject CN. And the ISE Certificate Authentication Profile is the place where you define WHERE the identity should come from. For EAP-TLS to work, you must understand what your client certs look like - if the Subject CN contains a username/machine_name or whatever, that identifies the endpoint, then use the Subject CN - but it must be consistent across all clients.
And since Policy Set programming is the same for all PSNs, this logic will be applied to your on-prem PSNs, and your cloud PSNs.
As for the EAP System Certificate for each PSN, that should also be consistent - you don't need to purchase a separate Digicert cert for each PSN - you get one, and re-use that for all your PSNs (you can export a cert and its private key, and import that into all your PSN's that need an EAP System Cert)
In ISE Trusted Cert section, ensure that the entire CA cert chain that is involved in the ISE EAP System Cert (Digi Cert CA?) has these options set
The only other thing I can think of regarding cloud based PSN vs on-prem PSN is that the IP MTU might play a factor. With EAP-TLS, the RADIUS datagrams will mostly always exceed 1500 bytes during TLS negotiation, because the TLS client hello and server hello will contain the entire cert chain. ISE uses MTU 1500 bytes. If the PSN is connected to an L3 network that uses Jumbo frames then it will cause issue - not sure about AWS, but keep this in mind. Run a tcpdump on the cloud PSN and observe the RADIUS packets during a TLS negotiation. it's normal and expected to see UDP fragmentation to occur. Some firewall in the past have also struggled with UDP fragmentation and re-assembly.
