Apache APISIX in front of AWS Lambda functions

The most common cause is a wrong service value. The aws-lambda plugin defaults service to execute-api, which is correct for Amazon API Gateway endpoints but wrong for Lambda function URLs, which need service set to lambda. Check the service and region values against the endpoint you are calling. Next, confirm the signing keys belong to an IAM identity with permission to invoke the function, and that the system clock on the APISIX nodes is synchronized, because SigV4 signatures are time-bound. If the error persists, compare the host header APISIX sends with the host in the function URL or API Gateway endpoint, since a mismatch changes the signed canonical request.

A gateway timeout comes from APISIX closing the upstream connection before the function responds, while a Lambda timeout comes from the function reaching its own configured limit. Check the function's timeout setting in AWS, then check the upstream timeout settings on the APISIX route. The gateway timeout should be longer than the function timeout plus network time, or the gateway will cut off requests the function is still processing. Review the Lambda duration and error metrics in CloudWatch for the same time window as the gateway error. If the function completes but the client still sees an error, the response is probably being delayed or dropped between the gateway and the client.

Yes. When a function has been idle, the first invocation must initialize the runtime and load code, which can add enough latency to exceed the upstream timeout on the gateway route. The symptom is occasional 504 responses that cluster after quiet periods and disappear on retry. To check, look for init duration entries in the function's logs and compare them with the gateway's upstream timeout. Options include raising the route timeout for that function, reducing package size and dependencies, or provisioning concurrency in AWS if the workload justifies its cost. Each option has a recurring cost or a trade-off in latency and scaling that should be confirmed with your team before the change is made.

Path forwarding is usually altered by the route definition. Check whether the APISIX route uses a uri pattern with a prefix that is stripped or rewritten before the request reaches the function, and whether the function URL or API Gateway resource expects that path. For function URLs, the path after the domain is passed to the function event, so a stripped or added prefix changes how your handler routes the request. Compare the request as the client sends it with the event the function logs. Query strings and trailing slashes are also worth checking, since a rewrite can drop them or add a slash that the handler does not expect.

Body and header problems usually come from the gateway altering the request or from the function expecting a format it does not receive. Confirm the Content-Type and Content-Length headers are passed unchanged, and check that no plugin on the route modifies the body. Some headers, including authentication headers, may be consumed or replaced by plugins, so verify which headers the function receives by logging the event. Binary payloads need the correct encoding handling in the function, and API Gateway proxy integrations expect a specific response shape, so a handler that returns a raw object instead of the expected status, headers and body will fail in ways that look like gateway errors.

Requests fail with authorization errors once the credentials APISIX holds are deactivated or deleted, and they continue to fail until the new values are loaded. Inventory every route that uses the aws-lambda plugin, record which IAM user or role and key each one uses, and confirm where those values are stored. Rotation should be planned as a change with a test call against each route after the update. Where the credentials are stored in configuration, confirm how the update reaches the gateway, and whether it requires a reload. Ask your team whether IAM roles or short-lived credentials are an option for your environment, since they reduce the number of long-lived keys that need rotation.

Put APISIX in front of Lambda when you need a single entry point for several backends, consistent authentication and rate limiting across services, or self-hosted control over the gateway layer. If the function has no other consumers and AWS already provides the controls you need, adding a gateway adds a component to run, patch and monitor, along with a second place where timeouts and credentials must be managed. A useful test is to list the policies you need at the edge, then check whether they are already available in the AWS service. Scope and cost depend on the number of routes, the authentication model and the operating model your team can support.

The answer depends on what the gateway replaces, not on the gateway alone. APISIX itself is licensed under Apache-2.0, so the software carries no license fee, but you pay for the compute that runs the gateway, the etcd cluster in traditional or decoupled mode, and the engineering time to build and operate it. Ask any partner to split the quote into one-time work (design, route build, auth setup, testing, handover) and recurring work (upgrades, patching, monitoring, on-call support). If the gateway only forwards requests to one function, a direct function URL with its own auth may be cheaper to run.

Effort scales with four factors: the number of routes, the authentication model, the number of environments, and how much APISIX experience your team already has. Each route needs a path mapping, an upstream definition, and tests. Each auth model (API keys, IAM SigV4, JWT or OpenID Connect) adds configuration and consumer design. Every extra environment repeats the pipeline work. A team new to APISIX will spend more time on configuration review and operational runbooks. Ask the quote to list these four factors with counts so you can compare scopes.

Duration depends on the agreed scope, so there is no standard figure to quote here. A scope with a few routes, one auth model and one environment is much shorter than a scope covering dozens of functions, several identity providers and separate staging and production estates. Engagements are fixed-scope, so the written scope should state the milestones, the deliverables for each one, and the dependencies on your AWS and identity teams. Ask for a timeline tied to those milestones rather than a single end date.

Start with access and inventory. The team needs an AWS account or role with permission to read Lambda function configuration, function URLs or API Gateway stages, and IAM policies used for signing. You also need a function inventory with names, runtimes, expected payloads, timeouts and owners. If authentication uses your identity provider, you need an admin or app owner who can register the gateway as a client and confirm token claims. Agree on the network path from APISIX to AWS, since that determines how the gateway reaches the endpoints.

Yes, if the team has someone who knows APISIX configuration, AWS IAM and the identity provider in use. The aws-lambda plugin is documented and the configuration keys are straightforward, so a small proof of concept is a reasonable first step. The risk sits in the parts that are easy to miss: SigV4 signing with the correct service value, timeout alignment between the gateway and Lambda, and securing the Admin API and etcd. Decide before starting who will own upgrades and on-call response. A partner is most useful when those ownership questions have no clear internal answer.

A gateway adds a hop, a configuration surface and a component to patch. It is the wrong choice when you have a single function with simple API Gateway or function URL access and no need for shared authentication, rate limits or routing across services. It also fits poorly when your traffic is mostly internal and already protected by IAM roles, or when the team has no capacity to run another production component. A gateway earns its place when several services need one policy point, when you must keep the same routes across clouds or on-premises services, or when you need plugins that AWS-native tools do not cover in your environment.

Use the plugin's service setting to match the endpoint type. The aws-lambda plugin calls either a Lambda function URL or an Amazon API Gateway endpoint. For function URLs, set service to lambda. API Gateway endpoints use the default execute-api. Authentication also differs: API Gateway endpoints can use an API key, while IAM access keys signed with AWS Signature Version 4 work with either target. Before choosing, confirm with your AWS administrators which authorization model they already audit, since the choice affects how keys are issued and rotated. The aws-lambda plugin documentation lists the exact settings to confirm.