Okay, at Google I found that
IAM abbreviates Amazon's
Identity and Access Management.

So, the OP has
an undefined three letter
acronym.

Suspicions confirmed: The OP
is an example of poor
technical writing.

Why do I care? I could be
interested in Amazon Web Services
(AWS) for my startup. But so far by
a very wide margin what has
been the worst problem in my
startup? And the candidates are:

(1) Getting a clear statement of
the business idea.

(2) Inventing the crucial,
defensible, core technology.

(3) Learning the necessary programming
languages.

(4) Installing software.

(5) System backup and restore.

(6) Making sense out of
documentation about computer
software.

May I have the envelope please
(drum roll)? And the winner is,

(6) Making sense out of
documentation about computer
software.

And the judges have decided that
uniquely in the history of this
competition, this selection deserves
the Grand Prize, never before given
and to be retired on this first
award, for the widest margin of
victory ever.

No joke, guys: The poorly written
documentation,
stupid words for really simple
ideas, has cost me literally
years of my effort. No joke.
Years. No exaggeration. Did
I mention years?

At this point, "I'm reticent.
Yes, I'm reticent." Maybe
Amazon has the greatest stuff
since the discovery and
explanation of the
3 degree K background
radiation, supersonic
flight, atomic power,
the microbe theory of
disease, electric power,
mechanized agriculture,
and sex, but if Amazon
can't do a good job,
and now I insist on a very
good job, documenting their
work, which is to be
yet another layer of documentation
between me and some microprocessors,
then, no, no thanks, no way,
not a chance, not even
zip, zilch, zero.

What might it take me to
cut through bad Amazon
documentation of AWS,
hours, days, weeks,
months, years, then
from time to time,
more hours, days, or weeks,
and then as AWS evolves,
more such time? What would
I need to keep my startup
progress on track,
500 hours a day? More?
All just to cut through
badly written documentation
for simple ideas, and worse
documentation for complicated
ideas?

First test: Any cases of
undefined terms or acronyms?

Result: About three such cases,
and out'a here. Gone. Done.
Kaput. I don't know what AWS
has, but I don't need it.

Sorry, AWS, to get me and my
startup as a user/customer,
you have to up your game
by several notches. The first
thing I will look at is
the quality of the technical
writing in your documentation.
And, I have some benchmarks for
comparison from J. von Neumann,
P. Halmos, I. Herstein, W. Rudin,
L. Breiman, J. Neveu, D. Knuth.

Amazon, for now, with me, from
your example of writing here,
you lose. Don't want it.
Can't use it. Not even for free.
I'm not going to invest my
time and effort trying to
cut through your poor technical
writing. And, the next time
I look at anything from AWS,
the first undefined term
and I'm out'a here again.

Yes, I'm hyper sensitive about
bad technical writing -- couldn't
be more sensitive if my fingers
and arms were burned off. Whenever
possible, I will be avoiding any
chance of encountering bad technical
writing, ever again. Period.
Clear enough?

More generally, my view is that
bad technical writing is the
worst bottleneck for progress
in computing.
Come on, AWS, up your game.

I don't want to run a server
farm and would like you to do
that for me, but neither do I
want to cut through more
bad technical writing -- for that
work, my project is already
years over budget.