You're also referring to a major weakness in the distributed consensus of bitcoin: the longest-chain-preferred mechanism is almost certainly a vector of attack on the chain.
From the perspective of people transacting on Bitcoin's infrastructure I suspect they'd call it "an attack."
You grossly underestimate the hashing capacity of the bitcoin network. The hashing capacity, at time of posting, is approximately 5,000,000,000 Gigahashes/second[1]. Spot measurement of the hashing capacity of an EC2 instance is 0.4 Gigahashes/second[2]. You would need 12 BILLION EC2 instances to 51% attack the bitcoin network.[3] Using EC2 to attack the network is impractical and inefficient.
[1] https://bitcoinwisdom.com/bitcoin/difficulty
[2] https://www.reddit.com/r/Bitcoin/comments/1btgl1/i_was_curio...
[3] x/(5e18+x)=.51 y=x/.4e8
Even most BTC users do not run actual clients anymore but use exchanges or wallet services which bundle huge numbers of users behind few actual Bitcoin network nodes.
I don't need to overcome the network, I need to invite the network to have arguments with itself, by finding a way to introduce widespread partitioning of the network.
In this, the preference to longer hash chains seems like a good idea in a unified clock model but a somewhat optimistic decision in a split clock world.
To do this you would need to have the equivalent hashing power of the network. Peers expect an nominally equivalent amount of Proof of Work for the difficulty adjustment. You would also need to guarantee that the peer connects to _no other_ peers
Your thinking is good adversarial thinking but it's already covered in the protocol.