LiveKit Egress S3 upload fails with `ExpiredToken` after ~80 min call

Egress / Ingress
1

Setup

  • LiveKit Egress with an S3 destination
  • AWS credentials we pass to the egress request are STS-derived (per our IAM config the session should be valid for 24 hours; we don’t have visibility into the actual effective TTL of the credentials by the time Egress uses them)

What happened

A call lasted ~80 minutes. Egress recorded the audio. When Egress tried to upload to S3 at the end (CreateMultipartUpload), AWS returned ExpiredToken and the recording was lost.

Egress ID: EG_LqDrKVyspwm9
Room ID: RM_Bx3WmmMJp5Rr

{
  "event": "Egress failed - skipping post-processing",
  "egress_status": 4,
  "egress_id": "EG_LqDrKVyspwm9",
  "error": "S3 upload failed: operation error S3: CreateMultipartUpload, https response error StatusCode: 400, RequestID: XGE8YY0EQY2YZPKP, HostID: <hostid-redacted>, api error ExpiredToken: The provided token has expired.",
  "timestamp": "2026-05-26T23:37:27.183624+00:00"
}

Questions

  1. What is the actual effective lifetime of STS credentials passed to Egress — does it honor the token’s Expiration, or cap it to something shorter?
  2. What’s the recommended way to record calls longer than ~1 hour to S3 via Egress without hitting ExpiredToken?
  3. Is there any way to recover or retry the upload after this failure? The audio was captured by Egress, only the upload failed.
2

Egress does not modify the TTL of the token, so I assume the effective TTL of the credentials was < 80m.

It’s not my area of expertise, but others have used assume_role_arn to avoid this kind of issue with long-running sessions. This setting has high-level documentation here: Egress API | LiveKit Documentation but you would need to contact support to enable that. I think this setting is only available on Scale and Enterprise.

3

Thanks for the response Darryn,

    boto_session = boto3.Session()
    credentials = boto_session.get_credentials()
    session_token = credentials.token
    access_key = credentials.access_key
    secret_key = credentials.secret_key
    req = api.RoomCompositeEgressRequest(
        room_name=ctx.room.name,
        audio_only=True,
        audio_mixing=audio_mixing,
        file_outputs=[
            api.EncodedFileOutput(
                file_type=api.EncodedFileType.OGG,
                filepath=file_path,
                disable_manifest=True,
                s3=api.S3Upload(
                    bucket=s3_bucket,
                    region=s3_region,
                    session_token=session_token,
                    access_key=access_key,
                    secret=secret_key,
                ),
            )
        ],
    )
    livekit_api = api.LiveKitAPI()
    res = await livekit_api.egress.start_room_composite_egress(req)

This is a sample on how we trigger an egress request where we pass a session token generated at that time based on the IAM policy attached to the pod. The IAM policy has a 24 hr ttl for token in our normal deployment.

For the assume_role_arn solution, can you please help share how we can enable and approach this? We are on Scale plan, our project Id - p_3tqm7ro6kbs

4

@Zaheer_Abbas, I think the root cause is that the session_token you pass is a static snapshot of your pod’s IRSA credentials taken at egress-request time. AWS web-identity (IRSA) sessions default to ~1 hour regardless of the role’s 24h MaxSessionDuration, unless the SDK explicitly requests longer. Egress holds that snapshot and can’t refresh it, so an 80-min call blows past the 1h expiry.

assume_role_arn fixes it structurally: instead of a static token, Egress makes an AssumeRole call at upload time to mint fresh credentials [ livekit/protocol/protobufs/livekit_egress.proto, S3Upload.assume_role_arn ]. The proto notes it’s “only available on accounts that have the feature enabled,” which is why Darryn routed you to support. You’d pass assume_role_arn + assume_role_external_id plus a base credential authorized to assume that role; support will confirm the exact trust setup on Scale (reference p_3tqm7ro6kbs).

For the lost recording (EG_LqDrKVyspwm9): a failed upload isn’t recoverable through the Egress API, so ask support in the same ticket whether anything was retained server-side, though realistically that file is gone.

5

You would need to please contact support for this request as follows:

6

Thanks - let me check on this and get back. Appreciate the help

7

@darryncampbell - can you please confirm that we can use both access token method and arn token method for the same account at a given time right? NOT for the same egress request, I am meaning to ask if we can use both access token method for one call and arn token method for a different call. Is that allowed by LiveKit cloud for a given project?

8

Yes, you should be able to use both methods got separate calls, however I want to correct something I said previously. This feature is only available to enterprise customers, not scale - apologies for that error.