If you're running an Ampere A1 instance on Oracle Cloud's Always Free tier, it's worth logging into the console today. Oracle has quietly reduced the free A1 compute allowance, and starting August 18, 2026, it began enforcing the new limit — including, in some reported cases, against instances that were technically already compliant.
What Actually Changed
The Always Free allocation for VM.Standard.A1.Flex dropped from 4 OCPUs / 24GB RAM to 2 OCPUs / 12GB RAM across your entire tenancy. In Oracle's billing terms that's 1,500 OCPU-hours and 9,000 GB-hours per month, down from 3,000 / 18,000.
The two E2.1.Micro (AMD x86) always-free instances are untouched — still up to two, still 1/8 OCPU + 1GB each.
It's a Tenancy-Wide Budget, Not a Per-VM Cap
This trips a lot of people up. The 2 OCPU / 12GB is a total across all your A1 instances, not a ceiling per instance.
Compliant examples:
1 instance at 2 OCPU / 12GB
2 instances at 1 OCPU / 6GB each
1 instance at 1 OCPU / 4GB + 1 instance at 1 OCPU / 8GB
Non-compliant:
Your old single 4 OCPU / 24GB box
Two instances that together exceed 2 OCPU / 12GB
Check Your Own Tenancy
Console → Compute → Instances → filter for A1.Flex → sum up OCPU and memory across everything you have running.
Instance A: 1 OCPU / 6GB
Instance B: 1 OCPU / 6GB
Total: 2 OCPU / 12GB ✅ compliant
If your total is over 2/12, or if anything shows as Stopped/Disabled that you didn't stop yourself, you need to act now, not later.
The Part Nobody Announced
The documentation change appears to date back to around mid-June 2026, but enforcement was inconsistent for weeks — over-quota instances kept running, billing still showed $0, and the instance-creation UI didn't reflect the new limits. Then on August 18, Oracle started actually enforcing it.
Post-enforcement, Cloud Customer Connect forums saw two categories of complaints:
Users who were genuinely over quota — expected to be disabled.
Users at exactly 2 OCPU / 12GB — supposedly compliant — who got disabled anyway and had to open a support ticket to get reactivated.
Treat the second category as user-reported anecdotes, not confirmed platform-wide bugs — but they're common enough that "I'm within quota" isn't a guarantee your instance survived the sweep.
Fixing an Over-Quota Setup
Resize in place — shrink 4/24 down to 2/12 directly.
Split — go from one big instance to two smaller ones for flexibility.
Delete unused instances — if you provisioned extras "just in case," reclaim them.
Move to PAYG — if 2/12 genuinely isn't enough, the free allocation stays free, and anything beyond it bills normally.
One catch: an already-disabled instance often can't be resized from the console — you may need Oracle support to reactivate it first. Back up before you touch anything.
One More Wrinkle: PAYG Accounts
Community reports are contradictory here. Some Oracle support replies say PAYG accounts still get 4/24 under Always Free terms; others say the same 2/12 cap applies. The public docs don't currently distinguish PAYG from free-tier for A1 quota purposes. If you're on PAYG, don't trust forum threads — open a support ticket and get it in writing.
Does 2 OCPU / 12GB Still Hold Up?
For most lightweight workloads, yes: WordPress, a handful of Docker containers, n8n, an Nginx reverse proxy, small databases, homelab stuff. Where it gets tight is multiple heavy services running concurrently, larger databases, or local LLM inference — and remember these are ARM cores, so verify ARM64 support before you deploy anything, since that trips people up more than the RAM number does.
Combined with the untouched E2.1.Micro instances (good for monitoring, DNS, a jump host), the free tier is still one of the more generous ones on the market — just don't treat it as your only copy of anything important.
I wrote a longer breakdown with the full before/after tables and step-by-step console walkthrough here: Oracle Cloud Always Free Tier Changes — full analysis
Top comments (0)