Running Snowpark Container Services on AWS Graviton: The GEN_ARM_G1 Family

Last updated: May 2026

Why Adding ARM Compute to SPCS Is a Big Deal

Snowpark Container Services has, until now, been an x86-only world. If you wanted to run a custom Python service, a Streamlit app, a serving cluster, or a microservice inside Snowflake's security boundary, you ran it on x86 instances and paid x86 rates. AWS, meanwhile, has been quietly migrating more and more of its own workloads to Graviton (their in-house ARM processor) because the price-performance is better for most general-purpose work.

With the May 15, 2026 GA of GEN_ARM_G1, that option finally lands inside Snowflake. If your service is a typical web API, a queue worker, or a Python-based ETL helper, ARM is now on the table. The migration cost is rebuilding your container image for linux/arm64. The reward is potentially meaningful savings on long-running services.

What GEN_ARM_G1 Looks Like

Per the Snowpark Container Services documentation:

• CPU type: ARM / AWS Graviton
• vCPU options: 1, 3, 6, 14, 28
• Memory range: 6 to 116 GiB, scaling with vCPU
• GPU: none
• Use case: general-purpose containerized workloads requiring ARM architecture
• Image requirement: "ARM instances require container images built for the linux/arm64 platform" (Snowflake docs, verbatim)
• Region exclusions: not available in us-gov-west-1, us-gov-east-1, cn-northwest-1

For comparison, the x86 sibling, GEN_X64_G2, offers vCPU options of 1, 3, 6, and 28 with the same 6-116 GiB memory range and is "recommended for general-purpose containerized workloads."

Creating an ARM Compute Pool

The CREATE COMPUTE POOL syntax is the same for ARM as it is for x86; you just change the value of INSTANCE_FAMILY.

CREATE COMPUTE POOL [ IF NOT EXISTS ] <name>
  [ FOR APPLICATION <app-name> ]
  MIN_NODES = <num>
  MAX_NODES = <num>
  INSTANCE_FAMILY = <instance_family_name>
  [ AUTO_RESUME = { TRUE | FALSE } ]
  [ INITIALLY_SUSPENDED = { TRUE | FALSE } ]
  [ AUTO_SUSPEND_SECS = <num>  ]
  [ [ WITH ] TAG ( <tag_name> = '<tag_value>' [ , ... ] ) ]
  [ COMMENT = '<string_literal>' ]
  [ PLACEMENT_GROUP = '<placement_group_name>' ];

A practical example for an ARM compute pool that auto-suspends after 10 minutes of inactivity:

CREATE COMPUTE POOL arm_general_pool
  MIN_NODES = 1
  MAX_NODES = 4
  INSTANCE_FAMILY = GEN_ARM_G1
  AUTO_RESUME = TRUE
  AUTO_SUSPEND_SECS = 600
  COMMENT = 'ARM general-purpose pool for API services';

The defaults worth knowing (per the docs):

• AUTO_RESUME default: TRUE
• AUTO_SUSPEND_SECS default: 3600 (one hour)
• MIN_NODES must be greater than 0

Building a linux/arm64 Container Image

This is the only part of the migration that requires real engineering effort. Your existing linux/amd64 images will not run on GEN_ARM_G1. You need a multi-architecture build pipeline. The standard approach with Docker:

# One-time: create a buildx builder
docker buildx create --name multi-arch --use
docker buildx inspect --bootstrap

# Build and push for ARM specifically
docker buildx build \
  --platform linux/arm64 \
  -t <account>.registry.snowflakecomputing.com/<db>/<schema>/<repo>/myservice:arm64 \
  --push .

If you want a single tag that resolves to the right architecture, build a manifest list with both linux/amd64 and linux/arm64 entries:

docker buildx build \
  --platform linux/amd64,linux/arm64 \
  -t <account>.registry.snowflakecomputing.com/<db>/<schema>/<repo>/myservice:latest \
  --push .

Snowflake's image registry will pull the correct variant when an ARM compute pool requests the image.

Watch out for native binaries and wheels

Most Python and Node services migrate to ARM with no source changes. The places to inspect carefully:

• C extensions and Python wheels. Verify that every dependency has an ARM wheel on PyPI. Older packages sometimes ship x86 only and will trigger a slow source-compile or fail outright.
• Native binaries you bundle into the image. Tools like jq, kubectl, or a vendored ML runtime need their ARM variants installed instead of the x86 ones.
• Base image. Pull a multi-arch base image (python:3.12-slim, node:20-bookworm, etc.). Distroless and Alpine variants are also multi-arch.
• Cryptography libraries. Anything compiled against OpenSSL or a specific CPU feature flag deserves a quick benchmark; CPU features differ between Graviton generations.

Pointing a Service at the New Pool

The service specification YAML used by Snowpark Container Services does not need ARM-specific fields. You bind the service to the new compute pool when you create or alter it:

CREATE SERVICE myservice
  IN COMPUTE POOL arm_general_pool
  FROM SPECIFICATION_FILE = '@my_stage/service-spec.yaml'
  MIN_INSTANCES = 1
  MAX_INSTANCES = 3
  EXTERNAL_ACCESS_INTEGRATIONS = (my_eai);

If you have a service that today runs on an x86 pool and you want to migrate it, the simplest path is:

1. Build and push the linux/arm64 variant of the image (multi-arch tag if you can).
2. Stand up a parallel service on the ARM pool with a small MAX_INSTANCES and route a small fraction of traffic to it.
3. Validate response time, memory usage, error rate.
4. Shift the rest of the traffic over, then decommission the x86 service.

When ARM Is the Right Choice

Not every workload is a good ARM candidate. A pragmatic decision matrix:

Cost Conversation

Snowflake bills Snowpark Container Services through the standard Service Consumption Table, with credits depending on instance family and node count. Two principles to keep in mind:

1. Compare total job cost, not unit rate. ARM can be cheaper per vCPU-hour and still cost more in total if your service runs slower on it. Run a representative load test before promising savings.
2. Auto-suspend is your friend. For services with bursty traffic, set AUTO_SUSPEND_SECS low (e.g. 300-600 seconds) and let the pool spin down between bursts. This applies to both ARM and x86 pools.

If you already track Snowflake compute spend using our cost optimization guide, add an SPCS line item per instance family so the ARM versus x86 picture is visible.

Operational Tips

• Use multi-arch tags in CI. Build both linux/amd64 and linux/arm64 on every commit so you do not have a stale ARM variant if you ever need to switch back fast.
• Pin base images. Multi-arch builds depend on the base image being multi-arch. Pin to specific digests rather than rolling tags to avoid surprises.
• Watch container start time. Image pull is one-shot per cold start. Smaller, slim ARM images keep cold starts predictable.
• Tag the compute pool. Use the TAG clause to mark ARM pools so cost reports can group them. Example: TAG (cost_center = 'platform', arch = 'arm64').
• Combine with the rest of the SPCS toolkit. Autoscaling policies (GA on May 4, 2026) work on ARM pools the same way they work on x86 pools.

Where ARM Fits in the Wider SPCS Story

The ARM GA does not stand alone. Looking at the May 2026 release notes as a set, Snowflake materially expanded Snowpark Container Services:

• May 4, 2026: SPCS autoscaling policies reached GA.
• May 5, 2026: Four new instance families became GA — GEN_X64_G2, MEM_X64_G2, GPU_L40S, GPU_R6K.
• May 15, 2026: GEN_ARM_G1 became GA on AWS.

For platform teams, this is the moment to revisit whether SPCS can host workloads that previously lived in a dedicated EKS or ECS cluster. The compute menu now covers most general-purpose, memory-heavy, GPU, and ARM needs inside the Snowflake security boundary.

Key Takeaways

• GEN_ARM_G1 reached GA on Snowpark Container Services for AWS on May 15, 2026.
• vCPU options are 1, 3, 6, 14, 28; memory scales from 6 to 116 GiB; no GPU.
• Container images must be built for linux/arm64. Use docker buildx with multi-arch tags.
• Not available in us-gov-west-1, us-gov-east-1, cn-northwest-1.
• Strong fit for general APIs, queue workers, Streamlit apps. Less appropriate for AVX-heavy or GPU-bound work.
• Always benchmark total job cost, not unit rate. ARM is usually cheaper, sometimes meaningfully faster, occasionally neither.
• Pair with autoscaling policies (GA May 4, 2026) for bursty workloads.

Frequently Asked Questions

What is the GEN_ARM_G1 instance family?

The ARM-based (AWS Graviton) general compute instance family for Snowpark Container Services, GA on AWS as of May 15, 2026. vCPU options: 1, 3, 6, 14, 28. Memory: 6 to 116 GiB. No GPU.

Do I have to rebuild my container images for ARM?

Yes. The docs are explicit: "ARM instances require container images built for the linux/arm64 platform." Use docker buildx with a multi-arch tag.

Which regions does GEN_ARM_G1 support?

Commercial AWS regions, with the following exclusions per the docs: us-gov-west-1, us-gov-east-1, cn-northwest-1.

How do I create an ARM compute pool?

Run CREATE COMPUTE POOL ... INSTANCE_FAMILY = GEN_ARM_G1 with MIN_NODES and MAX_NODES. Optionally set AUTO_RESUME, INITIALLY_SUSPENDED, AUTO_SUSPEND_SECS, PLACEMENT_GROUP, TAG, COMMENT.

Is GEN_ARM_G1 cheaper than the x86 family?

ARM typically delivers better price-performance for general-purpose workloads. Pricing is in the Service Consumption Table; the right metric is total job cost. Benchmark a representative workload before migrating production services.