我有一个用例，我希望所有请求都以如下前缀开头：
https://WHATEVER/pfx
例如 https://WHATEVER/pfx/a 和 https://WHATEVER/pfx/b/c/d
但我希望阻止 https://WHATEVER/somewhere_else 和不包含前缀 (pfx) 的类似请求。为了防止这种情况，我想简单地将所有此类请求重定向到 https://WHATEVER/pfx （主页）
这对 AWS ALB 可行吗？
提前致谢！
我在 AWS 上运行具有多个 SSL 证书的 ALB。域名是通过 EC2 上的应用程序动态处理的。目前，ALB 会将请求路由到 ALB 的 IP 地址到应用程序。即使应用程序对这些查询有适当的例外，这也会导致所有请求日志和 WAF 中出现不必要的日志条目。
我的前两个想法是……
- 添加阻止 IP 地址的侦听器规则。不幸的是，我看到的唯一方法是在
*.*.*.*. 这行不通，因为我们可以为site.group.example.com. - 如果 Host 标头与附加到侦听器的 SSL 证书之一匹配，则仅将请求转发到目标组。这里的问题是我找不到任何方法来执行这种规则。
因此，我有一个位于专用 VPC (EKS-VPC) 中的 EKS 集群。在我的主 VPC 中，我有一个面向公众的 ALB，我希望它以某种方式将流量引导到在 EKS 中运行的服务。更具体地说，我希望 ALB 将对特定端点的请求转发到 EKS，并将所有其他请求转发到我的主 VPC 中的 EC2 实例。
因此，例如请求myservice.mydomain.com将转到主 VPC 内的 EC2 实例，但请求myservice.mydomain.com/myapi/myendpoint将转到在 EKS 中运行的服务 - 因此是不同的 VPC
我在主 VPC 和 EKS VPC 之间启用了 VPC 对等互连，并且我更新了我的路由表。
我当然已经配置了一个 Ingress 并在 EKS 中设置了 ALB 控制器，它负责内部 ALB 配置
我正在考虑为 EKS 集群创建一个内部 ALB。然后获取其 IP 并创建一个新的 IP 目标组，将其与主 ALB 相关联。但是，您可以想象这会失败，因为对内部 ALB 私有 IP 的运行状况检查失败。所以我想知道这种情况下的最佳选择是什么？
如果我的基础架构中有一个带有下游 ECS 目标组的 ALB，SSL/TLS 是否总是在 ALB 处终止？
如果是这样，我唯一的选择是 ELB/NLB 来保留 SSL/TLS 上下文吗？
在 AWS 中，我们在内部 ALB 中部署了一个后端服务 - API。对于前端（Web UI），它调用API，也需要从企业内部网络访问。它应该绑定到 Route53。
我们在企业中使用 VPN。我们使用 DirectConnect 连接 AWS VPC。因此我们可以使用私有 IP 访问 AWS 中的内部 ALB 资源。
现在我们想要将原始内部 ALB 的 DNS 名称绑定到具有域的 Route 53。如果仅使用内部 ALB 可以吗？
可能当前内部的 ALB 无法实现目的。所以我们将添加第二个 ALB - 面向互联网。用它来绑定Route53。
如果同时设置2种ALB，用ECS部署，2种不同的目标安全组怎么做蓝绿部署？
我有一个 ECS Fargate 服务映射到 AWS 上的 Application Load Balancer。在此服务中，有几个任务经常被杀死并重新启动。这些任务应该能够连接到 MongoDB Atlas 集群。
我应该将哪个 IP 列入我的 Atlas 集群的白名单？我的服务是否可以有一个弹性 IP 或一系列 IP，以在我的 Mongo Atlas 集群中只允许我的服务的 IP？
对不起，如果这个问题很简单，我在 AWS 上的 ECS、ALB 和网络上有点挣扎。
我在 VPC 中构建了这条流量路由。
Route53->ACM(SSL)->Public ALB->EC2(Nginx proxy)->Private ALB->ECS(Internal App)
EC2 的安全组允许 tcp 80 和 443。ECS 的安全组允许来自 EC2 的安全组的 80。
当我访问注册在 Route53 中的域时，出现504 DNS look up failed错误。访问公共 ALB 的 DNS 名称时503 Service Temporarily Unavailable出错。
我确定 ACM 正在设置并且公共 LB 的 DNS 名称正在使用域注册到 Route53。
公共子网上的 ALB 设置由 Terraform 执行
resource "aws_lb_listener" "http" {
load_balancer_arn = aws_lb.this.arn
port = "80"
protocol = "HTTP"
default_action {
type = "redirect"
redirect {
port = "443"
protocol = "HTTPS"
status_code = "HTTP_301"
}
}
}
resource "aws_lb_listener_rule" "http_redirect" {
listener_arn = aws_lb_listener.proxy.arn
priority = 1
action {
type = "redirect"
redirect {
port = "443"
protocol = "HTTPS"
status_code = "HTTP_301"
}
}
condition {
path_pattern {
values = ["/*"]
}
}
}
resource "aws_lb_listener_rule" "http_forward" {
listener_arn = aws_lb_listener.http.arn
priority = 2
action {
type = "forward"
target_group_arn = aws_lb_target_group.proxy.arn
}
condition {
host_header {
values = ["proxy.portsite.com"]
}
}
}
resource "aws_lb_listener_rule" "https_forward" {
listener_arn = aws_lb_listener.https.arn
action {
type = "forward"
target_group_arn = aws_lb_target_group.proxy.arn
}
condition {
host_header {
values = ["proxy.portsite.com"]
}
}
}
两者都是路由的必要条件吗http_redirect？http_forward还是只有http_redirect好的？而且，问题是由它引起的吗？
已编辑：我的 AWS 系统中有问题。每几个请求几乎都需要 130 秒的时间来回答。当我说一些时，我的意思是 5 到 25 左右。通常，如果您取消慢速请求并再次发送，它只会快速响应。我还注意到任何请求都会发生这种情况，而不仅仅是特定请求。服务器和后端看起来并没有超载。系统如下：
ALB with sticky sessions | 2 Web servers | DB on RDS
系统在大多数时候使用 curl 时响应良好，但是当它需要很长时间时，这是响应输出：
这是任何 URL 上的 curl 测量时间。
time_namelookup: 0.004136
time_connect: 130.117558
time_appconnect: 130.125254
time_pretransfer: 130.125340
time_redirect: 0.000000
time_starttransfer: 130.172553
----------
time_total: 130.172615
除了 之外，从time_connect页面加载之后的意义上说，请求很好。系统正常响应时间小于0.5秒。
我正在阅读有关此的内容，并且文档表明time_connect，与
“从客户端的角度来看，time_connect 是 TCP 三次握手。它在客户端发送 ACK 后立即结束 - 它不包括该 ACK 到达服务器所需的时间。它应该接近往返时间(RTT) 到服务器..."
这是从这里拍摄的。
补充：系统本身是 nginx-Python，运行在 ec2 实例上，RDS 上有 MySQL 数据库，它提供来自 s3 的静态内容，用户也可以上传自己的文件。来自本地主机上的服务器（nginx-python ec2 实例） curl 总是很好，它永远不会花费很长时间。这让我相信这与 LB 和在 python 主机上监听的 nginx 有关。
补充：我也试过只在后端留下一台机器，问题并没有消失。
我在 AWS Cloudwatch、应用程序日志或数据库监控上找不到任何有意义的东西。关于我应该研究什么或如何解决此问题的任何想法？
编辑 3 感谢下面的评论：
# curl -v -I -L -k -w "@time.txt" -s "https://my-site.com/url/"
* Trying "
* Trying IP.ONE.from.AWS...
* connect to IP.ONE.from.AWS port 443 failed: Connection timed out
* TCP_NODELAY set
* Connected to my-site.com (IP.TWO.from.AWS) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
IP-ONE-from-AWS 和 IP-TWO-from-AWS 是来自我应该连接的 AWS 区域的 IP。
标题基本上说明了一切，我很好奇是否有一项服务可以处理 SSL 层，然后通过普通 HTTP（在 VPN 内部）将数据发送到 ec2 实例。
应用程序负载平衡器可以很好地用于此目的，但它们很昂贵（10 美元/月，如果您想要在例如几十个子域上获得证书，则加起来）并且由于它们使用的许多抽象层而使设置和管理很烦人。
我在同一个 ec2 实例上运行 nginx 和 postgre sql。
它为一个在该数据库上读取和写入数据的 Rails 应用程序提供服务。
我想在 ALB 服务后面有 2 个实例来分配负载并确保可用性。
我应该怎么做才能确保 2 个实例的数据一致？