AWS Device Farm

AWS Device Farm tests applications on real, physical phones and tablets hosted by AWS, rather than on emulators or on a device lab the team has to buy and maintain. It covers native and hybrid Android and iOS applications and web applications in desktop browsers.

There are two ways to use it.

Remote access

A remote access session puts a live device in the browser: you interact with it in real time, and the session produces a video recording and a log of what happened. It suits manual testing, reproducing a bug reported on a specific handset, checking rendering on an unusual screen, and walking through install and upgrade sequences.

The same session also exposes a managed Appium endpoint, so tests can be developed against a remote device from a local IDE — any client language, with breakpoints, live video and logs. A single session runs for up to 150 minutes.

Automated runs

An automated run uploads the application and the tests and executes them across a device pool — a set of devices chosen by platform, manufacturer or model — in parallel, in a managed test environment. The environment is configured with a test spec file, so no test infrastructure has to be provisioned. Test hosts and devices can connect into your VPC, which is what allows tests to exercise private endpoints rather than only public ones.

Two limits shape how a suite has to be written. A run is capped at 150 minutes per device, which is a hard limit, so a long suite has to be split rather than granted an extension. And the default concurrency for metered devices is five, so a pool of thirty devices is six waves, not one — the concurrency quota is adjustable on request, the run duration is not.

Each run produces a report with results, low-level logs, screenshots and any artefacts the tests emitted.

Worth knowing before planning around it

• Device Farm runs only in us-west-2 (Oregon). The service is not regional in the usual sense: projects, runs and devices live in that Region, which matters for a team whose other infrastructure and data are elsewhere, and for anything with data residency constraints.
• Billing is based on device time; the documentation and pricing distinguish metered from unmetered devices, so check which applies before estimating a large test suite. Queued runs are held for up to 24 hours before being dropped.
• Terminology is worth learning before reading the console: a project is a workspace, a run is one build tested against one or more devices, a job is one device within a run, and a session is an interactive remote access session.