简体繁体 English

AWS - 基于路径的路由来放大应用程序

[英]AWS - Path based routing to amplify apps

原文 2022-08-20 02:33:37 9 1 amazon-web-services/ aws-amplify/ aws-application-load-balancer

I have a two frontend apps served in two different amplify applications.我在两个不同的放大应用程序中提供了两个前端应用程序。 I want to forward the request based on the path to different servers using an Application Load Balancer (I'm open to any other tool that you might suggest as well).我想使用 Application Load Balancer 根据到不同服务器的路径转发请求（我也愿意接受您可能建议的任何其他工具）。 For example:例如：

But as far as I know, ALB path routing works with EC2 instances only.但据我所知，ALB 路径路由仅适用于 EC2 实例。 Is there a way to achieve this with two amplify instances?有没有办法通过两个放大实例来实现这一点？

I thought to create a EC2 instance with a tunnel to the amplify instance but I'm not sure if is the best solution.我想创建一个带有通往放大实例的隧道的 EC2 实例，但我不确定是否是最佳解决方案。

The main goal of doing this is share the localstorage of these two applications in the same domain.这样做的主要目标是在同一个域中共享这两个应用程序的本地存储。 So is important that the request is forwarded and not redirected to the amplify domains因此，转发请求而不是重定向到放大域非常重要

Either ways, if you have in mind any other way to achieve this, I'm open to suggestions as well无论哪种方式，如果您有任何其他方式来实现这一目标，我也愿意接受建议

1 个解决方案

That's true that ALB only supports instance, Ip or Lambda function only and no other AWS resources.确实， ALB 仅支持实例 Ip 或 Lambda function 且不支持其他 AWS 资源。

You can achieve your path based routing using CloudFront您可以使用 CloudFront 实现基于路径的路由

Create a cloudfront which will front both the amplify apps创建一个将两个放大应用程序放在前面的云端
Add both the amplify app URL as 2 origins to the cloudfront.将放大应用程序 URL 作为 2 个来源添加到云端。
Setup cache behavior path pattern settings for both the origins for example /srv1 path pattern should map to 1st amplify app and similarly for the /srv2 -> 2nd amplify app.为两个来源设置缓存行为路径模式设置，例如 /srv1 路径模式应该 map 到第一个放大应用程序，同样适用于 /srv2 -> 第二个放大应用程序。
Note :- you will need a default behaviour too for this cloudfront (for example none of the request matches your path pattern the request will go to this default behaviour for example a custom error page;)注意：-您也需要此云端的默认行为（例如，没有一个请求与您的路径模式匹配，请求将 go 到此默认行为，例如自定义错误页面；）
Note:- order of the path pattern is imp check reference links for more explanation注意：-路径模式的顺序是 imp 检查参考链接以获得更多解释

Links -> reference 1 , reference2 , https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html#DownloadDistValuesPathPattern链接 -> 参考 1 、参考2、 https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html#DownloadDistValuesPathPattern

My personal take on this:- amplify of course does help in development by taking away all the abstractions but at the same time you loose the control, instead if i were you i would have gone with ECS fargate with ALB combination which of course give me better control for future requirements and cost management.我个人对此的看法：-通过取消所有抽象，放大当然确实有助于开发，但同时你失去了控制，相反，如果我是你，我会选择 ECS fargate 和 ALB 组合，这当然给了我更好地控制未来的需求和成本管理。