On paper, moving Oracle to AWS looks straightforward. In reality, the issues don’t show up until you’re in production.

What Breaks First

• Storage latency assumptions (EBS ≠ SAN)

• Backup strategy gaps (RMAN + S3 confusion)

• Network throughput bottlenecks

• Licensing misunderstandings

• Monitoring blind spots vs on-prem OEM

Real-World Fixes

1. Storage Matters More Than You Think

Use io1/io2 with proper IOPS sizing. Don’t “figure it out later.”

2. RDS vs EC2 is a Strategic Choice

RDS = easier ops, less control
EC2 = full control, more responsibility

Pick based on operational maturity, not convenience.

3. Rethink Monitoring

CloudWatch is not OEM. You need both perspectives.

4. Network is the Silent Killer

Throughput limits will impact performance before CPU does.

Lessons Learned

Most AWS Oracle problems aren’t Oracle problems—they’re architecture problems.

Takeaway

If you lift-and-shift without redesign, you’re just moving risk—not removing it.

Exadata patching looks simple on paper. In production, it’s where things go sideways fast.

What Usually Breaks

• GI patch order confusion

• Datapatch timing mistakes

• Rolling patch assumptions that aren’t actually safe

• Hidden dependencies between DB + Grid + storage

My Real-World Checklist

1. Validate cluster health (crsctl, olsnodes)

2. Confirm backup + restore point

3. Patch Grid Infrastructure first (rolling)

4. Patch DB homes

5. Run datapatch (validate ALL DBs)

6. Validate services and failover

Lessons Learned

Most issues don’t come from the patch—they come from assumptions.

Takeaway

If you treat patching like a checklist instead of a process, you will get burned.