Tác giả: Jobin Joseph, Jeremy Shearer, và Julien Silverston
Ngày phát hành: 24 FEB 2026
Chuyên mục: Database, Expert (400), Oracle Database@AWS, Technical How-to

Oracle Database@AWS cung cấp các khả năng cơ sở dữ liệu cấp doanh nghiệp thông qua các dịch vụ cơ sở dữ liệu sử dụng hạ tầng Oracle Exadata được quản lý bởi Oracle Cloud Infrastructure (OCI) trong các trung tâm dữ liệu của Amazon Web Services (AWS). Bạn có thể sử dụng Oracle Database@AWS để di chuyển các khối lượng công việc Oracle Exadata của mình sang AWS trong khi vẫn duy trì hiệu suất và các tính năng tương tự như các triển khai Oracle Exadata tại chỗ của bạn. Bạn có thể hưởng lợi từ việc giảm độ trễ ứng dụng bằng cách thiết lập kết nối độ trễ thấp giữa Oracle Exadata và các ứng dụng của bạn chạy trên AWS. Ngoài ra, bạn có thể tích hợp Oracle Database@AWS với các dịch vụ AWS khác để có nhiều khả năng khác nhau, bao gồm khả năng quan sát (observability), phân tích, trí tuệ nhân tạo và học máy (AI/ML), và xây dựng các ứng dụng AI tạo sinh. Bằng cách cung cấp quản lý tự động, hiệu suất tối ưu và các tính năng bảo mật tích hợp trên nhiều Availability Zone, Oracle Database@AWS giúp bạn giảm chi phí vận hành trong khi vẫn duy trì mức độ tin cậy và hiệu suất cơ sở dữ liệu cao nhất.

Các tùy chọn High Availability (HA) và Disaster Recovery (DR) là những khía cạnh quan trọng cần xem xét khi di chuyển hoặc triển khai cơ sở dữ liệu quan trọng của bạn trong Oracle Database@AWS để đảm bảo kiến trúc có thể đáp ứng thỏa thuận mức dịch vụ (SLA) của ứng dụng. Khi cơ sở dữ liệu của bạn gặp thời gian ngừng hoạt động—cho dù do lỗi phần cứng, sự cố ngừng hoạt động của Region, hay các gián đoạn khác—bạn có thể phải đối mặt với tổn thất doanh thu đáng kể, mối quan hệ khách hàng bị tổn hại và các vi phạm tuân thủ tiềm ẩn, khiến các giải pháp khả năng sẵn sàng mạnh mẽ trở nên thiết yếu cho doanh nghiệp của bạn. Để giải quyết những thách thức này, bạn có thể triển khai các chiến lược bảo vệ toàn diện bằng cách sử dụng phương pháp tiếp cận đa lớp của Oracle Database@AWS để đạt được khả năng phục hồi. Bằng cách sử dụng Oracle Data Guard với cả cấu hình cross-AZ cho HA và thiết lập cross-Region cho DR, bạn có thể tạo ra khả năng bảo vệ chuyên sâu trải dài từ các lỗi phần cứng cục bộ đến các sự cố ngừng hoạt động trên toàn AWS Region.

Bài viết này sẽ giúp bạn triển khai và duy trì các cấu hình Data Guard tuân theo các phương pháp hay nhất của Kiến trúc khả năng sẵn sàng tối đa (MAA) của Oracle và AWS Well-Architected Framework. Chúng tôi sẽ chỉ ra cách chọn kiến trúc mạng phù hợp và cấu hình các liên kết Data Guard cho cả triển khai cross-AZ và cross-Region, đảm bảo các ứng dụng của bạn duy trì kết nối liền mạch trong quá trình chuyển đổi vai trò.

HA và DR cho Oracle Database@AWS với Data Guard

Các dịch vụ Exadata Database Service on Dedicated Infrastructure (ExaDB-D) và Autonomous Database Dedicated (ADB-D) được cung cấp trong Oracle Database@AWS mang lại trải nghiệm được quản lý để tạo và duy trì các cấu hình Data Guard. Bạn có thể sử dụng OCI console hoặc giao diện dòng lệnh (CLI) để xây dựng các cấu hình Data Guard giữa các site primary và standby sau khi kết nối cần thiết được thiết lập giữa các cụm máy ảo (VM) primary và standby. Sơ đồ sau đây cho thấy kiến trúc tham chiếu của cấu hình HA/DR cho ExaDB-D sử dụng liên kết Data Guard giữa hai Availability Zone trong cùng một Region và giữa các Region.

Bảng sau đây cho thấy sự so sánh các tính năng liên kết Data Guard có sẵn cho các dịch vụ ExaDB-D và ADB-D.

Tính năng	ExaDB-D	ADB-D
Trải nghiệm được quản lý để tạo và quản lý Data Guard	Có	Có
Tự động chuyển đổi dự phòng cho triển khai cross-AZ	Có: Data Guard Observer (FSFO) do khách hàng quản lý	Có
Tự động chuyển đổi dự phòng cho triển khai cross-Region	Có: Data Guard Observer (FSFO) do khách hàng quản lý	Có
Số lượng cơ sở dữ liệu standby được hỗ trợ (bao gồm cục bộ và từ xa)	6	2
Cấu hình khuyến nghị	Khả năng sẵn sàng tối đa cho cross-AZ và hiệu suất tối đa cho cross-Region	Khả năng sẵn sàng tối đa cho cross-AZ và hiệu suất tối đa cho cross-Region

Để thiết lập kết nối mạng cho liên kết Data Guard, bạn có thể chọn từ hai tùy chọn:

• Sử dụng AWS Transit Gateway để kết nối hai mạng ODB trong hai Availability Zone hoặc hai Region.
• Thiết lập peering ở cấp độ Virtual Cloud Network (VCN) của OCI bằng cách sử dụng các local peering gateway cho triển khai cross-AZ hoặc sử dụng remote VCN peering và một dynamic routing gateway (DRG) cho triển khai Data Guard cross-Region.

Trong các phần sau, chúng tôi sẽ đi sâu vào chi tiết mạng, lợi ích và ý nghĩa chi phí của các tùy chọn kết nối khác nhau cho liên kết Data Guard cho Oracle Database@AWS.

Triển khai Cross-AZ trong cùng một Region

Nền tảng của một kiến trúc cơ sở dữ liệu có khả năng phục hồi trên AWS bắt đầu bằng việc bảo vệ các cơ sở dữ liệu quan trọng khỏi các gián đoạn của Availability Zone primary. Hãy cùng khám phá các tùy chọn mạng cho triển khai Data Guard cross-AZ có sẵn cho cả dịch vụ ExaDB-D và ADB-D.

Sử dụng Transit Gateway để kết nối hai mạng ODB cho kết nối Data Guard

Bạn có thể định tuyến lưu lượng giữa hai mạng ODB trong hai Availability Zone trong một Region trong mạng AWS bằng cách sử dụng Transit Gateway. Sơ đồ sau đây cho thấy chi tiết cấu hình giữa hai cụm Exadata VM được lưu trữ trong hai Availability Zone (az1 và az2) và các mạng ODB sử dụng một transit gateway với các kết nối được định tuyến qua một transit virtual private cloud (VPC) được peered với mỗi mạng ODB.

Trong ví dụ này, b.b.b.b/b là dải CIDR của client subnet cho mạng ODB trong az1, a.a.a.a/a là dải CIDR cho transit VPC được peered với mạng ODB trong az1, y.y.y.y/y là dải CIDR của client subnet cho mạng ODB trong az2, và x.x.x.x/x là dải CIDR cho transit VPC được ODB peered với mạng ODB trong az2.

Mạng	CIDR
Primary transit VPC	a.a.a.a/a
Primary ODB network client subnet	b.b.b.b/b
Standby transit VPC	x.x.x.x/x
Standby ODB network client subnet	y.y.y.y/y

Tham khảo ODB peering để tìm hiểu về kiến trúc mạng của Oracle Database@AWS và khái niệm ODB peering.

Sơ đồ sau đây minh họa cách thiết lập kết nối cho lưu lượng Data Guard bằng cách sử dụng Transit Gateway giữa hai Availability Zone trong một Region.

Để triển khai kiến trúc này, bạn phải làm theo các bước sau:

1. Peering transit VPC1 (với CIDR a.a.a.a/a) với ODBNetwork-az1 (với client CIDR b.b.b.b/b) và transit VPC2 (với CIDR x.x.x.x/x) với ODBNetwork-az2 (với client CIDR y.y.y.y/y) bằng cách sử dụng phương pháp ODB peering.
2. Cung cấp một transit gateway hoặc sử dụng một transit gateway hiện có và gắn nó vào cả transit VPC1 và transit VPC2 vào các subnet được ánh xạ tới Availability Zone nơi mạng ODB được triển khai. Việc gắn Transit Gateway vào các transit VPC chỉ nên bao gồm các subnet được ánh xạ tới Availability Zone nơi mạng ODB được cung cấp.
3. Sửa đổi bảng định tuyến cho transit VPC1 (được sử dụng bởi subnet cho Transit Gateway attachment) để định tuyến lưu lượng nhắm mục tiêu đến transit VPC2 CIDR (x.x.x.x/x) và ODBNetwork-az2 CIDR (y.y.y.y/y) thông qua Transit Gateway attachment của nó.
4. Sửa đổi bảng định tuyến cho transit VPC2 (được sử dụng bởi subnet cho Transit Gateway attachment) để định tuyến lưu lượng nhắm mục tiêu đến transit VPC1 CIDR (a.a.a.a/a) và ODBNetwork-az1 CIDR (b.b.b.b/b) thông qua Transit Gateway attachment của nó.
5. Các tuyến từ các bảng định tuyến được gắn vào các subnet đó sẽ tự động được điền vào bảng định tuyến của Transit Gateway.
6. Thêm hai tuyến tĩnh trên Transit Gateway cho các client CIDR của mạng ODB tại cả hai Availability Zone không được kết nối trực tiếp với Transit Gateway. Tuyến tĩnh cho các CIDR b.b.b.b/b và y.y.y.y/y phải được trỏ đến Transit Gateway attachment tương ứng của transit VPC.
7. Sửa đổi các kết nối ODB peering để thêm các dải CIDR được peered cho mạng ODB khác và transit VPC của nó:
   a. Sửa đổi kết nối ODB peering cho ODBNetwork-az1 để thêm x.x.x.x/x và y.y.y.y/y vào danh sách CIDR được peered của nó.
   b. Sửa đổi kết nối ODB peering cho ODBNetwork-az2 để thêm a.a.a.a/a và b.b.b.b/b vào danh sách CIDR được peered của nó. Bằng cách sửa đổi danh sách CIDR được peered của kết nối ODB peering, nhóm bảo mật mạng của OCI VCN tương ứng sẽ tự động được cập nhật để cho phép lưu lượng cần thiết. Bạn có thể xem xét các quy tắc nhóm bảo mật mạng để xác minh kết nối trên cổng listener cơ sở dữ liệu, SSH (22) và ICMP.
8. Kiểm tra kết nối để xác nhận giải pháp được triển khai đúng cách.

Nếu bạn đang sử dụng AWS Cloud WAN để quản lý kết nối toàn cầu, bạn có thể sử dụng tương tự cho lưu lượng Data Guard, như đã thảo luận trong bài viết Kết nối AWS Cloud WAN với Oracle Database@AWS (ODB@AWS).

Sử dụng local peering gateway với OCI VCN cho kết nối Data Guard

Tùy chọn thứ hai để thiết lập kết nối giữa các cụm VM là định tuyến lưu lượng giữa hai OCI VCN được liên kết với các mạng ODB bằng cách sử dụng các local peering gateway.

Trong sơ đồ sau, ODBNetwork-az1 là tên của mạng ODB trong AZ1 với client CIDR b.b.b.b/b và ODBNetwork-az2 là tên của mạng ODB trong AZ2 với client CIDR y.y.y.y/y.

Để triển khai kết nối bằng cách peering OCI VCN, bạn phải làm theo các bước sau:

1. Xác định các OCI VCN được liên kết với các mạng ODB từ OCI console và ghi lại các dải CIDR cho các mạng client.
2. Thêm một local peering gateway vào mỗi VCN.
3. Peering hai local peering gateway.
4. Sửa đổi bảng định tuyến mặc định của OCI VCN tương ứng với ODBNetwork-az1 để định tuyến lưu lượng cho CIDR của ODBNetwork-az2 thông qua local peering gateway.
5. Sửa đổi bảng định tuyến mặc định của OCI VCN tương ứng với ODBNetwork-az2 để định tuyến lưu lượng cho CIDR của ODBNetwork-az1 thông qua local peering gateway.
6. Sửa đổi nhóm bảo mật mạng (nhóm có tên có thể điều chỉnh) cho mỗi OCI VCN để cho phép lưu lượng từ client CIDR của mạng ODB khác.
7. Kiểm tra kết nối để xác nhận giải pháp được triển khai đúng cách.

Tham khảo Về việc triển khai Disaster Recovery với Cross-Zone Data Guard trên Oracle Database@AWS để biết thêm chi tiết về cấu hình này.

So sánh các tùy chọn kết nối cho liên kết Data Guard cross-AZ

Bảng sau đây so sánh hai tùy chọn để định tuyến lưu lượng Data Guard giữa các Availability Zone bằng cách sử dụng Transit Gateway và OCI VCN peering.

Tính năng	Transit Gateway	OCI VCN peering
Cô lập lưu lượng	Mạng AWS	Mạng OCI
Độ trễ	Độ trễ thấp một chữ số mili giây	Độ trễ thấp một chữ số mili giây
Chi phí	Phí Transit Gateway và phí cross-AZ	Không có phí truyền dữ liệu
Yêu cầu về lưu trú dữ liệu và tuân thủ	Đáp ứng yêu cầu nếu lưu lượng phải nằm trong mạng AWS	Không đáp ứng yêu cầu về lưu trú dữ liệu vì dữ liệu được lưu trữ vật lý trong AWS và lưu lượng Data Guard được định tuyến qua mạng OCI
Quyền sở hữu để khắc phục sự cố	AWS	OCI

ExaDB-D không tự động cấu hình Data Guard Observer cho chuyển đổi dự phòng tự động khi thêm liên kết Data Guard. Tuy nhiên, bạn có thể xây dựng cấu hình observer theo cách thủ công. Nên lưu trữ phiên bản Data Guard Observer trên mạng AWS nơi ngăn xếp ứng dụng của bạn chủ yếu cư trú để kích hoạt chuyển đổi dự phòng khi kết nối ứng dụng với cơ sở dữ liệu bị ảnh hưởng. Sơ đồ sau đây cho thấy kiến trúc tham chiếu của liên kết Data Guard trên hai Availability Zone với cấu hình observer được triển khai trong Availability Zone thứ ba cho Fast-Start Failover (FSFO). Đối với ADB-D, bạn có thể bật chuyển đổi dự phòng tự động cho các triển khai cross-AZ mà không cần phải cấu hình thủ công một tiến trình observer.

Khôi phục sau thảm họa Cross-Region bằng cách sử dụng liên kết Data Guard

Sau khi bạn thiết lập cấu hình HA của mình trên các Availability Zone, bước tiếp theo là triển khai bảo vệ DR. Nếu các yêu cầu DR của bạn vượt quá những gì triển khai cross-AZ có thể cung cấp, hãy triển khai Data Guard trên các Region. Hãy cùng xem xét các tùy chọn kết nối có sẵn và so sánh hiệu quả của chúng cho các triển khai Data Guard cross-Region.

Sử dụng Transit Gateway để kết nối hai mạng ODB giữa các Region

Bạn có thể định tuyến lưu lượng giữa hai mạng ODB trong hai Region trong mạng AWS bằng cách sử dụng cấu hình Transit Gateway, như được hiển thị trong sơ đồ sau.

Các bước cấp cao cho cấu hình này bao gồm:

1. Cung cấp hai transit gateway, một cho mỗi Region. Bạn cũng có thể sử dụng các transit gateway hiện có.
2. Gắn các transit gateway vào ODB peered VPC trong mỗi Region vào subnet được ánh xạ tới Availability Zone nơi mạng ODB tồn tại.
3. Tạo một peering attachment và chấp nhận yêu cầu peering để thiết lập kết nối giữa các transit gateway, như đã thảo luận trong Transit gateway peering attachments trong AWS Transit Gateway.
4. Cập nhật các quy tắc định tuyến theo hướng dẫn đã đề cập trước đó cho cấu hình transit gateway cho lưu lượng cross-AZ.
5. Cập nhật danh sách CIDR được peered của mạng ODB để cho phép lưu lượng từ mạng ODB từ xa bằng cách sửa đổi cấu hình mạng ODB.
6. Kiểm tra kết nối để xác nhận giải pháp được triển khai đúng cách.

Nếu bạn đang sử dụng Cloud WAN để quản lý kết nối toàn cầu, bạn có thể sử dụng quy trình tương tự cho lưu lượng Data Guard, như đã thảo luận trong bài viết Kết nối AWS Cloud WAN với Oracle Database@AWS (ODB@AWS).

Sử dụng remote VCN peering với OCI VCN

Tùy chọn thứ hai là peering các OCI VCN backend để thiết lập kết nối cho cấu hình Data Guard cross-Region cần thêm các HUB VCN được cấu hình ở mỗi bên. Điều này là do một OCI VCN chỉ có thể được gắn vào một DRG, và VCN được ánh xạ tới mạng ODB đã được gắn vào một DRG để tích hợp mạng AWS-OCI. Do đó, chúng tôi giới thiệu một HUB VCN và thiết lập kết nối local peering gateway giữa OCI VCN của mạng ODB và HUB VCN, sau đó bạn có thể gắn nó vào một DRG để kết nối cross-Region, như được hiển thị trong sơ đồ sau.

Để biết các bước cấu hình chi tiết, hãy tham khảo Về việc triển khai Disaster Recovery với Active Data Guard Cross-Regional trên Oracle Database@AWS.

So sánh các tùy chọn kết nối cho liên kết Data Guard cross-Region

Bảng sau đây so sánh các tùy chọn kết nối cho lưu lượng Data Guard giữa các Region bằng cách sử dụng Transit Gateway và OCI VCN peering.

Tính năng	Transit Gateway	OCI VCN peering
Cô lập lưu lượng	Mạng AWS	Mạng OCI
Độ trễ	Mili giây	Mili giây
Chi phí	Phí Transit Gateway và phí truyền dữ liệu cross-Region	Phí truyền dữ liệu cross-Region
Yêu cầu về lưu trú dữ liệu và tuân thủ	Đáp ứng yêu cầu nếu lưu lượng phải nằm trong mạng AWS	Không đáp ứng yêu cầu về lưu trú dữ liệu vì dữ liệu được lưu trữ vật lý trong AWS và lưu lượng Data Guard được định tuyến qua mạng OCI
Quyền sở hữu để khắc phục sự cố	AWS	OCI

Cấu hình liên kết Data Guard cho ExaDB-D và ADB-D

Cả ExaDB-D và ADB-D đều cung cấp trải nghiệm được quản lý để thiết lập liên kết Data Guard bằng cách sử dụng console hoặc API và CLI mà không cần phải thực hiện thủ công các bước sao lưu, khôi phục và cấu hình Data Guard. Đối với ExaDB-D, hãy hoàn thành các bước sau:

1. Đăng nhập vào OCI tenancy của bạn bằng OCI console.
2. Chọn Oracle Exadata Database Service on Dedicated Infrastructure trong phần Oracle AI Database.
3. Chọn VMC của bạn cho cơ sở dữ liệu primary.
4. Chọn cơ sở dữ liệu primary.
5. Chọn Data Guard associations.
6. Cấu hình bằng cách sử dụng tùy chọn thêm standby bằng cách chọn AD, hạ tầng và VMC mục tiêu phù hợp cho phiên bản standby.
7. Kiểm tra switchover sau khi quá trình xây dựng hoàn tất.

Đối với ADB-D, hãy hoàn thành các bước sau:

1. Đăng nhập vào OCI tenancy của bạn bằng OCI console.
2. Chọn Autonomous Database on Dedicated Infrastructure trong phần Oracle AI Database.
3. Chọn Autonomous Container Database (ACD) của bạn.
4. Chọn Data guard associations.
5. Cấu hình bằng cách sử dụng tùy chọn thêm standby bằng cách chọn AD, hạ tầng và AVMC mục tiêu phù hợp cho standby.
6. Kiểm tra switchover sau khi quá trình xây dựng hoàn tất.

Kết nối ứng dụng cho Data Guard failover và switchover cross-AZ

Kết nối ứng dụng với cơ sở dữ liệu đòi hỏi sự cân nhắc kỹ lưỡng khi lập kế hoạch các kịch bản Data Guard switchover và failover cho cả ADB-D và ExaDB-D. Trong phần này, chúng tôi thảo luận về các mô hình được thiết kế tốt và khuyến nghị cho kết nối từ ngăn xếp ứng dụng đến cơ sở dữ liệu để cho phép các ứng dụng thiết lập kết nối minh bạch với cơ sở dữ liệu trên các kịch bản chuyển đổi vai trò mà không cần cấu hình lại bằng cách sử dụng các cấu hình TNS phù hợp.

Trong hầu hết các trường hợp, khách hàng triển khai ngăn xếp ứng dụng của họ trong một VPC trên các subnet được ánh xạ tới các Availability Zone khác nhau để đạt được khả năng sẵn sàng cao. Bởi vì một VPC có thể được peered đồng thời với các mạng ODB trong Availability Zone primary và Availability Zone standby, các ứng dụng chạy trong VPC đó có thể tạo điều kiện kết nối minh bạch với cơ sở dữ liệu trên các kịch bản Data Guard switchover và failover, như được hiển thị trong sơ đồ sau.

Nếu ứng dụng của bạn được kết nối với cơ sở dữ liệu trong mạng ODB qua một transit gateway, bạn có thể gắn các transit VPC được peered với các mạng ODB trong Availability Zone primary và standby vào transit gateway để thiết lập kết nối minh bạch trên các kịch bản switchover và failover. Như minh họa trong sơ đồ sau, các ứng dụng kết nối qua transit gateway đến mạng ODB, và ODB peered VPC chỉ đóng vai trò là một đường dẫn trung chuyển.

Trong kiến trúc này, transit VPC không lưu trữ các thành phần ứng dụng, và các ứng dụng sử dụng Transit Gateway để kết nối với lớp cơ sở dữ liệu.

Kết luận

Trong bài viết này, chúng tôi đã chỉ ra cách sử dụng Data Guard để đáp ứng các yêu cầu HA và DR cho các cơ sở dữ liệu quan trọng của bạn chạy trong Oracle Database@AWS, thảo luận về các tùy chọn kết nối để định tuyến lưu lượng Data Guard và chia sẻ các phương pháp hay nhất cho kết nối ứng dụng với cơ sở dữ liệu. Bằng cách triển khai cẩn thận nhiều lớp bảo vệ—chẳng hạn như khả năng phục hồi cấp rack của RAC, sao chép Data Guard Multi-AZ và khôi phục sau thảm họa cross-Region—bạn có thể đạt được mức độ bảo vệ và khả năng sẵn sàng mong muốn cho các cơ sở dữ liệu của mình được triển khai trong Oracle Database@AWS. Hãy bắt đầu hành trình hướng tới khả năng phục hồi cơ sở dữ liệu toàn diện ngay hôm nay bằng cách đánh giá các yêu cầu khả năng sẵn sàng hiện tại của bạn, chọn các cấu hình Data Guard phù hợp và triển khai kiến trúc mạng hỗ trợ tốt nhất nhu cầu kinh doanh của bạn. Các bước cấu hình chi tiết và các mẫu kiến trúc trong bài viết này có thể giúp bạn xây dựng và duy trì một môi trường Oracle Database@AWS mạnh mẽ, cung cấp tính liên tục trong kinh doanh cho các ứng dụng của bạn.

Tham khảo Hướng dẫn sử dụng Oracle Database@AWS để tìm hiểu thêm về các tính năng và khả năng của Oracle Database@AWS.

---

Về tác giả

Jobin Joseph
Jobin là Kiến trúc sư giải pháp chuyên gia cơ sở dữ liệu cấp cao có trụ sở tại Toronto. Với trọng tâm là các công cụ cơ sở dữ liệu quan hệ, anh ấy hỗ trợ khách hàng di chuyển và hiện đại hóa khối lượng công việc cơ sở dữ liệu của họ sang AWS. Anh ấy là một Oracle Certified Master với hơn 25 năm kinh nghiệm với các cơ sở dữ liệu Oracle.

Julien Silverston
Julien là kiến trúc sư giải pháp chính trong nhóm đa đám mây của Oracle Cloud Infrastructure với 25 năm kinh nghiệm. Julien có kinh nghiệm với các giải pháp đa đám mây, đám mây lai và dựa trên đám mây. Anh ấy là một kiến trúc sư giải pháp được chứng nhận của Oracle Cloud Infrastructure.

Jeremy Shearer
Jeremy là Kiến trúc sư giải pháp đối tác chính tại AWS có trụ sở tại Houston, tập trung độc quyền vào Liên minh Oracle. Với gần ba thập kỷ kinh nghiệm về Oracle, anh ấy chuyên cài đặt, cấu hình, quản lý và di chuyển các hệ thống ERP doanh nghiệp của Oracle, đặc biệt là JD Edwards.