Adhérence des sessions pour les règles pondérées

Lorsque vous utilisez des règles pondérées pour les A/B tests ou les déploiements Canary, vous souhaitez que chaque session bénéficie d'une expérience cohérente sur plusieurs demandes. Sans rigidité de session, une session peut recevoir différents ensembles de configuration ou être acheminée vers différentes cibles à chaque demande. Le routage vers une cible différente implique l'exécution d'un nouvel agent sans aucun contexte par rapport aux requêtes précédentes, ce qui perturbe l'expérience utilisateur.

Pour résoudre ce problème, la passerelle prend en charge la persistance des sessions. Lorsque vous incluez un identifiant de session dans vos demandes, la passerelle enregistre la décision de routage prise lors de la première demande et la réutilise pour toutes les demandes suivantes au cours de la même session.

Comment fonctionne la rigidité des sessions

La passerelle identifie une session en extrayant un identifiant de session de chaque demande. Le flux de viscosité fonctionne comme suit :

La façon dont la passerelle détermine l'ID de session dépend du type de cible :

Configurer le caractère permanent des sessions pour les cibles intermédiaires

Pour les cibles intermédiaires HTTP, vous pouvez définir une option stickinessConfiguration dans la configuration cible pour contrôler la manière dont la passerelle identifie les sessions et la durée de l'affinité de session. Cela est utile lorsque vos clients envoient déjà leur propre en-tête de session et que vous ne voulez pas leur demander d'envoyer également l'en-tête de session d'exécution standard.

L'stickinessConfigurationobjet contient :

Lorsqu'une cible possède unstickinessConfiguration, la passerelle résout l'ID de session à partir de l'identifiant configuréidentifier.

L'exemple suivant crée une cible intermédiaire avec un stickinessConfiguration qui extrait l'ID de session d'un x-session-id en-tête personnalisé et expire l'affinité de session au bout de 8 heures (28 800 secondes) :

aws bedrock-agentcore-control create-gateway-target --cli-input-json '{
    "gatewayIdentifier": "GATEWAY_ID",
    "name": "my-passthrough-target",
    "targetConfiguration": {
        "http": {
            "passthrough": {
                "endpoint": "https://my-service.example.com",
                "protocolType": "CUSTOM",
                "stickinessConfiguration": {
                    "identifier": "$.AMZN_AC_GW_CONTEXT.headers.x-session-id",
                    "timeout": 28800
                }
            }
        }
    },
    "credentialProviderConfigurations": [
        {"credentialProviderType": "GATEWAY_IAM_ROLE"}
    ]
}'

Pour plus d'informations sur les cibles intermédiaires, consultez la section cibles intermédiaires HTTP.

Comportements importants

Les décisions enregistrées ont priorité sur les modifications des règles. Si vous mettez à jour une règle, les sessions existantes se poursuivent avec la décision initiale. Cela garantit la cohérence des sessions. Pour appliquer de nouvelles règles à une session, démarrez-la avec un nouvel identifiant de session.

Les sessions expirent après une période d'inactivité. La fenêtre d'expiration est réinitialisée à chaque demande (fenêtre coulissante). Pour les cibles AgentCore d'exécution, les sessions expirent après 15 jours d'inactivité. Pour les cibles HTTP passthrough, la fenêtre d'expiration est celle timeout que vous avez définie dans la cible stickinessConfiguration (1 à 86 400 secondes) ; si vous ne définissez pas de délai d'expiration, le délai par défaut s'applique. Après l'expiration d'une session, utilisez un nouvel ID de session pour les nouvelles sessions afin d'éviter tout comportement de routage inattendu. Nous vous recommandons de ne pas réutiliser les identifiants de session expirés.

L'état de la session est défini par cible. Les différentes cibles conservent un état de session indépendant.

Pris en charge pour les cibles AgentCore d'exécution et de transfert HTTP. Le caractère persistant des sessions n'est pas pris en charge pour les cibles MCP.