by Art Baudo on 31 MAR 2025 in Amazon EC2, AWS Outposts, AWS Outposts rack, AWS Outposts servers, Compute Permalink  Share

Bài viết này được viết bởi Perry Wald, Principal GTM SA, Hybrid Edge, Eric Vasquez Senior SA Hybrid Edge, và Fernando Galves Gen AI Solutions Architect, Outposts

AWS Outposts là một dịch vụ được quản lý đầy đủ mà mở rộng cơ sở hạ tầng, dịch vụ, API, và công cụ AWS đến cơ sở của khách hàng. Outposts server được ra mắt vào năm 2022, một máy chủ gắn trên kệ 1U hoặc 2U, với khả năng chạy Amazon Elastic Compute Cloud (Amazon EC2) và Amazon Elastic Container Service (Amazon ECS), cũng như các dịch vụ edge khác ở quy mô nhỏ hơn như AWS IoT Greengrass. Phiên bản Outposts này chủ yếu tập trung vào việc mang lại độ trễ thấp hơn, khả năng tính toán AWS đến edge ở nhiều vị trí người dùng.

Trong quá trình cung cấp Outposts, bạn hoặc AWS tạo một kết nối liên kết dịch vụ kết nối Outposts server của bạn đến Khu vực AWS đã chọn hoặc Khu vực gối. Outposts phụ thuộc vào kết nối khu vực “để tiếp cận với khu vực gối”, chỉ cần rất ít về mặt mạng. Xem xét các yêu cầu mạng, nó cần:

• DHCP, để gán địa chỉ IP và cổng mặc định
• DNS công cộng, để giải quyết tên của điểm cuối khu vực ban đầu, để cho phép thiết lập tự động, và
• Truy cập Internet, để khi điểm cuối khu vực đã được giải quyết, Outpost có thể tiếp cận điểm cuối đó. Với tối thiểu 500 Mbps và độ trễ 175 ms tối đa cho hành trình khứ hồi

Thách thức của người dùng với kết nối Internet tại edge

Khi bạn đặt mua một Outposts server, bạn chịu trách nhiệm cài đặt server. Outposts server tự cung cấp và cần một kết nối liên kết dịch vụ giữa Outposts của bạn và Khu vực AWS (hoặc Khu vực gối). Kết nối này cho phép quản lý Outposts và trao đổi lưu lượng đến và từ Khu vực AWS. Việc triển khai server có thể được chia thành các bước sau: cài đặt Outposts server, bật chúng và cung cấp chi tiết xác thực thông qua dòng lệnh. Sau đó, Outposts server tiếp cận điểm cuối khu vực, và tự cung cấp. Trạng thái Outpost của bạn sẽ hiển thị là Hoạt động khi quá trình hoàn tất, có thể mất vài giờ tùy thuộc vào băng thông liên kết dịch vụ.

Mặc dù điều này đã phù hợp với phần lớn các trường hợp sử dụng, nhưng có một số vị trí không thể cung cấp kết nối Internet trong môi trường của họ. Điều này chủ yếu là trong các trường hợp sử dụng có lý do bảo mật mạnh mẽ để không có kết nối Internet (chẳng hạn như quầy giao dịch dịch vụ tài chính, cơ sở sản xuất nhỏ và quốc phòng), để tránh các rủi ro như tấn công DDoS và nỗ lực hack tiềm năng, hoặc để đáp ứng yêu cầu nhận quyền hoạt động (ATO).

Những vị trí này hoặc có một số dạng kết nối trực tiếp, hoặc thường có một liên kết kết nối trực tiếp tập trung đến AWS, và một mạng MPLS liên kết tất cả các địa điểm từ xa đến một địa điểm trung tâm. Trong cả hai kịch bản này, yêu cầu là cho phép Outposts server giải quyết và tiếp cận điểm cuối công cộng để thiết lập, và sau đó là điểm cuối neo công cộng để quản lý. Điều này được thực hiện mà không cần rời khỏi hệ sinh thái AWS, không cần phải tiếp xúc với các mối đe dọa Internet tiềm tàng một cách không cần thiết, và không cần thêm nhiều hệ thống để quản lý bản thân, nhưng thay vào đó là sử dụng các dịch vụ AWS.

Để đáp ứng yêu cầu này, chúng tôi xác định một số điều quan trọng cần được cung cấp nếu người dùng không có kết nối Internet tại địa điểm từ xa, như sau:

1. DHCP, để cung cấp cho Outposts server một địa chỉ IP, cổng mặc định và các máy chủ DNS.
2. Truy cập DNS công cộng để giải quyết cả điểm cuối thiết lập, và khi hoạt động, điểm cuối neo.
3. Truy cập Internet công cộng, mà không tiếp xúc vị trí người dùng với lưu lượng Internet tiềm tàng gây hại.

Tùy chọn VIF Direct Connect

Có ba loại Giao diện ảo (VIF) khác nhau có thể được cấu hình trên một liên kết AWS Direct Connect:

• VIF công cộng: Một VIF công cộng có thể truy cập tất cả các dịch vụ công cộng AWS bằng địa chỉ IP công cộng.
• VIF riêng tư: Một VIF riêng tư nên được sử dụng để truy cập một Amazon Virtual Private Cloud (Amazon VPC) bằng địa chỉ IP riêng tư.
• VIF chuyển tiếp: Một VIF chuyển tiếp nên được sử dụng để truy cập một hoặc nhiều Amazon VPC Transit Gateway liên kết với cổng Direct Connect.

Tùy chọn VIF chuyển tiếp

Một VIF chuyển tiếp có thể được sử dụng để giải quyết cả hai vấn đề này. Đầu tiên, một VIF chuyển tiếp triển khai một ENI trong một VPC (được gọi là kết hợp), để lưu lượng đến từ VIF chuyển tiếp vào một VPC có thể được định tuyến. Điều này là do nó tuân theo quy tắc rằng, đối với định tuyến VPC không chuyển tiếp, lưu lượng phải được nguồn hoặc nhắm mục tiêu cho một ENI trong VPC.

Nếu lưu lượng được chuyển tiếp đến một VPC khu vực thông qua cổng chuyển tiếp, thì nó có thể được chuyển tiếp đến Internet thông qua một cổng chuyển tiếp NAT. Đây là một cải tiến của kiến trúc để sử dụng một cổng chuyển tiếp để cung cấp một điểm thoát Internet duy nhất cho nhiều VPC đến Internet. Để biết thêm thông tin, xem Tạo một điểm thoát Internet duy nhất từ nhiều VPC sử dụng AWS Transit Gateway. Trong trường hợp này, thay vì cổng chuyển tiếp định tuyến nhiều VPC đến Internet, nó đang định tuyến đến một kết nối nội bộ.

Sử dụng cổng chuyển tiếp để chuyển tiếp lưu lượng đến một cổng chuyển tiếp NAT cho phép bạn cung cấp kết nối Internet cho Outposts server mà không quản lý thiết bị ảo, bởi vì cổng chuyển tiếp NAT cung cấp điều này như một dịch vụ. Cổng chuyển tiếp NAT cũng chỉ cho phép truy cập ra, vì vậy chúng cung cấp bảo mật chống lại bất kỳ nỗ lực truy cập bên ngoài nào từ Internet bởi một tác nhân xấu. Điều này hoạt động cho Outposts server vì chúng chỉ cần truy cập ra. Outposts luôn khởi tạo giao tiếp đến một điểm neo hoặc điểm cuối dịch vụ, và chúng không bao giờ nhận giao tiếp ngoại trừ khi là phản hồi.

Hình 1. Sơ đồ kiến trúc cho thấy việc sử dụng VIF chuyển tiếp và cổng chuyển tiếp NAT trong một Khu vực tiếp cận các điểm cuối khu vực

Cung cấp DNS

Mặc dù kiến trúc trước đó giải quyết thách thức về cách cung cấp một đường dẫn cho gói IP để chuyển tiếp giữa Outposts server và các điểm cuối công cộng cần thiết, nhưng nó không giải quyết vấn đề giải quyết tên DNS. Nếu địa điểm từ xa bị cô lập khỏi Internet, thì nó không có cách rõ ràng để giải quyết DNS.

Điểm cuối giải quyết Amazon Route53 cho phép bạn triển khai một địa chỉ IP trong một phân mạng VPC, cung cấp giải quyết DNS. Có hai loại điểm cuối giải quyết: xuất và nhập.

Điểm cuối giải quyết xuất được sử dụng bởi AWS để gửi truy vấn DNS đến các máy chủ DNS nội bộ của bạn. Điểm cuối giải quyết nhập được sử dụng bởi các máy chủ DNS (và máy chủ) của bạn để giải quyết địa chỉ trong Route 53.

Route 53 có thể giải quyết tên DNS công cộng, vì vậy điểm cuối dịch vụ Outposts [outposts..amazonaws.com](http://outposts.eu-central-1.amazonaws.com) trở thành có thể giải quyết bởi một điểm cuối giải quyết nhập.

Cấu hình VPC đi ra Outposts

1. Cài đặt VPC đi ra liên kết dịch vụ, xây dựng các phân mạng, triển khai một cổng chuyển tiếp NAT và cổng chuyển tiếp.
2. Tạo điểm cuối giải quyết Route 53 nhập.
3. Cấu hình DHCP trên switch, và đảm bảo rằng giá trị DNS khớp với điểm cuối giải quyết.
4. Cấu hình VIF chuyển tiếp trên switch, xây dựng một đối tác BGP, và kết nối đến cổng chuyển tiếp của bạn.
5. Xác nhận cài đặt truyền bá trên cổng chuyển tiếp và các tuyến đường mặc định.
6. Xác nhận các tuyến đường trên các phân mạng để cho phép lưu lượng đi ra Internet, và trở lại các Outposts server của bạn.
7. Kiểm tra giải quyết tên (dig) và https (curl) để điểm cuối dịch vụ.
8. Nếu cần, cài đặt Outposts server của bạn.

Tùy chọn VIF công cộng

Sử dụng một VIF công cộng cho phép bạn cung cấp kết nối Internet trực tiếp đến địa điểm nội bộ. Đổi lại, điều này có nghĩa là bạn cần triển khai các tường lửa và chức năng bảo mật trên kết nối này, thêm nhiều lớp chi phí hoạt động. Một VIF công cộng cũng có nghĩa là đầu nội bộ của VIF có thể được truy cập bởi bất kỳ địa chỉ IP công cộng nào trên mạng công cộng AWS, bất kể địa chỉ IP được liên kết đến bất kỳ instance nào. Một VIF công cộng là một điểm cuối địa chỉ IP công cộng trên mạng công cộng AWS. Bạn nên xem xét giao tiếp VIF công cộng như giao tiếp dựa trên Internet. Điều này có thể trở nên phức tạp đối với các nhóm tường lửa nếu họ phải cho phép danh sách các phạm vi IP AWS đã biết và quản lý tường lửa có trạng thái cho một phạm vi rộng của IP AWS.

Hơn nữa, ngay cả khi người dùng hài lòng với việc triển khai và quản lý một tường lửa ở đầu VIF công cộng đó, vẫn còn một câu hỏi về cách Outpost sẽ giải quyết DNS trong cài đặp này, và các điểm cuối neo tiếp theo. Trừ khi mạng riêng đã có giải quyết DNS đến một DNS công cộng, thì không có máy chủ DNS mà DHCP có thể chỉ đến để cho phép Outposts server có giải quyết tên. Điều này là do không có điểm cuối DNS công cộng trong mạng công cộng AWS. Lưu lượng từ VIF công cộng của người dùng có thể truy cập mạng công cộng AWS, nhưng nó không thể thoát ra khỏi nó đến các mạng công cộng khác. Ví dụ, nếu bạn đã cấu hình DHCP để chỉ đến một trong các máy chủ DNS nổi tiếng (chẳng hạn như 8.8.8.8), thì, vì máy chủ DNS này sống bên ngoài mạng công cộng AWS, các yêu cầu bắt nguồn từ phía nội bộ của một VIF công cộng sẽ bị loại bỏ khi chúng tới bờ của hệ thống tự trị AWS.

Cách duy nhất để một yêu cầu DNS được giải quyết sẽ là xây dựng một dịch vụ chuyển tiếp bind trong một VPC, cung cấp cho nó một địa chỉ IP công cộng, và chỉ giá trị DNS DHCP đến địa chỉ IP này.

Cấu hình mạng này giới thiệu độ phức tạp, và sẽ không có khả năng đối với những người có các công việc được quy định chặt chẽ. Bạn sẽ cần quản lý một tường lửa nội bộ, cho phép một mạng công cộng đến vị trí nội bộ, và quản lý cài đặt máy chủ bind trong một VPC. Vì những lý do này, một VIF công cộng thường không phải là một lựa chọn trừ khi người dùng đã chạy một và quen thuộc với các bước để bảo mật nó.

Hình 2. Sơ đồ kiến trúc cho thấy dòng lưu lượng sử dụng VIF công cộng và AWS Outposts

Anchoring AWS Outposts servers with AWS Direct Connect

Tùy chọn VIF riêng tư

Một VIF riêng tư có kết nối trực tiếp đến một virtual private gateway (VGW), hoặc thông qua một Direct Connect gateway. VPC không hỗ trợ định tuyến tự động. Để giải thích một cách khác, bất kỳ lưu lượng nào tuân theo quy tắc định tuyến trong bảng định tuyến subnet đều phải bắt nguồn từ, hoặc đi đến, một địa chỉ IP (hoặc đúng hơn là một Elastic Network Interface (ENI)) bên trong VPC đó.

Virtual private gateway không có ENI liên kết với chúng, nhưng được chỉ định là bước tiếp theo trong bảng định tuyến subnet. Nếu chúng ta xem xét ví dụ này và xem xét lưu lượng mà Outposts servers sẽ cố gắng truyền, thì nó sẽ gửi một gói dữ liệu với địa chỉ nguồn của Outposts servers, và địa chỉ đích là điểm cuối công cộng của dịch vụ Outposts (giả sử rằng nó có thể giải quyết được). Khi gói dữ liệu này đến VPC, thì cả địa chỉ nguồn và địa chỉ đích đều không thuộc về một ENI bên trong VPC. Do đó, định tuyến VPC sẽ loại bỏ gói dữ liệu này.

Ngay cả khi có một quy tắc định tuyến trên subnet chỉ định bước tiếp theo cho tất cả lưu lượng đến một NAT gateway (lý tưởng cho xuất internet), định tuyến vẫn sẽ không hoạt động. Điều này là do gói dữ liệu từ Outposts servers không có đích đến là NAT gateway, mà thay vào đó là đích đến của điểm cuối cấu hình trên internet.

Có thể sử dụng một sự kết hợp giữa định tuyến vào và các proxy trong suốt để thu nhận lưu lượng và truyền nó đến một instance đang chạy dịch vụ proxy để chuyển tiếp đến internet. Tuy nhiên, điều này sẽ thêm vào phức tạp trong việc quản lý và bảo trì các máy chủ proxy. Vì những lý do này, một VIF riêng tư thường không được khuyến nghị.

Hình 3. Sơ đồ kiến trúc hiển thị VGW và gói dữ liệu bị loại bỏ do định tuyến tự động không được hỗ trợ

Kết luận

Trong bài viết này, chúng tôi đã thảo luận về các mô hình kiến trúc mà bạn có thể sử dụng để cung cấp Outposts khi kết nối internet công cộng không khả dụng. Để bắt đầu với Outpost servers, vui lòng truy cập Server User Guide. Để biết thêm thông tin, liên hệ với chúng tôi để tìm hiểu thêm.