Set up your AWS environment to create and configure the required AWS resources before deploying an elastic runtime environment.
To set up the AWS environment, complete the following tasks:
1Create and configure AWS resources that the elastic runtime environment can use to start a Secure Agent and to run jobs.
2Create a cluster installer policy that contains the permissions that allow the cluster to interact with an elastic runtime environment.
3Create an IAM role for the cluster installer that allows the cluster installer to deploy an elastic runtime environment.
4Create a worker policy that contains the permissions that allow worker nodes to process data in an elastic runtime environment.
5Create an IAM role for the worker nodes that allows the worker nodes to process data in the elastic runtime environment.
6Optionally, launch an EC2 instance for the jump host to remotely access the elastic runtime environment. If you can access the private subnet through your enterprise network, you don't need to create a jump host.
7Launch an EC2 instance for the master node.
The following image shows how the AWS environment appears with a deployed elastic runtime environment:
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. To create the public subnet, use the following guidelines:
- Use any availability zone in the region where you created the VPC.
- To set the IPv4 VPC CIDR block, use the same IPv4 CIDR block that you specified when you created the VPC.
- To set the IPv4 subnet CIDR block, use a CIDR range that's 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. To create the private subnet, use the following guidelines:
- Use the same availability zone that you used to create the public subnet.
- To set the IPv4 VPC CIDR block, use the same IPv4 CIDR block that you specified when you created the VPC.
- To set the IPv4 subnet CIDR block, use a CIDR range that's within the VPC CIDR range. 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.
Choose a range that has enough available IP addresses to accommodate the maximum number of worker nodes in the elastic runtime environment. For example, if the environment has a minimum of one worker node and a maximum of 10 worker nodes, then at least 10 IP addresses must be available in the private subnet to accommodate the worker nodes.
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.
To create the NAT gateway, use the following guidelines:
- Use the public subnet as the subnet.
- Set the connectivity type to 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. To create the public route table, use 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. To create the private route table, use 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 for the elastic runtime environment
A security group allows SSH access to the elastic runtime environment. You specify this security group in the config.txt file. For more information about the config.txt file, see Deploy an elastic runtime environment.
To create the security group, use the following guidelines:
- Use an existing security group or create a new one.
- Use the VPC that you created.
- Add inbound rules that allow the following types of traffic:
▪ All traffic from the same security group
▪ All traffic from the local machine that you're using to create AWS resources
The following image shows an example of the inbound rules:
If any required inbound rules are missing, the cluster installer populates them.
Security group for the jump host (optional)
The jump host is an EC2 instance in the public subnet that you can use to SSH into nodes in the elastic runtime environment in the private subnet. A security group allows SSH access to the jump host from your local machine. If you can access the private subnet through your enterprise network, you don't need to create a jump host or a security group for the jump host.
To create a security group for the jump host, use the following guidelines:
- Use the VPC that you created.
- Add an inbound rule that allows SSH traffic on port 22 from source <local machine IP address>/32.
EFS file systems for system storage (required) and data storage (optional)
An elastic runtime environment uses EFS file systems for system storage and data storage. System storage is required for Secure Agent operations, and data storage is used to store flat files that you used as data sources in tasks, such as mapping tasks.
Create an EFS file system for system storage and then create an access point for it. Optionally, you can create another EFS file system for data storage and create an access point for it as well.
To create each file system, use the following guidelines:
- For the VPC, use the VPC that you created.
- For the system disk, don't specify any mount targets, and remove the default mount targets that AWS adds. The cluster installer automatically adds mount targets to the EFS file system.
For the data disk, specify the private subnet as the mount target.
- On the Network access page, customize the file system to set the availability zone to the name of the availability zone that you created and the security group to the name of the security group that you created.
- Create the file system only after you've customized it.
To create each access point, use the following guidelines:
- For the file system, use the file system that you created.
- Enter a root directory, such as /ert_sysdisk or /ert_datadisk.
- For the POSIX user, use the user ID 1200 and group ID 1200.
- In the root directory creation permissions, use owner user ID 1200, owner group ID 1200, and access point permission 0755.
The following image shows an example of an EFS file system in the AWS Management Console:
Step 2. Create a cluster installer policy
Create a cluster installer policy that contains the permissions that allow the cluster to interact with an elastic runtime environment.
To create the cluster installer policy, download the Permissions_cluster_installer_policy.json file from the Elastic runtime environment IAM policy permissions JSON files Knowledge article. Replace the placeholders and use the content to create a policy in AWS.
The following table describes each placeholder:
Placeholder
Description
{{account-id}}
AWS account ID.
{{VPC_ID}}
VPC ID.
{{cluster-installer-role}}
Cluster installer role name, such as cluster_installer_role. The name must follow the AWS naming convention for roles.
Note: You can decide on the role name in this step, and then use the same role name when you create the role. For information about creating the cluster installer role, see Step 3. Create a cluster installer role.
{{worker-node-role}}
Worker role name, such as worker_node_role. The name must follow the AWS naming convention for roles.
Note: You can decide on the role name in this step, and then use the same role name when you create the role. For information about creating the cluster installer role, see Step 5. Create a worker role.
•If AWS doesn't automatically create an instance profile for the role, create the instance profile manually.
Step 6. Create the jump host (optional)
Optionally, launch an EC2 instance for the jump host to remotely access the elastic runtime environment. If you can access the private subnet through your enterprise network, you don't need to create a jump host.
The jump host is an EC2 instance in the public subnet that you can 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 can remotely access the environment.
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.
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 security group that you created for the jump host. For more information, see Step 1. Create AWS resources.
Then, launch the instance.
Step 7. 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.
•Disable Auto-assign public IP.
•Use the security group that you created for the elastic runtime environment. For more information, see Step 1. Create AWS resources.
•To set the IAM instance profile, use the instance profile for the cluster installer role.
