Connecting to a VPC in another account

You can give your HealthOmics workflow runs access to resources in an Amazon VPC that belongs to a different AWS account. With AWS Resource Access Manager (AWS RAM) sharing, the VPC owner shares subnets with your account, and HealthOmics places the elastic network interfaces (ENIs) for your runs in those subnets. With VPC peering, the ENIs stay in your own VPC, and a peering connection routes traffic to the VPC in the other account. RAM sharing requires both accounts to belong to the same organization in AWS Organizations, while peering has no such requirement and fits runs that only need to reach specific resources in the other account.

Key concepts

Choose between RAM sharing and VPC peering based on where your workflow runs must operate. With RAM sharing, the VPC owner shares subnets (and optionally security groups) with a participant in the same AWS Organization, and HealthOmics places elastic network interfaces (ENIs) directly in the shared VPC. With VPC peering, the requester and the accepter route traffic between their VPCs. The ENIs remain in the requester's VPC, and the peering connection routes traffic to the accepter's VPC. Both approaches use the same HealthOmics configuration resource. Only RAM sharing sets the vpcOwnerAccountId parameter.

The following terms identify the accounts in each approach:

Choosing an approach

The following table summarizes the differences between the two approaches.

If you already know your requirements, use the following guidance:

Using RAM sharing

Use this procedure to give your HealthOmics workflow runs access to subnets (and optionally security groups) that another AWS account shares with you using AWS Resource Access Manager (AWS RAM). The VPC owner shares subnets to your (participant) account, and HealthOmics places your workflow run's elastic network interfaces (ENIs) directly in the shared subnets. Use this approach for centralized networking models, such as a shared egress VPC managed by a central network account.

For more information about sharing VPC resources, see Share your VPC subnets with other accounts and Share security groups with AWS Organizations in the Amazon VPC User Guide.

Prerequisites

To use a RAM-shared VPC with HealthOmics, you must have:

Step 1: Create the VPC and share resources (VPC owner account)

Perform the following steps in the VPC owner account. You need permission to create AWS RAM resource shares. To enable sharing with AWS Organizations, sign in to the AWS RAM console with the organization's management account. For more information, see Enable resource sharing within AWS Organizations in the AWS RAM User Guide.

Before you begin, create the VPC, subnets, security groups, and any required connectivity (such as a NAT gateway) in the VPC owner account. For more information about VPC setup, see Connecting HealthOmics workflows to a VPC.

For more information, see Creating a resource share in AWS RAM in the AWS RAM User Guide.

Step 2: Accept the share and create a configuration (participant account)

To run your workflows inside the shared VPC, perform the following steps in the account that runs your HealthOmics workflows.

Create the HealthOmics configuration. Set vpcOwnerAccountId to the VPC owner's 12-digit account ID, and provide one or more shared subnet and security group IDs.

Console

In the HealthOmics console, create a configuration with the following JSON:

{
  "name": "cross-account-ram-config",
  "runConfigurations": {
    "vpcConfig": {
      "securityGroupIds": ["sg-1234567890abcdef0"],
      "subnetIds": ["subnet-1234567890abcdef0"],
      "vpcOwnerAccountId": "111122223333"
    }
  }
}

AWS CLI

aws omics create-configuration \
  --name cross-account-ram-config \
  --run-configurations '{
    "vpcConfig": {
      "securityGroupIds": ["sg-1234567890abcdef0"],
      "subnetIds": ["subnet-1234567890abcdef0"],
      "vpcOwnerAccountId": "111122223333"
    }
  }'

After creating the configuration:

For more information about VPC networking, see Connecting HealthOmics workflows to a VPC.

Verification

Confirm that RAM sharing is configured correctly:

Troubleshooting RAM sharing

For general AWS RAM problems, see Troubleshooting AWS Resource Access Manager in the AWS RAM User Guide.

Stopping a RAM share

As the VPC owner, you might stop sharing your subnets with a participant account when the participant no longer needs access, or to revoke access for security or compliance reasons. To stop a share, delete the AWS RAM resource share (or remove the participant as a principal) in the AWS RAM console.

When you stop a share, HealthOmics protects you from losing control of your VPC:

Using VPC peering

Use this procedure to give your HealthOmics workflow runs private connectivity to a resource in another account's VPC by creating a VPC peering connection. Your workflow run's ENIs remain in your own (requester) VPC, and the peering connection routes traffic to the accepter's VPC. You don't need any HealthOmics-specific setup for VPC peering, and you don't set the vpcOwnerAccountId parameter.

This procedure connects two accounts with a peering connection using IPv4. For more information about other peering scenarios, see the VPC Peering Guide.

Prerequisites

To use VPC peering with HealthOmics workflow runs, you must have:

Step 1: Create an Amazon VPC in your requester's account

Create an Amazon VPC, subnets, route tables, and a security group in your HealthOmics requester account. For instructions, see Create a VPC in the Amazon VPC User Guide.

Step 2: Create a VPC peering connection request

Create a VPC peering connection request from your requester's VPC to the accepter's VPC. For instructions, see Create a VPC peering connection in the Amazon VPC Peering Guide.

The peering connection stays in the Pending acceptance state until the accepter's account accepts it.

Step 3: Prepare the accepter's account

To create your peering connection and prepare the accepter's VPC to use the connection, log in to the accepter's account with a role that holds the permissions listed in the prerequisites. In the accepter's account, perform the following procedures.

Inspect the route tables for the accepter's VPC afterward. The route that Amazon VPC generates might not establish connectivity, based on how the accepter's VPC is set up. Check for conflicts between the new route and existing configuration for the VPC. For instructions on troubleshooting, see Troubleshoot a VPC peering connection in the Amazon VPC Peering Guide.

For more information, see Update your route tables for a VPC peering connection in the Amazon VPC Peering Guide.

For more information, see Configure security group rules in the Amazon VPC User Guide.

For more information, see Enable DNS resolution for a VPC peering connection in the Amazon VPC Peering Guide.

Step 4: Update VPC configuration in the requester's account

Log in to your requester's account, then update the VPC configuration.

For more information, see Update your route tables for a VPC peering connection in the Amazon VPC Peering Guide.

For more information, see Configure security group rules in the Amazon VPC User Guide.

For more information, see Enable DNS resolution for a VPC peering connection in the Amazon VPC Peering Guide.

Step 5: Run workflows with VPC peering

When starting a workflow run, use the subnets and security groups from the VPC in your requester's account. Don't set vpcOwnerAccountId. The VPC peering connection routes traffic from your workflow runs to the VPC in the other account.

For information about creating HealthOmics configuration resources and starting workflow runs with VPC networking, see Connecting HealthOmics workflows to a VPC.

Verification

Confirm that VPC peering is configured correctly:

Troubleshooting VPC peering

For general VPC peering problems, see Troubleshoot a VPC peering connection in the Amazon VPC Peering Guide.

Best practices

Follow these practices to keep your cross-account VPC configuration secure and maintainable:

Additional resources