There is always delay between the time user A presses a key, and the time that user B on another computer will see that action.
This is because of both processing time on systems, as well as transmission time over the internet.
Newcomers to networking will try to reduce the latency by, for example, sending commands as soon as they are detected rather than as part of the regular game update loop cycle, or by trying to establish peer-to-peer connections to cut out the server in multi-player games.
In the end, such attempts end up making the code more fragile, and doesn't actually solve the problem, because there is an unavoidable delay between users -- the travel time of electric signals in copper between New York and California is significant, even before you add the additional processing overhead of the network infrastructure!

Thus, the art of creating a networked game is to design the game to work well within the limitations.
There are several different ways of doing this. Real-time strategy games will, for example, play a "yes, sir!" acknowledgement animation on the sending client, giving the command packet time to travel to the server and to other players.
Many MMO RPGs and some FPS-es will just accept the latency, and tune the game for a given latency target (200 ms is reasonable here.)
Other games will attempt to forward-predict the location/actions of remote player son the local target, and then somehow "fix up" when they receive information that is counter to the prediction. Some players like this; personally I don't particularly do so, because remote players will be snapping/warping/jumping around in an uneven manner.

The FAQ for the networking and multiplayer forum contains some links to good references on different models. The Source Networking Model document, the Zen of Networked Character Physics document, and the 1,500 Archers on a 28,800 Modem document are good starting points.

- peer to peer is slower than client/server?

No. If you can make a peer-to-peer connection, it will likely be slightly (but not a lot) faster than client/server for a message that would go user->server->other user. Some people assume it will be 50% faster, but that's seldom the actual case.
However, peer-to-peer come with a number of really hard problems, including NAT punch-through, cheating, and privacy concerns. It is common that beginners underestimate these problems, and overestimate the potential gains.

- how much it increases the delay using cloud backend (appwarp) instead of normal connection?

What is a "normal" connection? The IP, UDP, TCP, and HTTP protocols don't know whether they are going to a "cloud" location or a "normal" location.
If you are not seeing the performance you expect, you should draw out the different parts of the equation that can affect the performance, and attempt to measure each of them separately. That will give you a good understanding of the problem.

I don't know about appwarp at all -- their technical support should be able to answer performance SLA questions.
All we've seen is that you suggest there is a 80-120 millisecond "latency" when using their platform. However, that doesn't help us answer the question at all.
Latency between what and what? Where is their server? Where are you? Where is the other party? What protocol are you/they using? What are the alternatives you could consider?