# Private devices in AWS Device Farm
A private device is a physical mobile device that AWS Device Farm deploys on your behalf in an Amazon data center. This device is exclusive to your AWS account.
**Note**
Currently, private devices are available only in the AWS US West (Oregon) Region (`us-west-2`).
If you have a private device fleet, you can create remote access sessions and schedule test runs with your private devices. For more information, see [Creating a test run or starting a remote access session in AWS Device Farm](create-test-run-using-private-devices.md). You can also create instance profiles to control the behavior of your private devices during a remote access session or a test run. For more information, see [Creating an instance profile in AWS Device Farm](set-up-private-devices-account-settings.md). Optionally, you can request that certain Android private devices be deployed as rooted devices.
You can also create an Amazon Virtual Private Cloud endpoint service to test private apps that your company has access to, but are not reachable through the internet. For example, you might have a web application running in your VPC that you want to test on mobile devices. For more information, see [Using Amazon VPC endpoint services with Device Farm - Legacy (not recommended)](amazon-vpc-endpoints.md).
If you're interested in using a fleet of private devices, [contact us](mailto:aws-devicefarm-support@amazon.com). The Device Farm team must work with you to set up and deploy a fleet of private devices for your AWS account.
**Topics**
+ [Creating an instance profile in AWS Device Farm](set-up-private-devices-account-settings.md)
+ [Request additional private devices in AWS Device Farm](managing-private-device-instance.md)
+ [Creating a test run or starting a remote access session in AWS Device Farm](create-test-run-using-private-devices.md)
+ [Selecting private devices in a device pool in AWS Device Farm](selecting-private-devices.md)
+ [Skipping app re-signing on private devices in AWS Device Farm](skip-app-re-signing-on-private-devices.md)
+ [Amazon VPC across AWS Regions in AWS Device Farm](amazon-vpc-cross-region.md)
+ [Terminating private devices in Device Farm](terminate-private-device.md)
# Creating an instance profile in AWS Device Farm
You can set up a fleet that contains one or more private devices. These devices are dedicated to your AWS account. After you set up the devices, you can optionally create one or more instance profiles for them. Instance profiles can help you automate test runs and consistently apply the same settings to device instances. Instances profiles can also help you control the behavior of remote access session. For more information about private devices in Device Farm, see [Private devices in AWS Device Farm](working-with-private-devices.md).
**To create an instance**
1. Open the Device Farm console at [https://console.aws.amazon.com/devicefarm/](https://console.aws.amazon.com/devicefarm/).
1. On the Device Farm navigation panel, choose **Mobile Device Testing**, then choose **Private devices**.
1. Choose **Instance profiles**.
1. Choose **Create instance profile**.
1. Enter a name for the instance profile.
![\[\]](http://docs.aws.amazon.com/devicefarm/latest/developerguide/images/aws-device-farm-private-devices-create-new-instance-profile.png)
1. (Optional) Enter a description for the instance profile.
1. (Optional) Change any of the following settings to specify which actions you want Device Farm to take on a device after each test run or session ends:
+ **Reboot after use** – To reboot the device, select this check box. By default, this check box is cleared (`false`).
+ **Package cleanup** – To remove all the app packages that you installed on the device, select this check box. By default, this check box is cleared (`false`). To keep all the app packages that you installed on the device, leave this check box cleared.
+ **Exclude packages from cleanup** – To keep only selected app packages on the device, select the **Package Cleanup** check box, and then choose **Add new**. For the package name, enter the fully qualified name of the app package that you want to keep on the device (for example, `com.test.example`). To keep more app packages on the device, choose **Add new**, and then enter the fully qualified name of each package.
1. Choose **Save**.
# Request additional private devices in AWS Device Farm
In AWS Device Farm, you can request an additional private device instances to be added to your fleet. You can also view and change the settings of existing private device instances in your fleet. For more information about private devices, see [Private devices in AWS Device Farm](working-with-private-devices.md).
**To request additional private devices or change their settings**
1. Open the Device Farm console at [https://console.aws.amazon.com/devicefarm/](https://console.aws.amazon.com/devicefarm/).
1. On the Device Farm navigation panel, choose **Mobile Device Testing**, then choose **Private devices**.
1. Choose **Device instances**. The **Device instances** tab displays a table of the private devices that are in your fleet. To quickly search or filter the table, enter search terms in the search bar above the columns.
1. To request a new private device instance, choose **Request device instance** or [contact us](mailto:aws-devicefarm-support@amazon.com). Private devices require additional setup with help from the Device Farm team.
1. In the table of device instances, choose the toggle option next to the instance that you want to view information about or manage, then choose **Edit**.
![\[\]](http://docs.aws.amazon.com/devicefarm/latest/developerguide/images/aws-device-farm-edit-device-instance.png)
1. To attach an instance profile to the device instance, choose it from the **Profile** drop-down list. Attaching an instance profile can be helpful if you want to always exclude a specific app package from cleanup tasks, for example. For more information about using instance profiles with devices, see [Creating an instance profile in AWS Device Farm](set-up-private-devices-account-settings.md).
1. (Optional) Under **Labels**, choose **Add new** to add a label to the device instance. Labels can help you categorize your devices and find specific devices more easily.
1. Choose **Save**.
# Creating a test run or starting a remote access session in AWS Device Farm
In AWS Device Farm, after you set up a private device fleet, you can create test runs or start remote access sessions with one or more private devices in your fleet. For more information about private devices, see [Private devices in AWS Device Farm](working-with-private-devices.md).
**To create a test run or start a remote access session**
1. Open the Device Farm console at [https://console.aws.amazon.com/devicefarm/](https://console.aws.amazon.com/devicefarm/).
1. On the Device Farm navigation panel, choose **Mobile Device Testing**, then choose **Projects**.
1. Choose an existing project from the list or create a new one. To create a new project, choose **New project**, enter a name for the project, and then choose **Submit**.
1. Do one of the following:
+ To create a test run, choose **Automated tests**, and then choose **Create a new run**. The wizard guides you through the steps to create the run. For the **Select devices** step, you can edit an existing device pool or create a new device pool that includes only those private devices that the Device Farm team set up and associated with your AWS account. For more information, see [Creating a private device pool with private devices (console)](selecting-private-devices.md#create-new-device-pool).
+ To start a remote access session, choose **Remote access**, and then choose **Start a new session**. On the **Choose a device** page, select **Private device instances only** to limit the list to only those private devices that the Device Farm team set up and associated with your AWS account. Then, choose the device that you want to access, enter a name for the remote access session, and choose **Confirm and start session**.
![\[\]](http://docs.aws.amazon.com/devicefarm/latest/developerguide/images/aws-device-farm-use-private-device-instances-only-remote-access-session.png)
# Selecting private devices in a device pool in AWS Device Farm
To use private devices in your test run, you can create a device pool that selects your private devices. Device pools enable you to select private devices primarily through three types of device pool rules:
1. Rules based on the device ARN
1. Rules based on the device instance label
1. Rules based on the device instance ARN
In the following sections, each rule type and their use cases are described in depth. You can use the Device Farm console, AWS Command Line Interface (AWS CLI), or the Device Farm API to create or modify a device pool with private devices using these rules.
**Topics**
+ [Device ARN](#device-arn-rules)
+ [Device instance labels](#device-instance-labels-rules)
+ [Instance ARN](#instance-arn-rules)
+ [Creating a private device pool with private devices (console)](#create-new-device-pool)
+ [Creating a private device pool with private devices (AWS CLI)](#how-to-create-device-pool-cli-private-devices)
+ [Creating a private device pool with private devices (API)](#how-to-create-device-pool-api-private-devices)
## Device ARN
A device ARN is an identifier representing a type of device rather than any specific physical device instance. A device type is defined by the following attributes:
+ The device’s fleet ID
+ The device’s OEM
+ The device’s model number
+ The device’s operating system version
+ The device's state that indicates whether it's rooted or not
Many physical device instances can be represented by a single device type where every instance of that type has the same values for these attributes. For example, if you had three *Apple iPhone 13* devices on iOS version *16.1.0* in your private fleet, each device would share the same device ARN. If any devices were added or removed from your fleet with these same attributes, the device ARN would continue to represent whatever available devices you had in your fleet for that device type.
The device ARN is the most robust way of selecting private devices for a device pool because it allows the device pool to continue selecting devices regardless of the specific device instances you have deployed at any given time. Individual private device instances can experience hardware failures, prompting Device Farm to automatically replace them with new working instances of the same device type. In these scenarios, the device ARN rule ensures that your device pool can continue to select devices in the event of a hardware failure.
When you use a device ARN rule for private devices in your device pool and schedule a test run with that pool, Device Farm will automatically check which private device instances are represented by that device ARN. Of the instances that are currently available, one of them will be assigned to run your test. If no instances are currently available, Device Farm will wait for the first available instance of that device ARN to become available, and assign it to run your test.
## Device instance labels
A device instance label is a textual identifier you can attach as metadata for a device instance. You can attach multiple labels to each device instance and the same label to multiple device instances. For more information about adding, modifying, or removing device labels from device instances, see [Managing private devices](https://docs.aws.amazon.com/devicefarm/latest/developerguide/managing-private-devices.html).
The device instance label can be a robust way of selecting private devices for a device pool because, if you have multiple device instances with the same label, then it allows the device pool to select from any one of them for your test. If the device ARN isn’t a good rule for your use case (for example, if you want to select from devices of multiple device types, or if you want to select from a subset of all devices of a device type), then device instance labels can enable you to select from multiple devices for your device pool with greater granularity. Individual private device instances can experience hardware failures, prompting Device Farm to automatically replace them with new working instances of the same device type. In these scenarios, the replacement device instance will not retain any instance label metadata of the replaced device. So, if you apply the same device instance label to multiple device instances, then the device instance label rule ensures that your device pool can continue to select device instances in the event of a hardware failure.
When you use a device instance label rule for private devices in your device pool and schedule a test run with that pool, Device Farm will automatically check which private device instances are represented by that device instance label, and of those instances, randomly select one which is available to run your test. If none are available, Device Farm will randomly select any device instance with the device instance label to run your test and queue the test to run on the device once it’s available.
## Instance ARN
A device instance ARN is an identifier representing a physical bare metal device instance deployed in a private fleet. For example, if you had three *iPhone 13* devices on OS *15.0.0* in your private fleet, while each device would share the same device ARN, each device would also have its own instance ARN representing that instance alone.
The device instance ARN is the least robust way to select private devices for a device pool and is only recommended if the device ARNs and device instance labels don’t fit your use case. Device instance ARNs are often used as rules for device pools when a specific device instance is configured in a unique and specific way as a prerequisite for your test and if that configuration needs to be known and verified before the test is ran on it. Individual private device instances can experience hardware failures, prompting Device Farm to automatically replace them with new working instances of the same device type. In these scenarios, the replacement device instance will have a different device instance ARN than the replaced device. So, if you rely on device instance ARNs for your device pool, then you’ll need to manually change your device pool’s rule definition from using the old ARN to using the new ARN. If you do need to manually preconfigure the device for its test, then this can be an effective workflow (compared to device ARNs). For testing at scale, it is recommended to try to adapt these use cases to work with device instance labels and if possible, have multiple device instances preconfigured for testing.
When you use a device instance ARN rule for private devices in your device pool and schedule a test run with that pool, Device Farm will automatically assign that test to that device instance. If that device instance isn’t available, Device Farm will queue the test on the device once it’s available.
## Creating a private device pool with private devices (console)
When you create a test run, you can create a device pool for the test run and ensure that the pool includes only your private devices.
**Note**
When creating a device pool with private devices in the console, you can only use any one of the three available rules for selecting private devices. If you want to create a device pool that contains multiple types of rules for private devices (for example, device pools that contain rules for device ARNs and device instance ARNs), then you need to create the pool through the CLI or API.
1. Open the Device Farm console at [https://console.aws.amazon.com/devicefarm/](https://console.aws.amazon.com/devicefarm/).
1. On the Device Farm navigation panel, choose **Mobile Device Testing**, then choose **Projects**.
1. Choose an existing project from the list or create a new one. To create a new project, choose **New project**, enter a name for the project, and then choose **Submit**.
1. Choose **Project settings**, and then navigate to the **Device pools** tab.
1. Choose **Create device pool**, and enter a name and optional description for your device pool.
1. To use device ARN rules for your device pool, choose **Create static device pool**, then select the specific device types from the list that you would like to use in the device pool. Do not select **Private device instances only** because this option causes the device pool to be created with device instance ARN rules (instead of device ARN rules).
![\[Device selection method options for creating a static or dynamic device pool.\]](http://docs.aws.amazon.com/devicefarm/latest/developerguide/images/aws-device-farm-create-new-device-pool-private-devices.png)
1. To use device instance label rules for your device pool, choose **Create dynamic device pool**. Then, for each label you would like to use in the device pool, choose **Add a rule**. For each rule, choose **Instance Labels** as the `Field`, choose **Contains** as the `Operator`, and specify your desired device instance label as the `Value`.
![\[Device pool creation interface with dynamic selection method and attribute filter options.\]](http://docs.aws.amazon.com/devicefarm/latest/developerguide/images/aws-device-farm-create-new-device-pool-private-devices-add-rule.png)
1. To use device instance ARN rules for your device pool, choose **Create static device pool**, then select **Private device instances only** to limit the list of devices to only those private device instances that Device Farm has associated with your AWS account.
![\[Device selection options for creating a static device pool with private instances.\]](http://docs.aws.amazon.com/devicefarm/latest/developerguide/images/aws-device-farm-create-new-device-pool-private-device-instance-only.png)
1. Choose **Create**.
## Creating a private device pool with private devices (AWS CLI)
+ Run the [https://docs.aws.amazon.com/cli/latest/reference/devicefarm/create-device-pool.html](https://docs.aws.amazon.com/cli/latest/reference/devicefarm/create-device-pool.html) command.
For information about using Device Farm with the AWS CLI, see [AWS CLI reference](cli-ref.md).
## Creating a private device pool with private devices (API)
+ Call the [https://docs.aws.amazon.com/devicefarm/latest/APIReference/API_CreateDevicePool.html](https://docs.aws.amazon.com/devicefarm/latest/APIReference/API_CreateDevicePool.html) API.
For information about using the Device Farm API, see [Automating Device Farm](api-ref.md).
# Skipping app re-signing on private devices in AWS Device Farm
App signing is a process that involves digitally signing an app package (e.g., [APK](https://developer.android.com/studio/publish/app-signing), [IPA](https://support.apple.com/guide/security/app-code-signing-process-sec7c917bf14/web)) with a private key before it can be installed on a device or published to an app store like the Google Play Store or the Apple App Store. To streamline testing by reducing the number of signatures and profiles needed and increase data security on remote devices, AWS Device Farm will re-sign your app after it has been uploaded to the service.
Once you upload your app to AWS Device Farm, the service will generate a new signature for the app using its own signing certificates and provisioning profiles. This process replaces the original app signature with AWS Device Farm's signature. The re-signed app is then installed on the test devices provided by AWS Device Farm. The new signature allows the app to be installed and run on these devices without the need for the original developer's certificates.
On iOS, we replace the embedded provisioning profile with a wildcard profile and re-sign the app. If you provide it, we will add auxiliary data to the application package before installation so the data will be present in your app’s sandbox. Re-signing the iOS app results in the removal of all entitlements.
On Android, we re-sign the app. This may break functionality that depends on the app signature, such as the Google Maps Android API. It may also trigger anti-piracy and anti-tamper detection available from products such as DexGuard. For built-in tests, we may modify the manifest to include permissions required to capture and save screenshots.
When you use private devices, you can skip the step where AWS Device Farm re-signs your app. This is different from public devices, where Device Farm always re-signs your app on the Android and iOS platforms.
You can skip app re-signing when you create a remote access session or a test run. This can be helpful if your app has functionality that breaks when Device Farm re-signs your app. For example, push notifications might not work after re-signing. For more information about the changes that Device Farm makes when it tests your app, see the [AWS Device Farm FAQs](https://aws.amazon.com/device-farm/faq/) or the [Apps](https://docs.aws.amazon.com/devicefarm/latest/developerguide/apps.html) page.
To skip app re-signing for a test run, select **Skip app re-signing** under **Additional configuration**. This option is only available for private devices.
![\[\]](http://docs.aws.amazon.com/devicefarm/latest/developerguide/images/aws-device-farm-skip-app-re-signing.png)
**Note**
If you're using the XCTest framework, the **Skip app re-signing** option is not available. For more information, see [Integrating Device Farm with XCTest for iOS](test-types-ios-xctest.md).
Additional steps for configuring your app-signing settings vary, depending on whether you're using private Android or iOS devices.
## Skipping app re-signing on Android devices
If you're testing your app on a private Android device, select **Skip app re-signing** when you create your test run or your remote access session. No other configuration is required.
## Skipping app re-signing on iOS devices
Apple requires you to sign an app for testing before you load it onto a device. For iOS devices, you have two options for signing your app.
+ If you're using an in-house (Enterprise) developer profile, you can skip to the next section, [Creating a remote access session to trust your iOS app](#create-remote-session-trust-your-app).
+ If you're using an ad hoc iOS app development profile, you must first register the device with your Apple developer account, and then update your provisioning profile to include the private device. You must then re-sign your app with the provisioning profile that you updated. You can then run your re-signed app in Device Farm.
**To register a device with an ad hoc iOS app development provisioning profile**
1. Sign in to your Apple developer account.
1. Navigate to the **Certificates, IDs, and Profiles** section of the console.
1. Go to **Devices**.
1. Register the device in your Apple developer account. To get the name and UDID of the device, use the `ListDeviceInstances` operation of the Device Farm API.
1. Go to your provisioning profile and choose **Edit**.
1. Choose the device from the list.
1. In Xcode, fetch your updated provisioning profile, and then re-sign the app.
No other configuration is required. You can now create a remote access session or a test run and select **Skip app re-signing**.
## Creating a remote access session to trust your iOS app
If you're using an in-house (Enterprise) developer provisioning profile, you must perform a one-time procedure to trust the in-house app developer certificate on each of your private devices.
To do so, you must install a placeholder app that's signed with the same certificate as the app that you want to test. After the device trusts the configuration profile or enterprise app developer, all apps from that developer are trusted on the private device until you delete them. Therefore, when you install new versions of the app that you want to test, you won't have to trust the app developer again each time. This is particularly useful if you run test automations and you don't want to create a remote access session each time you test your app.
A common procedure many customers use is to re-sign the [Device Farm sample app for iOS](https://github.com/aws-samples/aws-device-farm-sample-app-for-ios/blob/master/prebuilt/prebuiltSampleApp.ipa), then install this onto their device as the placeholder app.
Before you start your remote access session, follow the steps in [Creating an instance profile in AWS Device Farm](set-up-private-devices-account-settings.md) to create or modify an instance profile in Device Farm. In the instance profile, add the bundle ID of the placeholder app to the **Exclude packages from cleanup** setting. Then, attach the instance profile to the private device instance to ensure that Device Farm doesn't remove this app from the device before it starts a new test run. This ensures that your developer certificate remains trusted.
You can upload the placeholder app to the device by using a remote access session, which allows you to launch the app and trust the developer.
1. Follow the instructions in [Creating a session](how-to-create-session.md) to create a remote access session that uses the private device instance profile that you created. When you create your session, be sure to select **Skip app re-signing**.
![\[\]](http://docs.aws.amazon.com/devicefarm/latest/developerguide/images/aws-device-farm-create-reomte-access-session-skip-app-resigning.png)
**Important**
To filter the list of devices to include only private devices, select **Private device instances only** to ensure that you use a private device with the correct instance profile.
Be sure to also add the placeholder app or the app that you want to test to the **Exclude packages from cleanup** setting for the instance profile that's attached to this instance.
1. When your remote session starts, choose **Choose File** to install an application that uses your in-house provisioning profile.
1. Launch the app that you just uploaded.
1. Confirm that an iOS dialogue box appears indicating that the enterprise app developer is untrusted.
1. Then, if the iOS device is on iOS version 18 or greater, open a support ticket with the AWS Device Farm team to have our team trust the app for you, since these devices require the app to be manually trusted. Otherwise, if the iOS version is 17 or lower, you can go into the **Settings** app, and, under **General** settings, trust the app yourself from the **VPN and Profiles** menu.
All apps from this configuration profile or enterprise app developer are now trusted on this private device until you delete them.
# Amazon VPC across AWS Regions in AWS Device Farm
Device Farm services are located only in the US West (Oregon) (`us-west-2`) Region. You can use Amazon Virtual Private Cloud (Amazon VPC) to reach a service in your Amazon Virtual Private Cloud in another AWS Region using Device Farm. If Device Farm and your service are in the same Region, see [Using Amazon VPC endpoint services with Device Farm - Legacy (not recommended)](amazon-vpc-endpoints.md).
There are two ways to access your private services located in a different Region. If you have services located in one other Region that's not `us-west-2`, you can use VPC Peering in order to peer that Region’s VPC to another VPC that is interfacing with Device Farm in `us-west-2`. However, if you have services in multiple Regions, a Transit Gateway will allow you to access those services with a simpler network configuration.
For more information, see [VPC peering scenarios](https://docs.aws.amazon.com/vpc/latest/peering/peering-scenarios.html) in the *Amazon VPC Peering Guide*.
## VPC peering overview for VPCs in different Regions in AWS Device Farm
You can peer any two VPCs in different Regions as long as they have distinct, non-overlapping CIDR blocks. This ensures that all of the private IP addresses are unique, and it allows all of the resources in the VPCs to address each other without the need for any form of network address translation (NAT). For more information about CIDR notation, see [RFC 4632](https://tools.ietf.org/html/rfc4632).
This topic includes a cross-Region example scenario in which Device Farm (referred to as *VPC-1*) is located in the US West (Oregon) (`us-west-2`) Region. The second VPC in this example (referred to as *VPC-2*) is in another Region.
**Device Farm VPC cross-Region example**
| VPC Component | VPC-1 | VPC-2 |
| --- | --- | --- |
| CIDR | 10.0.0.0/16 | 172.16.0.0/16 |
**Important**
Establishing a peering connection between two VPCs can change the security posture of the VPCs. In addition, adding new entries to their route tables can change the security posture of the resources within the VPCs. It is your responsibility to implement these configurations in a way that meets your organization's security requirements. For more information, please see the [Shared responsibility model](https://aws.amazon.com/compliance/shared-responsibility-model/).
The following diagram shows the components in the example and the interactions between these components.
![\[Work with private devices across AWS Regions.\]](http://docs.aws.amazon.com/devicefarm/latest/developerguide/images/device-farm-vpc-across-region-vpn.png)
**Topics**
+ [VPC peering overview for VPCs in different Regions in AWS Device Farm](#device-farm-vpce-configuration-cross-region-vpc-overview)
+ [Prerequisites for using Amazon VPC in AWS Device Farm](#device-farm-vpce-configuration-cross-region-prerequisites)
+ [Step 1: Setting up a peering connection between VPC-1 and VPC-2](#device-farm-vpce-configuration-cross-region-step1)
+ [Step 2: Updating the route tables in VPC-1 and VPC-2](#device-farm-vpce-configuration-cross-region-step2)
+ [Step 3: Creating a target group](#device-farm-vpce-configuration-cross-region-step3)
+ [Step 4: Creating a Network Load Balancer](#device-farm-vpce-configuration-cross-region-step4)
+ [Step 5: Creating a VPC endpoint service to connect your VPC to Device Farm](#device-farm-vpce-configuration-cross-region-step5)
+ [Step 6: Create a VPC endpoint configuration between your VPC and Device Farm](#device-farm-vpce-configuration-cross-region-step6)
+ [Step 7: Creating a test run to use the VPC endpoint configuration](#device-farm-vpce-configuration-cross-region-step7)
+ [Creating a scalable network with Transit Gateway](#device-farm-vpce-configuration-cross-region-transit-gateways)
## Prerequisites for using Amazon VPC in AWS Device Farm
This example requires the following:
+ Two VPCs that are configured with subnets containing non-overlapping CIDR blocks.
+ *VPC-1* must be in the `us-west-2` Region and contain subnets for Availability Zones `us-west-2a`, `us-west-2b`, and `us-west-2c`.
For more information on creating VPCs and configuring subnets, see [Working with VPCs and subnets](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html) in the *Amazon VPC Peering Guide*.
## Step 1: Setting up a peering connection between VPC-1 and VPC-2
Establish a peering connection between the two VPCs containing non-overlapping CIDR blocks. To do this, see [Create and accept VPC peering connections](https://docs.aws.amazon.com/vpc/latest/peering/create-vpc-peering-connection.html) in the *Amazon VPC Peering Guide*. Using this topic's cross-Region scenario and the *Amazon VPC Peering Guide*, the following example peering connection configuration is created:
**Name**
`Device-Farm-Peering-Connection-1`
**VPC ID (Requester)**
`vpc-0987654321gfedcba (VPC-2)`
**Account**
`My account`
**Region**
`US West (Oregon) (us-west-2)`
**VPC ID (Accepter)**
`vpc-1234567890abcdefg (VPC-1)`
**Note**
Ensure that you consult your VPC peering connection quotas when establishing any new peering connections. For more information, please see [Amazon VPC quotas](https://docs.aws.amazon.com/vpc/latest/userguide/amazon-vpc-limits.html#vpc-limits-peering) in the *Amazon VPC Peering Guide*.
## Step 2: Updating the route tables in VPC-1 and VPC-2
After setting up a peering connection, you must establish a destination route between the two VPCs to transfer data between them. To establish this route, you can manually update the route table of *VPC-1* to point to the subnet of *VPC-2* and vice versa. To do this, see [Update your route tables for a VPC peering connection](https://docs.aws.amazon.com/vpc/latest/peering/vpc-peering-routing.html) in the *Amazon VPC Peering Guide*. Using this topic's cross-Region scenario and the *Amazon VPC Peering Guide*, the following example route table configuration is created:
**Device Farm VPC route table example**
| VPC component | VPC-1 | VPC-2 |
| --- | --- | --- |
| Route table ID | rtb-1234567890abcdefg | rtb-0987654321gfedcba |
| Local address range | 10.0.0.0/16 | 172.16.0.0/16 |
| Destination address range | 172.16.0.0/16 | 10.0.0.0/16 |
## Step 3: Creating a target group
After you set up your destination routes, you can configure a Network Load Balancer in *VPC-1* to route requests to *VPC-2*.
The Network Load Balancer must first contain a target group that contains the IP addresses to which requests are sent.
**To create a target group**
1. Identify the IP addresses of the service that you want to target in *VPC-2*.
+ These IP addresses must be members of the subnet used in the peering connection.
+ The targeted IP addresses must be static and immutable. If your service has dynamic IP addresses, consider targeting a static resource (such as a Network Load Balancer) and having that static resource route requests to your true target.
**Note**
If you're targeting one or more stand-alone Amazon Elastic Compute Cloud (Amazon EC2) instances, open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2), then choose **Instances**.
If you're targeting an Amazon EC2 Auto Scaling group of Amazon EC2 instances, you must associate the Amazon EC2 Auto Scaling group to a Network Load Balancer. For more information, see [Attaching a load balancer to your Auto Scaling group](https://docs.aws.amazon.com/autoscaling/ec2/userguide/attach-load-balancer-asg.html) in the *Amazon EC2 Auto Scaling User Guide*.
Then, you can open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2), and then choose **Network Interfaces**. From there you can view the IP addresses for each of the Network Load Balancer's network interfaces in each **Availability Zone**.
1. Create a target group in *VPC-1*. To do this, see [Create a target group for your Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/create-target-group.html) in the *User Guide for Network Load Balancers*.
Target groups for services in a different VPC require the following configuration:
+ For **Choose a target type**, choose **IP addresses**.
+ For **VPC**, choose the VPC that will host the load balancer. For the topic example, this will be *VPC-1*.
+ On the **Register targets** page, register a target for each IP address in *VPC-2*.
For **Network**, choose **Other private IP address**.
For **Availability Zone**, choose your desired zones in *VPC-1*.
For **IPv4 address**, choose the *VPC-2* IP address.
For **Ports**, choose your ports.
+ Choose **Include as pending below**. When you're finished specifying addresses, choose **Register pending targets**.
Using this topic's cross-Region scenario and the *User Guide for Network Load Balancers*, the following values are used in the target group configuration:
**Target type**
`IP addresses`
**Target group name**
`my-target-group`
**Protocol/Port**
`TCP : 80`
**VPC**
`vpc-1234567890abcdefg (VPC-1)`
**Network**
`Other private IP address`
**Availability Zone**
`all`
**IPv4 address**
`172.16.100.60`
**Ports**
`80`
## Step 4: Creating a Network Load Balancer
Create a Network Load Balancer using the target group described in [step 3](#device-farm-vpce-configuration-cross-region-step3). To do this, see [Creating a Network Load Balancer](amazon-vpc-endpoints.md#device-farm-create-nlb).
Using this topic's cross-Region scenario, the following values are used in an example Network Load Balancer configuration:
**Load balancer name**
`my-nlb`
**Scheme**
`Internal`
**VPC**
`vpc-1234567890abcdefg (VPC-1)`
**Mapping**
`us-west-2a` - `subnet-4i23iuufkdiufsloi`
`us-west-2b` - `subnet-7x989pkjj78nmn23j`
`us-west-2c` - `subnet-0231ndmas12bnnsds`
**Protocol/Port**
`TCP : 80`
**Target Group**
`my-target-group`
## Step 5: Creating a VPC endpoint service to connect your VPC to Device Farm
You can use the Network Load Balancer to create a VPC endpoint service. Through this VPC endpoint service, Device Farm can connect to your service in *VPC-2* without any additional infrastructure, such as an internet gateway, NAT instance, or VPN connection.
To do this, see [Creating an Amazon VPC endpoint service](amazon-vpc-endpoints.md#device-farm-vpce-configuration-vpc-endpoint).
## Step 6: Create a VPC endpoint configuration between your VPC and Device Farm
Now you can establish a private connection between your VPC and Device Farm. You can use Device Farm to test private services without exposing them through the public internet. To do this, see [Creating a VPC endpoint configuration in Device Farm](amazon-vpc-endpoints.md#device-farm-edit-devicefarm-settings-vpc-endpoint).
Using this topic's cross-Region scenario, the following values are used in an example VPC endpoint configuration:
**Name**
`My VPCE Configuration`
**VPCE service name**
`com.amazonaws.vpce.us-west-2.vpce-svc-1234567890abcdefg`
**Service DNS name**
`devicefarm.com`
## Step 7: Creating a test run to use the VPC endpoint configuration
You can create test runs that use the VPC endpoint configuration described in [step 6](#device-farm-vpce-configuration-cross-region-step6). For more information, see [Creating a test run in Device Farm](how-to-create-test-run.md) or [Creating a session](how-to-create-session.md).
## Creating a scalable network with Transit Gateway
To create a scalable network using more than two VPCs, you can use Transit Gateway to act as a network transit hub to interconnect your VPCs and on-premises networks. To configure a VPC in the same region as Device Farm to use a Transit Gateway, you can follow the [Amazon VPC endpoint services with Device Farm](https://docs.aws.amazon.com/devicefarm/latest/developerguide/amazon-vpc-endpoints.html) guide to target resources in another region based on their private IP addresses.
For more information about Transit Gateway, see [What is a transit gateway?](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) in the *Amazon VPC Transit Gateways Guide*.
# Terminating private devices in Device Farm
To terminate a private device after your initial agreed term, you must provide a 30-day notice of non-renewal via our email at aws-devicefarm-support@amazon.com. For more information about private devices, see [Private devices in AWS Device Farm](working-with-private-devices.md).
**Important**
These instructions **only** apply to terminating private device agreements. For all other AWS services and billing issues, see the respective documentation for those products or contact AWS support.