top of page

Creating a Super Scalable Photogrammetry Service with AWS

In today's world, technology is enhancing our lives in countless ways, both personally and professionally. Take cell tower inspections, for instance. Not long ago, this was a hazardous and labor-intensive job that required someone to physically climb the tower for inspections.


However, with the latest advancements in drone technology, we're opening up new possibilities. Now, instead of dispatching a highly skilled climber, we can perform cell tower surveys using a semi-automatic quadcopter equipped with a camera. This approach not only improves safety but also boosts efficiency.

A person in a hard hat and blue jacket controls a drone near a structure by the sea, with a clear blue sky in the background.

Not only is the entire process safer, but it is also more comprehensive. For example, 2D photos captured by the drone can be used to create highly accurate 3D models through a process called photogrammetry. These models can then be utilized for various analyses, providing even greater insights.

Image showing photo grid on left, labeled "Photogrammetry", with blue arrow pointing to a 3D digital model of a tower on the right.

Yet, there is a caveat: photogrammetry can be resource-intensive. For an early-stage startup building mapping and analytical tools, investing in and maintaining its own data center can be challenging. Fortunately, cloud computing now offers startups a wide range of options. A startup doesn’t need to spend large sums on hardware or hire extra personnel to operate it. One can build a super scalable photogrammetry service with AWS.


Let’s explore how Apptimia built a scalable and reliable photogrammetry service around an existing photogrammetry engine for one of our customers by leveraging cloud computing.


Typically, a highly accurate 3D model requires around 1,000 high-resolution photos taken by a drone, with each photo being roughly 25MB. This results in about 25GB per photo set. Generating a 3D model from such a photo set using a photogrammetry engine running on an AWS g4dn.2xlarge EC2 instance can take up to 24 hours. This is a considerable amount of time for an analyst to wait. If you consider that some companies own thousands of cell towers, the entire process could span years.


There are two primary ways to scale a service:

  1. Vertical Scaling - Adding more powerful hardware to an existing machine.

  2. Horizontal Scaling - Adding more machines.


The first option is relatively simple on AWS if you are using Infrastructure as Code tools like AWS CloudFormation. It involves changing the instance type in the specification and redeploying the instance. However, this approach has its limits and was insufficient for our needs.


Fortunately, the photogrammetry engine supports parallelization via NFS, enabling horizontal scaling, which provides much greater scalability.

Flowchart of a photogrammetry engine network. A leader connects via NFS to three followers, sharing 2D photos and 3D data. Blue boxes.
Parallelization of photogrammetry worklows

There are several ways to horizontally scale workloads on AWS, including:

  1. AWS Lambda - A Function-as-a-Service (FaaS) solution with built-in autoscaling.

  2. AWS ECS - A container-based approach with configurable scaling behavior.

  3. AWS ALB + EC2 - A virtual machine-based approach with configurable autoscaling.


Given that the photogrammetry engine required significant resources, access to a specific OS and filesystem, extended runtime periods, and lacked container support, our only viable option was EC2. Additionally, since the photogrammetry engine handles coordination between nodes internally, no external load balancer was needed.


Taking these factors into account, we designed the following architecture:

Flowchart showing photogrammetry processing architecture with API Gateway, Lambda, Processing Queue, and worker nodes connecting to file storage.
Photogrammetry processing architecture

The architecture works as follows:

  1. A REST API ingests HTTP traffic and schedules 3D model generation tasks via an SQS queue, if necessary.

  2. The Process Runner Lambda function fetches messages from the SQS queue and starts a suitable EC2 instance (main worker) for the given photogrammetry job type.

  3. The main worker retrieves previously uploaded photos from an AWS S3 bucket, estimates the size of the 3D model, and starts additional EC2 worker nodes.

  4. Once the process is complete, the main worker uploads the generated 3D model to the S3 bucket and shuts down the entire cluster.


There are 2 key benefits of this solution:

  • Time reduction

  • Cost reduction


By running 40 simultaneous EC2 instances, we reduced the processing time from XX hours to XX minutes. This also allowed us to generate multiple photogrammetry models simultaneously.

AWS logo, clock icon with green arrow, and Amazon EC2 icons X1 and X40. Text reads "XX Hours" and "XX Minutes."

For early-stage startups with inconsistent system loads, it is cost-effective to run EC2 instances only when a 3D model needs to be processed. For example:

  • The on-demand hourly cost for a g4dn.2xlarge instance is $0.7520. Running 40 instances for 3 hours to process a model costs $0.7520 × 40 × 3 = $90.24 per job.

  • Assuming one model is processed per week over a year, the total cost is $90.24 × 53 weeks = $4,782.72.

  • In contrast, reserving 40 g4dn.2xlarge instances for a year would cost $0.3250 × 40 × 24 × 366 days = $114,192.


This demonstrates significant cost savings by using on-demand instances for sporadic workloads.

AWS diagram showing a process flow with EC2 icons, a collage of images on the left, an arrow pointing to a 3D model, and a cost-saving icon.

This is one of the many production-grade cloud systems we've built for our customers at Apptimia. If you're looking for scalable cloud processing systems, get in touch with us!

Bartosz Ch.

Lead Software Engineer at Apptimia

bottom of page