Of course, in the "long term" (whatever that means), the market and shareholders expect to reap vast profits, and price that, along with the company's free cash flows, into the stock.
However, my personal thesis is that Amazon specifically is a bit of an anomaly in this regard: it seems unlikely to me that we will see any strategic shift in pricing from basically any Amazon-owned entity in our lifetimes -- the culture is too ingrained towards a strategy of complete and utter dominance over all markets, margin reduction being a key tool in the toolbox. So if I were to bet I would say pricing power is pretty low on the list of concerns of AWS lock in -- more concerning are things like unexpected conflicts of interest as Amazon eats the world (see also: Netflix), operational dependency (ultimately, you rely upon AWS ops' competency for your uptime, security, etc), end-of-lifing of services you depend on, opportunity cost vs other vendors who may offer better services, and other unknown unknowns.
That said, Amazon Prime prices just went up 20%, so Amazon will clearly raise prices if they think the market will bear it.
Moreover, "complete and utter dominance" sounds like a monopoly. It's difficult to think of a monopoly that didn't raise prices and/or decrease service once they were established. I would not start a business on Amazon without assessing the risk of tying my fate to a single large vendor, for cost as well as other reasons you cited like Amazon deciding to compete with you.
That's a bad example. Redshift is "wire compatible" with Postgres. You use the same drivers. There are a few popular extensions they added to Sql to copy files directly from and to S3 but that's about it.
Assuming you seek wire compatibility, your choice would therefore be a PostgreSQL-compliant DW, of which there are several. However, they have greatly differing cost and operational profiles, which make switching non-trivial. They also tend to support different versions of PG depending on when they forked from PostgreSQL.
I'm not saying it is a good idea to leave Redshift in some distant future where you might save a few pennies. Heck, I hardly ever say it's a good idea to rearchitect a core part of your infrastructure without having a very good reason -- saving a few dollars isn't one. But from the software side, you aren't stuck with Redshift and you aren't embedding a lot of proprietary AWS specific drivers in your code base.
Take your Redshift example. It's an outstanding service but once you build apps around it and load a bunch of data the switching costs become very high. AWS can raise the price quite a bit before it makes economic sense for working apps to move off it.
Consequently a key question to ask is when do my favorite AWS services become cash cows? At that point your economics will change substantially. You may be living day-to-day in your business but the stock market thinks Amazon will extract large profits out of AWS in spite of growing competition. Food for thought...