OCI Architect Professional (1Z0-997-24) - Fact Sheet¶

Objectives:
- Zero RTO/RPO
- Global load distribution
- Regional fault tolerance

Components:
Region 1 (us-phoenix-1):
├── Full application stack
├── Database with multi-region replication
├── Object Storage with cross-region replication
└── Traffic Manager health check

Region 2 (us-ashburn-1):
├── Full application stack (identical)
├── Database with multi-region replication
├── Object Storage with cross-region replication
└── Traffic Manager health check

Traffic Manager:
├── Health checks on both regions
├── Geolocation steering (users → nearest region)
├── Failover policy (automatic rerouting on failure)
└── Load balancer policy (distribute across healthy regions)

Data Synchronization:
- Database: GoldenGate bidirectional replication
- Object Storage: Cross-region replication
- Conflict resolution: Last-write-wins or custom logic

Considerations:
+ Zero downtime for regional failures
+ Low latency (users routed to nearest region)
+ No data loss with synchronous replication
- Highest cost (fully duplicated infrastructure)
- Complex conflict resolution
- Requires global database technology

Objectives:
- Balance cost and availability
- RTO: 1-4 hours, RPO: minutes

Primary Region (us-phoenix-1):
├── Full production environment
├── Database (primary)
├── Regular cross-region backups
└── Autonomous Data Guard to secondary

Secondary Region (us-ashburn-1):
├── Minimal infrastructure (pilot light)
│   ├── VCN and subnets (pre-configured)
│   ├── Load balancer (stopped or minimal)
│   └── Compute instances (stopped or minimal)
├── Database standby (Autonomous Data Guard)
├── Backups replicated from primary
└── Resource Manager stacks ready to scale up

Failover Process:
1. Detect primary region failure
2. Switchover database to secondary (automatic with ADG)
3. Resource Manager: Scale up compute instances
4. Update DNS to point to secondary region
5. Monitor and validate in secondary region

Considerations:
+ Lower cost than active-active
+ Reasonably fast recovery (1-4 hours)
+ Near-zero data loss with ADG
- Manual or semi-automated failover
- Requires regular DR testing

Objectives:
- Global content delivery
- Low latency for static content
- Regional processing for dynamic content

Architecture:
Edge Layer (Global):
├── CDN (3rd party or OCI)
├── WAF (Web Application Firewall)
└── DDoS protection

Traffic Management:
├── Geolocation routing
├── Performance-based routing
└── Health-based failover

Regional Processing (Multiple Regions):
Region 1, 2, 3...:
├── API Gateway
├── Application servers
├── Regional caching
└── Backend services

Central Data Layer (Primary Region):
├── Master database
├── Object Storage (origin for CDN)
└── Data replication to edge regions

Considerations:
+ Excellent performance for global users
+ Reduced load on origin servers
+ Built-in DDoS protection at edge
- Complexity in cache invalidation
- Increased monitoring surface

Objectives:
- Extend on-premises to cloud
- Low latency, high bandwidth
- Private connectivity

On-Premises:
├── Data Center 1
│   ├── Core applications
│   ├── Primary database
│   └── FastConnect (10 Gbps) → OCI
└── Data Center 2
    ├── DR site
    ├── Standby database
    └── FastConnect (10 Gbps) → OCI

OCI (Primary Region):
├── VCN with DRG
├── Compute instances (burst capacity)
├── Object Storage (shared storage)
├── Autonomous Database (analytics)
└── FastConnect termination

Connectivity:
- FastConnect via 3rd party provider
- Redundant connections (2x 10 Gbps)
- BGP routing for automatic failover
- Private IP addressing (RFC 1918)

Use Cases:
- Cloud bursting (scale to OCI during peaks)
- Disaster recovery (OCI as DR site)
- Hybrid applications (on-prem + cloud components)
- Data analytics (process data in OCI)

Considerations:
+ High bandwidth, low latency
+ Private, secure connectivity
+ Predictable network performance
- Higher cost than VPN
- Requires provider availability
- 30-90 day lead time for provisioning

Objectives:
- Cost-effective hybrid connectivity
- Redundancy for high availability
- Encryption by default

Architecture:
On-Premises:
├── CPE 1 (Primary)
│   ├── Tunnel 1 → OCI VPN 1 (IPSec)
│   └── Tunnel 2 → OCI VPN 2 (IPSec)
└── CPE 2 (Secondary)
    ├── Tunnel 3 → OCI VPN 1 (IPSec)
    └── Tunnel 4 → OCI VPN 2 (IPSec)

OCI:
├── VCN with DRG
├── VPN 1 (Primary)
└── VPN 2 (Secondary)

Routing:
- BGP for dynamic routing
- Primary path: CPE 1 → VPN 1
- Automatic failover to other tunnels
- Equal-cost multi-path (ECMP) for load balancing

Considerations:
+ Lower cost than FastConnect
+ Quick provisioning (hours, not weeks)
+ Built-in encryption (IPSec)
- Lower bandwidth (~250 Mbps per tunnel)
- Higher latency (internet-based)
- Subject to internet reliability

Objectives:
- Migrate VMware workloads to OCI
- Maintain VMware tools and processes
- Extend on-premises vSphere

Architecture:
On-Premises VMware:
├── vCenter
├── ESXi hosts
├── vMotion network
└── L2 extension to OCI (HCX)

OCI VMware Solution (OCVS):
├── VMware SDDC
│   ├── vCenter
│   ├── ESXi hosts on bare metal
│   ├── vSAN storage
│   └── NSX networking
├── Dedicated VCN
├── FastConnect or VPN to on-premises
└── L2 extension for vMotion

Migration:
- HCX for live vMotion to OCI
- No downtime for workloads
- Maintain IP addresses during migration
- Gradual migration approach

Considerations:
+ Familiar VMware tools and processes
+ Live migration with vMotion
+ Maintain IP addressing scheme
- Higher cost (dedicated bare metal)
- VMware licensing costs
- Requires VMware expertise

Objective: Centralize network services and route traffic between VCNs and on-premises

Hub VCN (Shared Services):
├── DRG (central routing point)
├── Network Firewall (inspection)
├── Bastion Service
├── VPN/FastConnect to on-premises
├── DNS Resolver
└── Shared services (monitoring, logging)

Spoke VCNs (Workloads):
├── Spoke 1: Production applications
├── Spoke 2: Development/test
├── Spoke 3: Analytics platform
└── Each spoke peers with hub via DRG

Routing:
Hub VCN:
- Route to spokes: via DRG
- Route to on-premises: via FastConnect/VPN
- Route from spoke to on-premises: via DRG → hub → FastConnect/VPN

Spoke VCNs:
- Route to hub: via DRG
- Route to other spokes: via DRG → hub → DRG
- Route to on-premises: via DRG → hub → FastConnect/VPN

Traffic Flow Examples:
1. Spoke 1 → Spoke 2:
   Spoke 1 → DRG → Hub → Firewall → DRG → Spoke 2

2. Spoke 1 → On-premises:
   Spoke 1 → DRG → Hub → FastConnect → On-premises

3. On-premises → Spoke 1:
   On-premises → FastConnect → Hub → Firewall → DRG → Spoke 1

Considerations:
+ Centralized security controls
+ Simplified routing management
+ Transitive routing between all VCNs
+ Single point for on-premises connectivity
- Hub becomes potential bottleneck
- Hub VCN downtime affects all spokes
- Additional latency for inter-spoke traffic

Objective: Provide private access to OCI services without internet

Architecture:
VCN 1 (Application):
├── Private subnet
├── App servers
├── Service Gateway → Object Storage
└── Service Gateway → Autonomous Database

VCN 2 (Database):
├── Private subnet
├── DB Systems
├── Service Gateway → Object Storage (backups)
└── No Internet Gateway (fully private)

VCN 3 (Analytics):
├── Private subnet
├── Data processing instances
├── Service Gateway → Object Storage (data lake)
└── Service Gateway → ADW

Benefits:
- No data egress charges for OCI service access
- No internet exposure
- Private IP addressing maintained
- High throughput to OCI services

Use Case Example - Application Backup:
1. App server writes backup to Object Storage
2. Traffic goes through Service Gateway (private)
3. No NAT Gateway or Internet Gateway needed
4. No data egress charges
5. Backup stored in Object Storage (cross-region replication)

Considerations:
+ No internet exposure
+ No data egress charges
+ High performance
- Limited to supported OCI services
- Regional service (not cross-region)

Objective: Unified DNS resolution across on-premises and OCI

Architecture:
On-Premises:
├── DNS Servers (Active Directory, BIND, etc.)
├── Forward zone: oci.company.com → OCI DNS
└── Conditional forwarders to OCI

OCI:
├── DNS Resolver (per VCN)
│   ├── Resolver Endpoint (private IP in VCN)
│   ├── Forwarding rules: company.com → on-premises DNS
│   └── Private views for internal zones
├── Private DNS Zones
│   ├── oci.company.com (internal OCI resources)
│   └── db.company.com (database endpoints)
└── Public DNS Zones
    └── api.company.com (public endpoints)

DNS Resolution Flow:
1. On-premises client queries db.oci.company.com
2. On-prem DNS forwards to OCI DNS Resolver
3. OCI DNS resolves from private view
4. Response returned to client

2. OCI instance queries user.company.com
2. OCI DNS Resolver forwards to on-premises DNS
3. On-prem DNS resolves from Active Directory
4. Response returned to instance

Considerations:
+ Unified namespace
+ Seamless resolution across environments
+ Private DNS for internal resources
- Requires FastConnect or VPN for forwarding
- Careful management of forwarding rules
- Monitor DNS resolver performance

Objective: Maximum performance and availability for enterprise databases

Architecture:
Exadata Cloud Service:
├── Exadata Infrastructure
│   ├── Database servers (compute)
│   ├── Storage servers (Exadata storage)
│   ├── InfiniBand network (high-speed)
│   └── RDMA for low latency
├── VM Cluster
│   ├── RAC database (2+ nodes)
│   ├── Automatic Storage Management (ASM)
│   └── Exadata Smart Scan
├── Data Guard (standby in another AD/region)
└── Backup to Object Storage

Performance Features:
- Smart Scan (offload processing to storage)
- Hybrid Columnar Compression
- Storage Indexes
- InfiniBand for ultra-low latency
- Flash cache for hot data

HA Configuration:
- RAC for high availability (active-active)
- Data Guard for disaster recovery (active-passive)
- Grid Infrastructure for automatic failover
- Online operations (patching, scaling)

Use Cases:
- ERP systems (Oracle E-Business Suite, SAP)
- Large data warehouses
- High-transaction OLTP systems
- Consolidation of multiple databases

Considerations:
+ Highest performance for Oracle databases
+ Built-in HA and DR capabilities
+ Engineered system (optimized hardware/software)
- Highest cost
- Requires Oracle Database expertise
- Minimum size commitment

Objective: Self-managing database with cross-region DR

Primary Region (us-phoenix-1):
├── Autonomous Database (ATP or ADW)
│   ├── Serverless or Dedicated
│   ├── Auto-scaling enabled
│   ├── Automatic backups (60-day retention)
│   └── Automatic patching
└── Autonomous Data Guard enabled

Standby Region (us-ashburn-1):
├── Autonomous Database Standby
│   ├── Synchronized with primary
│   ├── Automatic switchover/failover
│   └── Can be used for read-only queries (Active Data Guard)

Failover Scenarios:
Automatic Failover:
- Primary region becomes unavailable
- Automatic detection (< 2 minutes)
- Standby promoted to primary
- RTO: < 2 minutes, RPO: < 5 minutes

Planned Switchover:
- Maintenance or testing
- Zero data loss
- Coordinated role reversal
- RTO: < 2 minutes, RPO: 0

Considerations:
+ Fully managed (no DBA required)
+ Cross-region DR included
+ Automatic failover
+ Can read from standby
- Limited to Autonomous Database features
- Less control than DB Systems

Objective: Migrate on-premises database to OCI with minimal downtime

Source (On-Premises):
├── Oracle Database (11g, 12c, 19c, 21c)
├── GoldenGate for replication
└── Network connectivity to OCI

Target (OCI):
├── Autonomous Database, DB System, or Exadata
├── GoldenGate for replication
└── Database Migration Service (optional)

Migration Process:
Phase 1: Initial Load
1. Backup source database
2. Restore to OCI target (or use Data Pump)
3. Validate schema and objects

Phase 2: Replication
1. Configure GoldenGate on source
2. Configure GoldenGate on target
3. Start replication (capture + apply)
4. Monitor lag (keep < 1 minute)

Phase 3: Cutover
1. Announce maintenance window
2. Stop application writes to source
3. Wait for replication lag = 0
4. Switchover GoldenGate (reverse direction)
5. Point applications to OCI database
6. Resume operations (typically < 30 minutes downtime)

Phase 4: Validation and Monitoring
1. Validate application functionality
2. Monitor database performance
3. Keep GoldenGate running for rollback option
4. Decommission source after confidence period

Considerations:
+ Minimal downtime (minutes to hours)
+ Can roll back if issues occur
+ Supports most Oracle database versions
- Requires GoldenGate license
- Complex configuration
- Monitor replication lag carefully

Objective: Never trust, always verify - eliminate implicit trust

Architecture Layers:

1. Identity Layer:
├── Identity Domains (centralized IdP)
├── MFA for all users (mandatory)
├── Federation with corporate IdP (SAML 2.0)
├── Conditional access policies
└── Privileged access management

2. Network Layer:
├── Private subnets (default)
├── No Internet Gateways (unless required)
├── NSGs with least privilege rules
├── Network Firewall for inspection
└── Bastion Service (no direct SSH access)

3. Infrastructure Layer:
├── Security Zones (enforce compliance)
├── Cloud Guard (continuous monitoring)
├── Vulnerability Scanning (all instances)
├── Hardened images (CIS benchmarks)
└── Immutable infrastructure (IaC)

4. Data Layer:
├── Encryption at rest (customer-managed keys)
├── Encryption in transit (TLS 1.2+)
├── Vault for key and secret management
├── Regular key rotation
└── Database encryption (TDE)

5. Application Layer:
├── WAF (OWASP Top 10 protection)
├── API Gateway (rate limiting, authentication)
├── Application-level encryption
├── Security scanning (SAST/DAST)
└── Zero trust service mesh

6. Monitoring Layer:
├── Centralized logging (all resources)
├── Security Information and Event Management (SIEM)
├── Anomaly detection (machine learning)
├── Incident response automation
└── Regular security audits

Implementation:
- Default deny (explicit allow required)
- Least privilege access (IAM policies)
- Microsegmentation (NSGs per resource)
- Continuous verification (re-authentication)
- Assume breach (monitor for lateral movement)

Considerations:
+ Strongest security posture
+ Defense in depth
+ Compliance-ready
- Higher complexity
- More management overhead
- Potential for access issues if misconfigured

Objective: Segmented network with centralized inspection

Architecture:
Internet
    ↓
Public Subnet (DMZ - Untrusted):
├── Public Load Balancer
├── WAF (Web Application Firewall)
└── Bastion (jump host)
    ↓
Network Firewall Subnet:
├── OCI Network Firewall
│   ├── Intrusion detection/prevention
│   ├── URL filtering
│   ├── TLS inspection
│   └── Threat intelligence
    ↓
Application Subnet (Trusted):
├── Application servers
├── API Gateway
└── Private Load Balancer
    ↓
Database Subnet (Highly Trusted):
├── Databases (Autonomous, DB Systems)
├── Service Gateway (backups to Object Storage)
└── No external connectivity

Firewall Rules:
DMZ → Application: Allow HTTP/HTTPS (after inspection)
Application → Database: Allow DB port (1521, 3306, 5432)
Database → Internet: Deny all
Database → Service Gateway: Allow (backups)

Traffic Flow:
1. User → Internet → WAF → Public LB (DMZ)
2. Public LB → Network Firewall (inspection)
3. Network Firewall → App servers (if allowed)
4. App servers → Network Firewall (inspection)
5. Network Firewall → Database (if allowed)

Considerations:
+ Centralized security inspection
+ East-west traffic filtering
+ Threat detection and prevention
- Additional latency (inspection)
- Network Firewall costs
- Complex rule management

Objective: Protect sensitive data (PII, PHI, PCI)

Data Classification:
├── Public: No protection required
├── Internal: Access control only
├── Confidential: Encryption + access control
└── Restricted: Encryption + masking + auditing

Protection by Classification:

Public Data:
- Object Storage (standard tier)
- No encryption required (but enabled by default)
- Public read access (optional)

Internal Data:
- IAM policies (least privilege)
- Audit logging enabled
- Encryption at rest (Oracle-managed keys)

Confidential Data:
- Customer-managed encryption keys (Vault)
- Key rotation (automatic)
- Strict IAM policies
- Audit logging with alerts
- Encryption in transit (TLS 1.3)

Restricted Data (PII/PHI/PCI):
- Customer-managed encryption keys (Vault)
- Data masking (database-level)
- Tokenization (sensitive fields)
- Audit logging with real-time alerts
- Encryption in transit (mutual TLS)
- No export/download (policy-enforced)
- Data residency controls
- Security Zones (cannot disable encryption)

Example: Healthcare Application (HIPAA)
Database (PHI):
├── Transparent Data Encryption (TDE)
├── Customer-managed keys in Vault
├── Data masking for non-prod environments
├── Audit all access (Unified Auditing)
├── Redact SSN/DOB in logs
└── Private subnet (no internet access)

Application:
├── TLS 1.3 for all connections
├── OAuth 2.0 authentication
├── Role-based access control
├── Session timeout (15 minutes)
└── WAF (protect against attacks)

Monitoring:
├── Audit all database access
├── Alert on unusual patterns
├── Encrypt logs before archiving
└── Retain logs for 7 years (compliance)

Considerations:
+ Meets compliance requirements (HIPAA, GDPR, PCI-DSS)
+ Data protection in depth
+ Auditability for compliance
- Increased complexity
- Performance impact (encryption, masking)
- Careful key management required

Analysis Process:
1. Monitor utilization metrics (7-30 days)
   - CPU: CPUUtilization metric
   - Memory: MemoryUtilization metric
   - Network: NetworksBytesIn/Out
   - Disk: DiskBytesRead/Written

2. Identify over-provisioned instances:
   - CPU < 30% average utilization
   - Memory < 40% average utilization
   - Network < 20% of available bandwidth

3. Right-size recommendations:
   - High CPU, Low Memory → Compute-optimized shape
   - Low CPU, High Memory → Memory-optimized shape
   - Low CPU, Low Memory → Smaller standard shape
   - High CPU, High Memory → Larger standard shape or Flex

4. Test and validate:
   - Change shape during maintenance window
   - Monitor performance for 7 days
   - Rollback if performance degrades
   - Document savings

Example Savings:
Before: VM.Standard.E4.4 (4 OCPUs, 64 GB RAM) @ $0.32/hr
- Utilization: 25% CPU, 30% Memory
After: VM.Standard.E4.Flex (2 OCPUs, 32 GB RAM) @ $0.16/hr
- Savings: 50% ($117/month per instance)

Web Tier Autoscaling:
Instance Pool Configuration:
- Min instances: 2 (one per AD for HA)
- Max instances: 10 (capacity limit)
- Desired: Start with 2

Autoscaling Policy:
Scale-Out Rule:
- Metric: CPUUtilization > 70%
- Duration: 5 minutes (avoid thrashing)
- Action: Add 2 instances (one per AD)
- Cool-down: 5 minutes

Scale-In Rule:
- Metric: CPUUtilization < 30%
- Duration: 15 minutes (ensure sustained low load)
- Action: Remove 2 instances
- Cool-down: 10 minutes

Schedule-Based Scaling:
Business Hours (8 AM - 6 PM):
- Min instances: 4
- Max instances: 10

Off-Hours (6 PM - 8 AM):
- Min instances: 2
- Max instances: 6

Cost Impact:
Without autoscaling: 10 instances * 24 hours = 240 instance-hours/day
With autoscaling: ~120 instance-hours/day (50% savings)

Workload Analysis:
1. Measure IOPS and throughput requirements
2. Choose appropriate performance tier
3. Monitor actual vs. provisioned performance
4. Right-size volume performance

Example: Database Server
Requirements:
- IOPS: 50,000 sustained
- Throughput: 800 MB/s
- Volume size: 1 TB

Option 1: Ultra High Performance (225 IOPS/GB)
- Volume size: 1024 GB
- IOPS: 225 * 1024 = 230,400 (exceeds requirement ✓)
- Throughput: 2,680 KB/s * 1024 = 2,744 MB/s (exceeds ✓)
- Cost: $0.153/GB/month = $156.67/month

Option 2: Higher Performance (75 IOPS/GB)
- Need: 50,000 / 75 = 667 GB minimum
- Volume size: 1024 GB (for capacity)
- IOPS: 75 * 1024 = 76,800 (exceeds requirement ✓)
- Throughput: 600 KB/s * 1024 = 614 MB/s (below requirement ✗)

Recommendation: Ultra High Performance for this workload
Note: Can adjust tier later if requirements change

Use Case: Application Logs
Lifecycle Policy:
- Day 0-30: Standard tier (frequent access)
- Day 31-180: Infrequent Access tier (occasional access)
- Day 181-2555: Archive tier (compliance retention)
- Day 2556+: Delete (7-year retention complete)

Cost Analysis (1 TB logs/month):
Month 1: 1 TB * $0.0255 = $25.50 (Standard)
Month 2:
  - New logs: 1 TB * $0.0255 = $25.50 (Standard)
  - Old logs: 1 TB * $0.01 = $10.00 (Infrequent Access)
  - Total: $35.50

Steady State (after 7 months):
- Last 30 days: 1 TB * $0.0255 = $25.50 (Standard)
- Day 31-180: 5 TB * $0.01 = $50.00 (Infrequent Access)
- Day 181-2555: 79 TB * $0.0025 = $197.50 (Archive)
- Total: $273/month

Without Lifecycle: 85 TB * $0.0255 = $2,167.50/month
With Lifecycle: $273/month
Savings: 87% ($1,894.50/month)

Configuration:
Base: 2 OCPUs
Auto-scaling: Enabled (up to 3x = 6 OCPUs)
Scaling trigger: CPU > 80% for 1 minute

Cost Model:
Base: 2 OCPUs * 24 hours * 30 days = 1,440 OCPU-hours/month
  @ $0.395/hour = $568.80/month

With Auto-scaling:
Typical usage: 2 OCPUs for 20 hours/day = 1,200 OCPU-hours
Peak usage: 6 OCPUs for 4 hours/day = 720 OCPU-hours
Total: 1,920 OCPU-hours/month @ $0.395 = $758.40/month

Alternative: Fixed 6 OCPUs
6 OCPUs * 24 hours * 30 days = 4,320 OCPU-hours
  @ $0.395/hour = $1,706.40/month

Savings with Auto-scaling: $948/month (56% vs. fixed 6 OCPU)

Scenario: 10 small databases on separate VMs
Current:
- 10 VM DB Systems (2 OCPU each) = 20 OCPUs total
- Cost: 10 * $120/month = $1,200/month

Option 1: Consolidate on Autonomous Database Dedicated
- Autonomous Exadata Infrastructure (12 OCPUs)
- 10 Autonomous Databases on shared infrastructure
- Cost: $800/month (infrastructure) + $200/month (databases)
- Total: $1,000/month
- Savings: $200/month (17%)
- Benefits: Automated management, better resource utilization

Option 2: Consolidate on DB System with Multitenant
- DB System with 12 OCPUs
- 10 Pluggable Databases (PDBs) in 1 Container Database
- Cost: $600/month
- Savings: $600/month (50%)
- Note: Requires database administration expertise

Use Case: Hybrid application with frequent data transfer

VPN (Site-to-Site IPSec):
- Bandwidth: ~250 Mbps per tunnel (4 tunnels = 1 Gbps max)
- Latency: 15-30 ms (depends on internet path)
- Reliability: Subject to internet conditions
- Cost: $0.25/hour per VPN = $180/month (4 VPNs)

FastConnect (1 Gbps):
- Bandwidth: 1 Gbps dedicated
- Latency: 5-10 ms (dedicated path)
- Reliability: 99.9% SLA
- Cost: $285/month (port) + provider fees (~$200) = $485/month

Decision Factors:
Data Transfer: 5 TB/month from on-premises to OCI

VPN Total Cost:
- VPN: $180/month
- Data transfer: 5 TB * $0 = $0 (inbound is free)
- Total: $180/month
- Transfer time: 5 TB @ 500 Mbps average = ~22 hours

FastConnect Total Cost:
- FastConnect: $485/month
- Data transfer: 5 TB * $0 = $0 (inbound is free)
- Total: $485/month
- Transfer time: 5 TB @ 1 Gbps = ~11 hours

Recommendation:
- VPN: For low bandwidth, intermittent use
- FastConnect: For high bandwidth, low latency, consistent use
- Break-even: ~10 TB/month or latency-sensitive applications

Scenario: Web application with variable traffic

Current: Flexible Load Balancer @ 100 Mbps
- Average usage: 30 Mbps
- Peak usage: 80 Mbps
- Cost: 100 Mbps * $0.007/Mbps/hour * 730 hours = $511/month

Optimization: Reduce to 100 Mbps, use autoscaling for backend
- Provision: 50 Mbps (covers typical usage)
- Burst: Up to 100 Mbps (OCI allows temporary bursts)
- Cost: 50 Mbps * $0.007/Mbps/hour * 730 hours = $255.50/month
- Savings: $255.50/month (50%)

Additional Optimization: Session persistence
- Enable cookie-based persistence (sticky sessions)
- Reduces backend server load (session reuse)
- Improves response time (no session re-creation)
- Cost: Included (no additional charge)

Approach: Move applications to OCI without changes
Best For: Quick migrations, legacy applications
Tools: OCI Migration Service, Rackware, third-party

Steps:
1. Discover and assess current environment
2. Create target VCN and subnets
3. Replicate VMs to OCI (live or offline)
4. Cutover (change network routing)
5. Validate and optimize post-migration

Example: Physical servers → OCI Compute instances
Timeline: 2-4 weeks (per application)
Downtime: Minutes to hours (depends on cutover method)

Approach: Minor optimizations during migration
Best For: Modernizing infrastructure without code changes
Changes: Update OS, change instance types, use managed services

Steps:
1. Identify optimization opportunities
2. Migrate to OCI with updates (e.g., newer OS version)
3. Replace components with OCI services (e.g., RDS → Autonomous DB)
4. Cutover and validate

Example:
- Source: Windows Server 2012, SQL Server 2014
- Target: Windows Server 2022, Autonomous Database
Timeline: 4-8 weeks
Downtime: Hours (for database migration)

Approach: Replace with SaaS or different product
Best For: End-of-life software, outdated applications
Changes: Complete product replacement

Example:
- Source: On-premises email server (Exchange)
- Target: Oracle Email Delivery + third-party SaaS
Timeline: Varies by product
Downtime: Depends on cutover strategy

Approach: Redesign application for cloud-native features
Best For: Modernization, scalability, performance
Changes: Rewrite application, adopt microservices, use PaaS

Example:
- Source: Monolithic Java application on VMs
- Target: Microservices on OKE, serverless functions, API Gateway
Timeline: 3-12 months (significant effort)
Benefits: Scalability, resilience, cost optimization

Approach: Decommission applications no longer needed
Best For: Redundant or obsolete applications
Action: Document, archive data, shut down

Example: Multiple legacy reporting tools → consolidate to one
Timeline: 1-2 weeks (per application)
Savings: Eliminate licensing, infrastructure, maintenance costs

Approach: Keep applications on-premises
Best For: Applications not ready for migration, compliance requirements
Action: Continue operating in current environment, plan for future migration

Example: Applications with hardware dependencies, mainframe systems
Timeline: N/A (not migrating)

Best For: Smaller databases (<1 TB), acceptable downtime

Steps:
1. On-premises: Full backup using RMAN or Data Pump
2. Transfer backup to OCI Object Storage (rclone, rsync)
3. Restore to OCI database (RMAN or Data Pump import)
4. Validate data and application connectivity
5. Cutover (update connection strings)

Downtime: Hours to days (depends on database size)
Tools: RMAN, Data Pump, Object Storage
Cost: Minimal (storage costs only)

Example: 500 GB database
- Backup: 2 hours
- Transfer: 4 hours (@ 300 Mbps)
- Restore: 3 hours
- Validation: 1 hour
- Total downtime: 10 hours

Best For: Large databases, minimal downtime required

Architecture:
1. Source database (on-premises)
2. GoldenGate capture process (on-premises)
3. GoldenGate trail files → OCI
4. GoldenGate apply process (OCI)
5. Target database (OCI)

Steps:
1. Initial load: Backup/restore or Data Pump
2. Configure GoldenGate replication
3. Monitor replication lag (keep < 1 minute)
4. Cutover: Stop source, sync target, switchover
5. Validate and monitor

Downtime: Minutes to hours (cutover only)
Tools: Oracle GoldenGate, ZDM service
Cost: GoldenGate license, compute for GoldenGate instances

Example: 5 TB database
- Initial load: 24 hours (offline)
- Replication: Running continuously (lag < 1 min)
- Cutover: 30 minutes
- Total application downtime: 30 minutes

Best For: Simplified migrations, built-in validation

Features:
- Logical migration (Data Pump-based)
- Schema conversion (some databases)
- Validation and comparison
- Automated process

Steps:
1. Create migration in DMS console
2. Validate source and target connectivity
3. Run migration (schema, data)
4. Validate with built-in tools
5. Cutover

Supported Sources:
- On-premises Oracle Database
- MySQL, PostgreSQL (with conversion)
- RDS Oracle, RDS MySQL, RDS PostgreSQL

Downtime: Hours (depends on size)
Tools: DMS (fully managed service)
Cost: DMS service (pay per use)

Example Structure:
"A company is migrating their on-premises Oracle database to OCI.
Requirements:
- Minimize downtime (< 1 hour)
- Database size: 10 TB
- Compliance: Data must not traverse the internet
- High availability in OCI

What is the recommended migration approach?"

Analysis Process:
1. Identify requirements:
   - Minimize downtime → Zero Downtime Migration (GoldenGate)
   - Large database → Not backup/restore (too slow)
   - No internet → FastConnect or dedicated network
   - High availability → Multi-AD, Data Guard

2. Eliminate wrong answers:
   - Backup/restore: Too much downtime ✗
   - DMS over internet: Data traverses internet ✗
   - Single-AD deployment: Not HA ✗

3. Choose best answer:
   - ZDM with GoldenGate over FastConnect, target multi-AD with Data Guard ✓

Example:
"Which load balancer type should be used for a UDP-based application
requiring < 1ms latency and million requests per second?"

Analysis:
- UDP protocol → Layer 4 (not Layer 7)
- Ultra-low latency → Network Load Balancer
- High throughput → Network Load Balancer

Answer: Network Load Balancer
Why: Load Balancer (Layer 7) is HTTP/HTTPS only, Network Load Balancer
handles TCP/UDP with ultra-low latency

Example:
"Instances in a private subnet cannot reach the internet for software updates.
Internet Gateway and route rules are configured. What is the issue?"

Analysis:
- Private subnet → Should use NAT Gateway (not Internet Gateway)
- Internet Gateway → For public subnets only
- Route rule to IGW from private subnet → Wrong gateway type

Answer: Replace Internet Gateway with NAT Gateway in route rule

Example:
"What is the recommended approach for managing encryption keys for
sensitive data in OCI?"

Options:
A. Use Oracle-managed encryption keys (default)
B. Use customer-managed keys in Vault
C. Store keys in Object Storage
D. Use application-level key management

Analysis:
- Sensitive data → Customer control required
- Oracle-managed keys → No customer control ✗
- Object Storage → Not designed for key storage ✗
- Application-level → More complex, not recommended ✗
- Vault with customer-managed keys → Best practice ✓

Answer: B (Use customer-managed keys in Vault)

Trap: Choosing the most complex or expensive solution
Reality: Choose simplest solution that meets requirements

Example:
Question: "Design HA architecture for web application in single region"
Wrong: Multi-region active-active with Traffic Manager
Right: Multi-AD deployment with load balancer

Key: Read requirements carefully - single region requirement

Trap: Ignoring specific constraints in question
Reality: All requirements must be satisfied

Example:
Question: "Design most cost-effective solution with RTO < 1 hour"
Wrong: Active-active multi-region (meets RTO but not cost-effective)
Right: Pilot light DR (meets both RTO and cost requirements)

Key: Identify ALL requirements (cost, performance, availability, etc.)

Trap: Mixing up similar services or features
Reality: Know exact differences

Common Confusions:
- Security Lists vs NSGs
  → Security Lists: Subnet-level, allow/deny rules
  → NSGs: Resource-level, allow-only rules

- Load Balancer vs Network Load Balancer
  → Load Balancer: Layer 7 (HTTP/HTTPS), SSL termination
  → Network Load Balancer: Layer 4 (TCP/UDP), preserve client IP

- Autonomous DB Serverless vs Dedicated
  → Serverless: Shared infrastructure, pay-per-use
  → Dedicated: Isolated infrastructure, dedicated capacity

Trap: Assuming optional features are enabled by default
Reality: Know what's enabled by default, what requires configuration

Examples:
- Default: Encryption at rest (Oracle-managed keys)
- Requires config: Customer-managed keys
- Default: No public access (private resources)
- Requires config: Internet Gateway for public access
- Default: Security list allows no traffic
- Requires config: Add allow rules for specific traffic