Set up your AWS environment before deploying an elastic runtime environment.
To set up the AWS environment, complete the following tasks:
1Create AWS resources. Create and configure AWS resources that the elastic runtime environment can use to start a Secure Agent and run jobs.
2Create a cluster installer policy. Create an IAM policy for the cluster installer role. This policy contains the permissions that allow the cluster to interact with an elastic runtime environment.
3Create a cluster installer role. Create an IAM role for the cluster installer.
4Create a worker node policy. Create an IAM policy for the worker node. The worker node policy contains the permissions that allow worker nodes to operate within an elastic runtime environment.
5Create a worker node role. Create an IAM role for the worker node.
6Create instance profiles. Create instance profiles that pass information about the cluster installer role and the worker role to the EC2 instances in the Kubernetes cluster.
7Create the jump host. Launch an EC2 instance for the jump host. The jump host is an EC2 instance in the public subnet that you use to SSH into nodes in the elastic runtime environment in the private subnet.
The elastic runtime environment must run in a private subnet and remote access requires a jump host.
8Create the master node. Launch an EC2 instance for the master node.
9Attach the cluster installer role to the master node. After creating the cluster installer role, attach it to the master node to make it available to the EC2 instance.
Step 1. Create AWS resources
Create and configure AWS resources that the elastic runtime environment can use to start a Secure Agent and run jobs.
Create and configure the following AWS resources:
VPC
A VPC contains all your AWS resources, including the Kubernetes cluster that hosts the Secure Agent.
Create a VPC in your AWS account. Use IPv4 CIDR manual input and enter the CIDR block for the VPC to use.
Public subnet
A public subnet provides internet access through a NAT gateway. Use the following guidelines to create the public subnet:
- Use any availability zone in the region where you created the VPC.
- For the IPv4 VPC CIDR block, use the same IPv4 CIDR block that you specified when you created the VPC.
- For the IPv4 subnet CIDR block, the CIDR range must be within the VPC CIDR range. Choose a range based on the number of IP addresses that you want to have within the subnet. For example, if you use 10.1.0.0/16 for the VPC, you might use 10.1.0.0/20 for the public subnet.
Private subnet
A private subnet hosts IDMC servers and resources. Use the following guidelines to create the private subnet:
- Use the same availability zone that you used to create the public subnet.
- For the IPv4 VPC CIDR block, use the same IPv4 CIDR block that you specified when you created the VPC.
- For the IPv4 subnet CIDR block, the CIDR range must be within the VPC CIDR range. Choose a range based on the number of IP addresses that you want to have within the subnet. For example, if you use 10.1.0.0/16 for the VPC, you might use 10.1.240.0/20 for the private subnet.
- Add the tag NAME=<private subnet name>, such as NAME=ert_private_subnet. The tag name is case-sensitive.
Note: The NAME tag that Informatica uses to identify AWS resources is separate from the Name tag that AWS uses to name resources. A resource can have both the NAME and Name tags.
NAT gateway
A NAT gateway allows outbound traffic to the internet from nodes in the private subnet. The NAT gateway ensures that private nodes are isolated from the public internet.
Use the following guidelines to create the NAT gateway:
- Use the public subnet as the subnet.
- For the connectivity type, select Public.
- Allocate an elastic IP address to the NAT gateway.
Internet gateway
An internet gateway is used for internet access. The public subnet and the internet gateway allow the jump host to receive SSH connections from the public internet.
Create an internet gateway in AWS and then attach it to the VPC.
A public route table routes traffic in the public subnet. Create a public route table using the following guidelines:
- Use the VPC that you created.
- Add a route using 0.0.0.0/0 as the destination and the internet gateway that you created.
- Edit the subnet association and select the public subnet that you created.
Private route table
A private route table routes traffic in the private subnet. Create a private route table using the following guidelines:
- Use the VPC that you created.
- Add a route using 0.0.0.0/0 as the destination and the NAT gateway that you created.
- Edit the subnet association and select the private subnet that you created.
Security group
A security group allows SSH access to the elastic runtime environment. Use the following guidelines for the security group:
- Use an existing security group or create a new one.
- Ensure the VPC uses the VPC that you created.
- Include inbound rules that allow:
▪ All traffic to the local machine that you're using to create AWS resources
▪ All traffic originating from the same security group
- Add the tag NAME=<security group name>, such as NAME=ert_sg. The tag name is case-sensitive.
Note: The NAME tag that Informatica uses to identify AWS resources is separate from the Name tag that AWS uses to name resources. A resource can have both the NAME and Name tags.
Note: You need to add the name of the security group to the config.txt file that you will configure when you deploy the elastic runtime environment.
If you don’t specify a security group, the cluster installer will attempt to create one for you and populate it with the necessary inbound rules. If permissions prevent this, the installer will stop and you must create the security group.
Step 2. Create a cluster installer policy
Create an IAM policy for the cluster installer role and give it a name such as cluster_installer_policy. The cluster installer policy contains the permissions that allow the cluster to interact with an elastic runtime environment.
To create a cluster installer policy, perform the following steps:
1Ensure that you have the following information ready:
Observe security best practices and use the least privileges principle wherever possible. For example, the JSON template shows "Resource": "*" for the IAM policy. However use "*" only where absolutely required. Consider restricting by region or resource.
For more information about IAM policies, refer to the AWS documentation.
Description of the policy permissions
The following descriptions explain each block in the Permissions_cluster_installer_policy.json file:
Allows full management of Auto Scaling Groups (ASGs). Full management includes creating, updating, deleting ASGs, attaching load balancers to ASGs, terminating instances within ASGs, and viewing their statuses and tags. This is critical for dynamic scaling of compute resources.
Provides read-only access to describe all EC2 resources. Read-only access allows the user/product to query information about existing EC2 instances, volumes, snapshots, etc., necessary for monitoring and decision-making but not modifying resources.
Grants permission to launch new EC2 instances (RunInstances) using specified resources like security groups, network interfaces, launch templates, snapshots, key pairs, and subnets. This permission supports creating new virtual machines under controlled conditions.
Allows creation of various EC2-related resources such as key pairs (for accessing instances), tags, route tables, snapshots, network interfaces, launch templates, security groups, internet gateways, subnets, volumes, and AMIs (images). Enables full setup and customization of network and compute environments.
This broad permission set enables management of live EC2 resources including modifying security group rules, route tables, VPC attributes, starting/stopping/terminating instances, importing key pairs and snapshots, managing launch templates, deleting various EC2 resources, associating IAM roles with instances, and more. It covers lifecycle and infrastructure adjustments.
Allows tagging of various EC2 resources created explicitly during the listed actions, like creating volumes, instances, security groups, launch templates, subnets, auto-scaling groups, etc. Tagging helps with resource identification, billing, and management.
Grants permission to create security groups specifically within the Virtual Private Clouds (VPCs) owned by the account. Security groups control inbound and outbound traffic to instances.
Permits creation of security groups and tagging for specific resource types including security groups, network interfaces, launch templates, Elastic IPs, and snapshots. Useful for managing and organizing network and instance-related resources.
Allows management of subnets and route tables within a specific VPC (denoted by {{VPC_ID}}), including creating, associating CIDR blocks, deleting subnets, and tagging. Ensures control over network segmentation.
Grants permission to create mount targets and describe existing Amazon Elastic File System (EFS) resources. This supports attaching file systems to EC2 instances for shared storage access and inspecting filesystem details.
Allows passing specific IAM roles to AWS services such as EC2 or EKS so they can assume these roles for permissions during operations like cluster or worker node functions. Essential for role delegation.
Full permissions for managing Elastic Load Balancing (ELB) including target groups, listeners for application and network load balancers, listener rules, and load balancers themselves. Enables setup, configuration, and maintenance of load balancing services.
Grants full access to AWS Secrets Manager secrets in the specified account. This includes creating, reading, updating, and deleting secrets used for securely storing credentials or sensitive information.
Allows creation of service-linked roles for AWS services. These roles enable AWS services to perform actions on your behalf, necessary for certain automated service functionalities.
Allows you to view details of all Elastic Load Balancers and check the health status of instances registered to those load balancers. It grants read-only access to describe load balancers and their instance health across the entire AWS account, without permission to modify or manage any resources.
Step 3. Create a cluster installer role
In AWS, create an IAM role for the cluster installer and give it a name such as cluster_installer_role.
Perform the following steps in the AWS Management Console:
1Access Roles and click Create Role.
2In the Create Role Wizard, select AWS service for Trusted entity type and EC2 for Use case.
3Locate the cluster installer role policy that you just created and select your policy,
The cluster installer policy name can't contain spaces.
5Click Create Role.
AWS automatically creates an instance profile with the same name as the role.
For more informamtion about IAM roles, refer to the AWS documentation. You can also create IAM roles using the AWS CLI.
Step 4. Create a worker node policy
Create an IAM policy for the worker node role and give it a name such as worker_node_policy. The worker node policy contains the permissions that allow worker nodes to operate within an elastic runtime environment.
To create a worker node policy, perform the following steps:
Grants read-only access for discovering and inspecting AWS infrastructure related to file systems, EC2 instances, availability zones, and Auto Scaling.
Permits reading sensitive configuration secrets from AWS Secrets Manager.
Step 5. Create a worker node role
In AWS, create an IAM role for the worker node and give it a name such as worker_node_role.
The worker node role provides AWS permissions required for the node to interact with core AWS services such as EC2, Auto Scaling, EFS, and Secrets Manager.
Perform the following steps in the AWS Management Console:
1Access Roles and click Create Role.
2In the Create Role Wizard, select AWS service for Trusted entity type and EC2 for Use case.
3Locate the worker node policy that you just created and select your policy.
Tip: Note the name of your worker node role. You'll need to enter this value into the Worker Instance Profile field of your elastic runtime environment environment configuration. For more information, see Environment configuration.
The worker node policy name can't contain spaces.
5Click Create Role.
AWS automatically creates an instance profile with the same name as the role.
For more informamtion about IAM roles, refer to the AWS documentation. You can also create IAM roles using the AWS CLI.
Step 6. Create instance profiles (if necessary)
Instance profiles pass information about the cluster installer role and the worker role to the EC2 instances in the elastic runtime environment.
Use the following table to determine whether you need to create instance profiles:
How did you create the role?
Action
AWS Management Console
No further action required.
AWS automatically creates an instance profile with the same name as the role and attaches the role to it.
AWS CLI
Manually create the instance profile.
Using API calls
Manually create the instance profile.
Tip: To verify that an instance profile exists, use the Roles page in the AWS Management Console and look up the role.
Manually creating an instance profile
To manually create the instance profiles, either run the AWS CLI on the jump host or open the AWS Shell from the AWS Management console.
Create the following instance profiles by running the appropriate commands:
Instance profile for the cluster installer role
To create an instance profile for the cluster installer role, run the following command:
aws iam create-instance-profile --instance-profile-name <cluster installer instance profile name>
To attach the cluster installer role to the instance profile, run the following command:
aws iam add-role-to-instance-profile --instance-profile-name <cluster installer instance profile name> --role-name <cluster installer role name>
Note: Replace the placeholder <cluster installer instance profile name> with the name that you want to use for the cluster installer instance profile. Replace the placeholder <cluster installer role name> with the name of the cluster installer role that you created.
Instance profile for the worker role
To create an instance profile for the worker role, run the following command:
aws iam create-instance-profile --instance-profile-name <worker instance profile name>
To attach the worker role to the instance profile, run the following command:
aws iam add-role-to-instance-profile --instance-profile-name <worker instance profile name> --role-name <worker role name>
Note: Replace the placeholder <worker instance profile name> with the name that you want to use for the worker role instance profile. Replace the placeholder <worker role name> with the name of the worker role that you created.
You need to use the name of the worker instance profile in the config.txt file that you configure when you deploy the elastic runtime environment.
To verify that the instance profiles were created, open the cluster installer role and the worker role in the AWS Management Console and review the instance profile ARN.
Step 7. Create the jump host
Launch an EC2 instance for the jump host.
The jump host is an EC2 instance in the public subnet that you use to SSH into nodes in the elastic runtime environment in the private subnet. Because the elastic runtime environment is designed to run in a private subnet, a jump host is required to remotely access the environment.
Create a jump host using the launch instance wizard in AWS. Use the following guidelines:
•Use Amazon Linux as the OS image.
•Use instance type t3.small.
•Create a new key pair.
•Use the VPC that you created.
•For the subnet, select the public subnet that you created.
•Enable Auto-assign public IP.
•Use the option to create a new security group for the jump host with an inbound rule that allows SSH traffic on port 22 from source <local machine IP address>/32. The inbound rule allows you to access the jump host from your local machine.
Then, launch the instance.
Using a jump host is a best practice for secure and scalable infrastructure so that the elastic runtime environment isn't exposed to the internet. The jump host greatly reduces the attack surface and prevents unauthorized access to the elastic runtime environment, and access is controlled using SSH authentication and security group rules. If the jump host is compromised, nodes in the elastic runtime environment are protected by a firewall and security groups.
Step 8. Create the master node
Launch an EC2 instance for the master node.
Create the master node using the launch instance wizard in AWS. Use the following guidelines:
•Create the master node by launching an instance using the public Informatica AMI infa-elastic-master-node-2025-07-M.
•Use an instance type with at least 2 CPUs and 4 GB of memory.
•Use the key pair that you created when you launched the jump host.
•In the network settings, use the VPC that you created.
•Use the private subnet that you created as the subnet (subnet must reside in a NAT Gateway).
•Disable Auto-assign public IP.
•Use the option to use an existing security group and select the security group that you created.
•For the IAM instance profile, use the instance profile for the cluster installer role.