AWS Lambda中使用bcrypt哈希超时的低成本优化方案问询

这真是个典型的Lambda资源矛盾场景——既要保持大部分请求的低成本，又要解决少数CPU密集型操作的性能瓶颈，太懂这种纠结了！结合你用Go开发的情况，给你几个实际可行的方案：

1. 拆分专属Lambda函数处理哈希计算 #

把用户注册/认证中的bcrypt哈希逻辑单独抽成一个独立的Lambda函数，给这个函数配置更高的内存（比如256MB或512MB），而主Web应用的Lambda依然保持128MB的低配置。

在Go代码中，你可以用AWS SDK for Go调用这个专属哈希Lambda：

import (
    "context"
    "github.com/aws/aws-sdk-go-v2/aws"
    "github.com/aws/aws-sdk-go-v2/service/lambda"
)

// 调用专属哈希Lambda
func invokeHashLambda(ctx context.Context, cfg aws.Config, password string) (string, error) {
    client := lambda.NewFromConfig(cfg)
    input := &lambda.InvokeInput{
        FunctionName: aws.String("your-hash-function-name"),
        Payload:      []byte(password),
    }
    resp, err := client.Invoke(ctx, input)
    if err != nil {
        return "", err
    }
    return string(resp.Payload), nil
}

这样只有注册和认证这两个请求会触发高内存Lambda，其他请求依然走低成本的128MB实例，完美控制成本。而且高内存Lambda的CPU性能更强，bcrypt哈希时间会大幅缩短（比如256MB下可能2-3秒就能完成）。

2. 调整bcrypt的Cost参数 #

bcrypt的计算耗时主要由cost参数决定，这个参数是指数级增长的——cost每加1，计算时间就翻倍。如果当前你用的是默认的cost=12（甚至更高），在128MB的Lambda上确实会非常慢。

你可以尝试降低cost值（比如降到8或9），在本地或测试环境测试哈希耗时：

import "golang.org/x/crypto/bcrypt"

func hashPassword(password string) (string, error) {
    // 把cost从默认的12降到8，测试耗时
    hashed, err := bcrypt.GenerateFromPassword([]byte(password), 8)
    return string(hashed), err
}

通常cost=8在128MB Lambda上的哈希时间能控制在1-2秒左右，完全可以接受，而且安全性依然符合大部分业务场景的要求（只要你的业务不是超高安全等级的金融类应用）。这个方案不需要调整Lambda配置，零额外成本。

3. 给专属哈希Lambda配置少量预留并发（可选） #

如果拆分后的哈希Lambda被调用的频率很低，偶尔会遇到冷启动+哈希的双重耗时，可以给这个高内存Lambda配置1个预留并发。这样AWS会保持一个预热好的实例随时待命，调用时直接处理，不会有冷启动延迟，进一步提升用户体验。由于只配置1个预留并发，额外成本几乎可以忽略。

4. 备选：尝试内存效率更高的密码哈希算法 #

如果调整cost还是达不到预期，也可以试试Argon2id（当前密码哈希的标准），它的内存利用率比bcrypt更好，在低内存环境下的性能表现可能更优。Go官方的golang.org/x/crypto/argon2库已经支持这个算法，你可以测试对比两者在128MB Lambda上的耗时。不过这个方案需要修改代码，建议优先尝试前面的方案。

内容的提问来源于stack exchange，提问作者Lockless