3 additional varchar(32) keys and also updating them -- too bad for performance?
Maintaining those indexes will have a cost.  It is not possible to say if that cost is "too bad" or if it is significant to you.  The cost will depend on your RAM and memory settings, on your data size, and on your storage system.  Do some benchmarking on your own system (or a clone of it) and see.  

If 100,000 rows are arriving evenly throughout the day, any reasonably sized server should be able to cope with this load.  You might not want to use a AWS t2.nano.  But you didn't say how many rows are updated per day, but "not too often" doesn't seem hard to deal with.

Assuming all index pages other than the leaf pages are already cached, then an update of one random unique token to another random unique token would need to read one index leaf page (for the old value), read and dirty one table page, read and dirty one index leaf page (for the new value), and possibly read and dirty a 2nd table page if the new record can't fit on the same page as the old one, or if there is an index entry for the new value already and it needs to verify that entry is not "live" in violation of the unique constraint.  The WAL records covering all of this will need to be written (most likely fitting into one write request) and flushed.  This shouldn't take more than 100ms in the typical case if you have 5400 RPM hard disk, substantially less if many of those random reads are satisfied by the caches.  In the worst case could be a lot longer if someone else is syncing large amounts of data to disk at the same time and you get contention on that.