The development and administration tools work well, including a consistent API and adequate management console. In terms of business process, it provided an effective "escape valve" for new product development that would have been much more onerous to deploy if we had to provision physical hardware and arrange for associated IT resources.
AWS has a record of occasional severe outages, which has a cascading effect on the large number of high-profile services that now run on its infrastructure. Despite the spectacular nature of these outages, it is unlikely that a self-managed data center would achieve significantly better uptime.
It is also the case that AWS outages can be mitigated with effective use of multiple deployment 'zones' and regions. This is something that any mission-critical application should be doing anyway as part of disaster recovery preparations.
I would gladly rely on AWS for any large-scale application deployment. For prototyping and small-scale applications, a more heavily managed environment on top of the 'bare metal' virtual infrastructure, such as Heroku or Elastic Bean Stalk, is probably a more productive approach in most cases.
It was relatively easy for a developer to learn how to use it for simple scenarios. Setting up more complex virtual infrastructure with multiple tiers, redundancy and failover is more of a challenge to to take on from scratch, but a number of companies offer support in the form of deployment templates and additional services.
AWS does not provide the raw performance that you can get by building your own custom infrastructure. However, it is often the case that the benefits of specialized, high-performance hardware do not necessarily outweigh the significant extra cost and risk. Performance as perceived by the user is very different from raw throughput.