Analyzing the Cost of Building Android on Google Cloud

A detailed analysis of the costs associated with building Android on GCP, including storage provisioning, compute expenses, and resource management best practices.

Building Android from source is a resource-intensive task requiring significant compute power and storage. Throughout this series, we successfully set up our environment, built AOSP 16, and ran the Cuttlefish emulator on Google Cloud Platform (GCP).

Now that the technical goals are met, it is valuable to analyze the financial aspect of this project. Understanding the cost structure is crucial for any developer or organization planning to move their build infrastructure to the cloud.

We conducted an audit of our project resources to provide a transparent look at the monthly operational costs.

Storage Analysis

We used the Google Cloud CLI (gcloud) to list the persistent disks currently provisioned in our project aosp-build-480610.

gcloud compute disks list --project=aosp-build-480610

Output:

NAME      LOCATION       LOCATION_SCOPE  SIZE_GB  TYPE         STATUS
aosp1     asia-south1-a  zone            1000     pd-standard  READY
aospdisk  asia-south1-a  zone            1000     pd-standard  READY

Our audit revealed two 1TB disks:

1. aosp1: The primary boot disk attached to our build instance.
2. aospdisk: A secondary disk from earlier configuration steps.

We checked the status of the secondary disk:

gcloud compute disks describe aospdisk --zone=asia-south1-a

The output confirmed that aospdisk was READY but had no associated users (instances). This identifies it as an unattached resource that continues to incur storage charges as long as it exists.

Compute Resources

Next, we reviewed the configuration of our Virtual Machine:

gcloud compute instances list --project=aosp-build-480610

Output:

NAME   ZONE           MACHINE_TYPE   PREEMPTIBLE  INTERNAL_IP  EXTERNAL_IP  STATUS
aosp1  asia-south1-a  n2-highmem-16               10.160.0.2                TERMINATED

Our instance is currently in the TERMINATED state. This is the correct state for a non-active build machine, as it halts hourly compute charges. However, the machine type remains configured as n2-highmem-16 (16 vCPUs, 128GB RAM).

• Cost Implication: While stopped instances do not incur compute costs, they reserve the configuration. If restarted for minor tasks without resizing, billing resumes at the high-memory rate.
• Best Practice: For long-term projects, consider resizing the instance to a smaller machine type (e.g., n2-standard-2) when not performing active builds.

Operational Cost Breakdown

We analyzed the billing report for December to understand the cost distribution. The recurring operational cost for this environment was approximately ₹7,941 (approx. $92).

The breakdown by resource type is as follows:

Key Observations

1. Storage Dominance: Storage accounted for nearly 80% of the total bill. This is due to the provisioned capacity model, where users are billed for the full size of the disk (1TB in this case) regardless of the actual data stored.
2. Idle Resource Costs: The unattached disk (aospdisk) contributed equally to the storage cost as the active boot disk. Identifying and removing unused resources is the single most effective cost-saving measure.
3. Compute vs. Storage: High-performance compute instances are expensive per hour, but their cost is intermittent. Storage costs are continuous, making them a significant factor in the total cost of ownership for cloud build environments.

Conclusion and Project Wrap-up

This analysis concludes our series on building AOSP on Google Cloud. We have successfully demonstrated the end-to-end workflow: configuring the cloud environment, compiling the Android source code, and validating the build with the Cuttlefish emulator.

From a resource perspective, we determined that storage capacity is the primary cost driver for this workload. Our audit confirms that a standard 1TB disk configuration incurs approximately ₹8,000/month in recurring costs.

Optimization Recommendation: For this experiment, a 500GB disk would have been sufficient to host the ~340GB build footprint. Choosing this smaller size would have reduced the monthly storage expenditure by 50% while still providing ample headroom for the source code and build artifacts.

With the project goals met, we will now proceed to decommission the environment by deleting the Virtual Machine and its associated Persistent Disks. This ensures that project resources are released and billing is concluded.

Happy building!