Randomly slow inserts with InnoDB
I would suggest that you are 12ms away (latency) from the AWS datacenter.  You are stuck with that overhead.  Conclusion:  Beware of the timings.
The "&lt;1ms" is realistic only if client and server are in the same datacenter and the disk is SSD.  What is "magnetic storage"?  Perhaps that is an old, spinning, disk.  In that case 10ms is a reasonable guess for one write.  And it is hard to determine from the available numbers what the latency really is.  (Presumably less than 12ms.)  Conclusion:  Be sure to use SSDs.
What does Amazon say about interference from other instances on the same hardware?  You have a "small" instance; there are probably many others sharing the same I/O.  If one of them has a spike, you might be slowed down.  With "large", you might have fewer competing customers.  And it might be SSD.  Conclusion:  Focus on average or 95th percentile, not spikes.
innodb_flush_log_at_trx_commit=1 requires at least 1 disk write per transaction.  =0 delays and combines writes, hence the noticeable speedup.  One way to soften it is to batch multiple queries into a single BEGIN...COMMIT.  (Only do such where the logic makes sense.)  Conclusion:  Bigger transactions.  (However, you will still be stuck with 12+ms per transaction instead of per insert.)
Updates to indexes (except for UNIQUE indexes) are delayed and can usually be treated as zero impact.
char(21) COLLATE utf8_unicode_ci -- Is it always 21 characters?  If not, use VARCHAR.  Perhaps it is always ascii, not utf8?  If so, use CHARACTER SET ascii.
PRIMARY KEY (seqid),  UNIQUE KEYid(id) -- Why have both?  As already mentioned, it causes overhead included in the INSERT time, namely to verify uniqueness before committing.
The activity seems to be very low.  Normally people ask questions like yours when they are having trouble with hundreds or thousands of queries per second.
Here's a way to get a 16-byte, chronologically ordered, UUID:  http://mysql.rjweb.org/doc.php/uuid .  (But not as easily displayed.)