# I Wanted a Free Cloud GPU. I Ended Up With a Server That Encrypts 6 GB per Second. > Source: > Published: 2026-10-27 03:51:27+00:00 I signed up for Oracle Cloud with a fairly specific goal: I wanted access to a GPU without paying for expensive cloud infrastructure. I had been experimenting with CUDA, GPU-accelerated encryption, local language models, and performance benchmarking. Having another cloud machine available for testing seemed like a useful addition to my development environment. Oracle Cloud’s Free Tier looked promising. Some articles described surprisingly capable virtual machines that could run continuously without a monthly bill. But there was a catch. The free server didn’t include an NVIDIA GPU. At first, that felt like a disappointment. Then I discovered something more interesting: Oracle was offering a real ARM-based virtual machine with CPU resources, hardware cryptographic instructions, and enough memory to run meaningful experiments. By the end of the afternoon, I had a working Ubuntu server, remote SSH access, a reproducible benchmarking setup, and AES-256-CTR results approaching 6 GB/s. Here’s how it happened, what worked, what didn’t, and why the experience changed how I think about free cloud computing. Oracle Cloud Infrastructure (OCI) offers two different programs that are easy to confuse. The first is Free Trial, which provides promotional credits for eligible cloud services during a limited period. The second is Always Free, which provides a defined allocation of computing, storage, and other resources without a fixed expiration date, subject to service limits and account conditions. I was particularly interested in the Ampere A1 compute offering. At the time of my experiment, the Always Free allocation I used was equivalent to: ``` · 1,500 OCPU-hours per month.· 9,000 GB-hours of memory per month.· Approximately 2 OCPUs and 12 GB of RAM for continuous operation.· Up to 200 GB of combined Always Free boot and block volume storage. ``` An important detail: some older tutorials mention four OCPUs and 24 GB of RAM. Oracle documentation has shown different A1 limits across pages and account categories, so checking the current rules and your actual entitlement before provisioning is essential. I decided to use the conservative configuration: two OCPUs and 12 GB of RAM. Unlike an API-only sandbox, this is a Linux virtual machine where you can install compilers, run services, execute benchmarks, and control your own development environment. During registration, Oracle required me to select a home region. I chose Germany Central (Frankfurt), region identifier eu-frankfurt-1. This matters because Always Free compute is generally tied to the home region, and the home-region selection cannot simply be changed later. Availability may vary by region and availability domain. My first surprise came immediately after registration: the instance creation dialog showed no available Ubuntu or Oracle Linux images. Rather than immediately abandoning the account, I investigated. Oracle provides Cloud Shell, a browser-based terminal with the OCI command-line interface installed. I queried operating system images directly: ``` oci compute image list \ - compartment-id "$TENANCY_ID" \ - region eu-frankfurt-1 \ - operating-system "Canonical Ubuntu" \ - limit 10 \ - query 'data[].{Name:"display-name"}' \ - output table ``` The API returned Ubuntu images, including Ubuntu 24.04 for AArch64. I also queried available Ampere A1 shapes: ``` oci compute shape list \ - compartment-id "$TENANCY_ID" \ - region eu-frankfurt-1 \ - shape VM.Standard.A1.Flex ``` The A1 shape appeared in the results, and a compatibility query confirmed that my chosen Ubuntu ARM64 image supported it. The images existed. The shape existed. The API worked. The discrepancy appeared related to the console or the state of the newly created account, not the absence of Ubuntu in Frankfurt. Oracle had emailed me that it was still completing some account and billing setup. I retried later and the image selector worked. That timing suggests a possible connection, but does not prove the root cause. Lesson: When a cloud console shows no resources, don’t automatically assume the resources don’t exist. Query the API before drawing conclusions. I eventually selected this configuration: ``` · Region: Frankfurt, Germany.· Instance shape: VM.Standard.A1.Flex.· Operating system: Ubuntu 24.04 Minimal (AArch64 / ARM64).· CPU and memory: 2 OCPUs, 12 GB RAM.· Boot storage: default boot volume, approximately 47 GB provisioned.· Networking: public subnet, public IPv4 address.· Access: SSH public-key authentication. ``` ARM64 differs from the x86_64 architecture found in most Intel and AMD desktops. The OS image, compiled binaries, and some dependencies must match the processor architecture. I ran into one more issue: the initial instance setup could not attach a public IPv4 address because the new subnet was not yet recognized as public. Using the VCN Wizard to create a network with internet connectivity resolved that: it supplied a public subnet, routes, an internet gateway, and the associated network configuration. After selecting the existing public subnet, I could assign a public IP. Oracle reported the instance creation operation as successful in about 25 seconds. Shortly afterward, the VM was running. I downloaded the SSH key pair during setup, keeping the private key on my Windows computer. From PowerShell, I connected using: ``` ssh -i "$env:USERPROFILE\.ssh\oracle_research.key" \ubuntu@YOUR_PUBLIC_IP ``` My first attempt failed because I used a relative key path while in the wrong directory. The correct path fixed the issue. Inside Ubuntu, four commands were enough to confirm the environment: ``` uname -mnprocfree -hdf -h ``` · Architecture: aarch64. · Available CPUs: 2. · Memory: around 11 GiB as reported by Linux. · Root filesystem: roughly 45 GiB, with about 43 GiB free initially. I installed GCC, CMake, Git, Python, OpenSSL, and basic development utilities. I now had a working remote development machine. Because my original goal involved CUDA, I checked the PCI devices: ``` lspci ``` The output included: Display controller: Red Hat, Inc. Virtio 1.0 GPU This was not an NVIDIA accelerator. Virtio GPU is a virtualized graphics adapter presented to the guest machine. Its presence does not mean access to a physical CUDA GPU. Further checks found no NVIDIA PCI device. The available GPU service limits in my Oracle tenancy were either zero or not available. The conclusion: my Always Free Ampere A1 VM was a CPU server, not a CUDA workstation. Selecting a GPU-related image or installing CUDA software cannot manufacture GPU hardware. I inspected the processor: ``` lscpu ``` The CPU identified itself as ARM Neoverse-N1, with feature flags including: ``` aes pmull sha1 sha2 crc32 asimd ``` The aes flag indicates support for ARM cryptographic instructions that accelerate AES. pmull supports polynomial multiplication useful in authenticated encryption modes, and asimd provides ARM Advanced SIMD. That made this VM an appealing third platform for cryptography experiments alongside x86 AES-NI and NVIDIA CUDA systems. I used OpenSSL 3.0.13 on Ubuntu ARM64. My initial AES-128-CTR test ran on one CPU core: ``` taskset -c 0 openssl speed \-elapsed -seconds 10 \-evp aes-128-ctr ``` At the 16,384-byte buffer size, it reached approximately 4.02 GB/s. Next, I compared AES-256-CTR with OpenSSL ARM acceleration available by default against a run using OPENSSL_armcap=0. I repeated each configuration on one core and with two parallel processes. For the 16 KiB buffer, the measurements were: · Accelerated, 1 core: 3.008 GB/s. · Non-accelerated, 1 core: 0.170 GB/s. · Accelerated, 2 cores: 5.958 GB/s. · Non-accelerated, 2 cores: 0.336 GB/s. The throughput ratio was approximately 17.75× on one core and 17.71× with two cores. The accelerated two-core result approached 6 GB/s. It would be wrong to claim that ARM AES is universally 18 times faster than software encryption. Our test compared two OpenSSL execution configurations on a specific cloud ARM instance. OPENSSL_armcap=0 disables more than AES instructions, so it does not perfectly isolate the effect of AES alone. The benchmark also measures crypto processing, not full application behavior including file access, networking, or data movement. Even with those caveats, the result illustrates the potential impact of optimized instruction paths on CPU cryptography. At 16 KiB, two-core accelerated throughput was about 1.98× the single-core result, indicating near-linear scaling in this short synthetic experiment. I saved all four output logs rather than relying on copied terminal snippets: ``` aes256_hardware_1core.logaes256_hardware_2cores.logaes256_software_1core.logaes256_software_2cores.log ``` I also recorded system information and hashes: ``` date -uuname -alscpuopenssl version -asha256sum aes256_*.log ``` A final archive packaged the raw outputs and metadata. These preliminary tests are not a publication-grade benchmark campaign: repeated sessions, balanced test order, validation, and uncertainty analysis would be needed for stronger scientific claims. The lack of CUDA does not make the machine useless. Quite the opposite. · Remote development: a persistent Linux build and testing environment. · ARM64 compatibility testing: compile and validate software for a second CPU architecture. · C/C++ and Python experiments: run tools, tests, and automation on a real cloud VM. · CPU inference: investigate smaller quantized models with tools such as llama.cpp, subject to RAM and performance constraints. · Cryptography: compare hardware and software algorithm paths and study buffer-size behavior. · Self-hosted lightweight services: development APIs, automation jobs, and monitoring utilities. I would not choose it for CUDA development, large neural-network training, or GPU compute benchmarks. Matching the workload to the hardware matters more than its advertised price. Oracle Always Free is not unlimited infrastructure. There are quotas, region and capacity restrictions, conditions governing idle compute, and responsibilities for securing public-facing services. The home region is particularly important, because free compute entitlement is associated with it. A valid shape can also report insufficient available host capacity. A cloud VM with a public IP requires good administration: SSH keys, tightly scoped inbound access to port 22, software updates, and careful handling of credentials. The console cost estimate may show standard rates before Free Tier allowances. Always verify billing status and actual entitlements rather than assuming an estimated price is either a bill or a guarantee of zero cost. I started hoping for a free NVIDIA GPU. I didn’t get one. Instead I got a persistent ARM64 development server, learned to troubleshoot provisioning with CLI queries, configured remote access, and measured hardware-accelerated AES-CTR throughput approaching 6 GB/s. That doesn’t replace a high-end GPU. It demonstrates a different kind of value. Cryptography, compiling, automation, CPU inference, networking, and systems research can all benefit from modest but capable infrastructure. Sometimes the best free cloud resource isn’t the hardware you originally wanted. It’s the platform that lets you run real experiments, challenge assumptions, and learn something unexpected. And that is exactly what I found with Oracle Cloud Always Free. Technical note: Measurements were collected on October 23, 2026, using Oracle VM.Standard.A1.Flex with two ARM Neoverse-N1 cores, Ubuntu 24.04.5 LTS, and OpenSSL 3.0.13. GB/s values are decimal and refer to synthetic OpenSSL AES-CTR processing rather than end-to-end application throughput. Oracle program limits may change. [I Wanted a Free Cloud GPU. I Ended Up With a Server That Encrypts 6 GB per Second.](https://pub.towardsai.net/i-wanted-a-free-cloud-gpu-i-ended-up-with-a-server-that-encrypts-6-gb-per-second-b26d7ffe72d0) was originally published in [Towards AI](https://pub.towardsai.net) on Medium, where people are continuing the conversation by highlighting and responding to this story.