Table of Contents
- IAM can run on instances of any size with any resources. While the system
requirements vary significantly depending on the use-case, generally speaking,
we recommend to start big and then gradually reduce the instances to the
appropriate number and size.
- When allocating resources to an IAM cluster, slightly over-provision the
cluster to make room for request spikes.
- Regardless of the datastore being adopted with IAM, the IAM nodes themselves
need to join in a cluster. The IAM nodes will talk to each other via their
connections to the database. Please refer to the
clustering reference for more details.
Production System Requirements
- For IAM, prefer CPU optimized instances. We recommend at least 4 CPU cores,
16GB of RAM and 24GB of disk space. IAM performs better on a system with
multiple cores. In an AWS environment, we recommend running c4.2xlarge instances
in production that guarantee enough cores (8) and memory (16GB).
- For the database, prefer memory optimized instances. Assume more
intensive workload on the datastore if you are using the rate-limiting or
response rate-limiting plugins with a “cluster” policy. Use this only if Redis
is not an option. High ulimit value, possibly >=65535. A higher limit value
will allow IAM and the datastores to process more incoming requests.
- Instances with multiple cores are required. IAM, by leveraging the underlying
Nginx runtime, will start a worker process for each core. On systems with
multiple cores a worker crash will not badly affect the system since the other
workers can process the ongoing HTTP requests until the crashed worker is being
automatically replaced with a new one.
- At least 2 nodes/instances of IAM, behind a load balancer (Nginx, HAProxy,
AWS ELB or similar). This prevents downtime if an IAM node crashes, since the
other nodes can process the incoming HTTP requests. The number of instances
behind the load balancer should increase with the number of incoming requests,
to avoid the scenario when after a node crashes the sudden increase of load to
the remaining nodes will effectively DDoS them and make the other nodes crash
- IAM is stateless and more nodes can be added behind the load balancer to
scale the system. Incoming HTTP/s requests can be processed by any server, and
that also includes the IAM's Admin API.
- Every new IAM node should target the same datastore, and join the existing
IAM nodes in a cluster. Failure to join the IAM nodes in an IAM cluster will
result in data inconsistencies and errors when processing requests. IAM
automates joining a node in the cluster as long as the right configuration
settings have been provided. For more information, we recommend reading the
The performance of IAM varies depending on multiple factors, including:
- Network latency from the client to IAM, and from IAM to the final upstream
servers, greatly affects the performance. The faster the network, the better
IAM will perform in pretty much every aspect, including system resources.
- Number of incoming HTTP requests and the size of requests and responses that
have to be processed.
- Response time from the upstream server. The fastest the upstream servers can
process a request, the faster IAM can process the response back to the client
and free up resources to handle more incoming requests.
- The number of plugins that are being executed. The more plugins, the more
processing time IAM will require when proxying requests.
Network & Firewall
In this section, you will find a summary about the recommended network and
firewall settings for IAM.
These are the port settings in order for IAM to work:
For IAM Manager:
For the Dev Portal:
Note: since IAM CE 0.13.0—and EE 0.32—listen directives have a new
format, described here, where instead of
specifying SSL and non-SSL ports in different configuration directives—e.g.,
admin_listen_ssl—only one is required: for example, the
listen directive for the Admin API for SSL and non-SSL ports now looks like:
0.0.0.0:8001, 0.0.0.0:8444 ssl
Other listen directives comply to the new format.
Below are the recommended firewall settings:
- The upstream APIs behind IAM will be available on proxy_listen.
Configure listeners accordingly to the access level you wish to grant to the
- Protect admin_listen, and only allow trusted sources that can access
the Admin API.
- IAM assumes a flat network topology in Multi-DC setups. If you have a
Multi-DC setup, IAM nodes between the datacenters should communicate over a
- IAM will try to auto-detect the node's first, non-loopback, IPv4 address and
advertise this address to other IAM nodes. Sometimes this is not enough and the
IP address needs to be manually set, you can do that by changing the advertise
property in the cluster configuration.