You can easily do this by implementing the logic in the client - nothing native in Aerospike that you can just turn on this behavior.
Option 1 - You will create two namespaces, one on disk with the desired longer TTL, other in RAM with the desired shorter TTL. You will first read in RAM, if record not found, read from disk, and then also write it back to RAM. (Here, you will have to also consider if there can possibly be any consistency issues because each read or write in Aerospike is atomic. Multi-client situation, data updated on disk by another client after one client read it.) If you are able to read successfully from RAM, touch the record to update its TTL. Read and touch operation can be combined in the same transaction. If the data is single bin integer or float, further optimization is possible.
Option 2 - It is also possible to store the same record data both in disk and RAM simultaneously - on disk for persistence, in RAM for faster performance. Con - your entire data set now resides both in disk and RAM. But you can achieve this in a single namespace. The TTL will be same for both stores then. To update TTL on read, you have to essentially do a write (touch), but both can be done in the same transaction.