Linden Consulting.
Architecture

ElastiCache AUTH Required: Redis-Authentifizierung korrekt konfigurieren

2026-05-20 · 8 Min. Lesezeit

Ihre Anwendung hat sich problemlos mit ElastiCache Redis verbunden, bis jemand die Verschlüsselung im Transit aktiviert hat. Jetzt schlägt jeder Verbindungsversuch fehl mit:

NOAUTH Authentication required.

Oder Sie sehen dies in Ihren Anwendungslogs:

Redis connection error: Error: NOAUTH Authentication required.
    at parseError (/app/node_modules/redis/lib/parser.js:179:12)

Oder schlimmer noch, die Verbindung hängt stillschweigend und läuft in einen Timeout:

Redis connection error: connect ETIMEDOUT 10.0.1.42:6379

ElastiCache-Authentifizierungsfehler sind trügerisch. Die Fehlermeldungen sehen einfach aus, aber dahinter verbirgt sich eine komplexe Interaktion zwischen Auth-Tokens, TLS-Konfiguration, Security Groups, VPC-Netzwerk und Parameter-Group-Einstellungen. Ich habe ElastiCache-Verbindungsprobleme für Dutzende von Kunden debuggt, und die Ursache ist selten das, was sie zunächst zu sein scheint.

Hier ist mein systematischer Ansatz zur Diagnose und Behebung jedes gängigen ElastiCache-Authentifizierungsfehlers.

Schritt 1: Aktuelle Cluster-Konfiguration ermitteln

Bevor Sie Änderungen vornehmen, verstehen Sie den aktuellen Zustand Ihres ElastiCache-Setups:

# Für Replication Groups (häufigste Konfiguration)
aws elasticache describe-replication-groups \
  --replication-group-id my-redis-cluster \
  --query 'ReplicationGroups[0].{
    Status: Status,
    AuthTokenEnabled: AuthTokenEnabled,
    TransitEncryptionEnabled: TransitEncryptionEnabled,
    AtRestEncryptionEnabled: AtRestEncryptionEnabled,
    ClusterMode: ClusterEnabled,
    AutomaticFailover: AutomaticFailover,
    MemberClusters: MemberClusters,
    NodeGroups: NodeGroups[*].{
      PrimaryEndpoint: PrimaryEndpoint,
      ReaderEndpoint: ReaderEndpoint,
      NodeGroupMembers: NodeGroupMembers[*].{
        CacheClusterId: CacheClusterId,
        CurrentRole: CurrentRole
      }
    }
  }'

Achten Sie besonders auf AuthTokenEnabled und TransitEncryptionEnabled. Wenn AuthTokenEnabled den Wert true hat, muss jede Verbindung das Auth-Token bereitstellen. Wenn TransitEncryptionEnabled true ist, muss jede Verbindung TLS verwenden.

# Parameter Group auf zusätzliche Einstellungen prüfen
aws elasticache describe-cache-parameters \
  --cache-parameter-group-name my-redis-params \
  --query 'Parameters[?ParameterName==`cluster-enabled` || ParameterName==`maxmemory-policy`].{Name: ParameterName, Value: ParameterValue}'

Ursache 1: AUTH-Token erforderlich, aber nicht bereitgestellt

Wenn AuthTokenEnabled den Wert true hat, muss Ihr Client den AUTH-Befehl senden, bevor er andere Befehle ausführt. Die Art der Bereitstellung hängt von Ihrer Client-Bibliothek ab.

Zum Testen mit redis-cli:

# Ohne TLS (wenn Transit-Verschlüsselung deaktiviert ist)
redis-cli -h my-redis-cluster.abc123.ng.0001.use1.cache.amazonaws.com \
  -p 6379 \
  -a 'my-auth-token-here'

# Mit TLS (wenn Transit-Verschlüsselung aktiviert ist)
redis-cli -h my-redis-cluster.abc123.ng.0001.use1.cache.amazonaws.com \
  -p 6379 \
  --tls \
  -a 'my-auth-token-here'

Im Anwendungscode wird das Auth-Token im Connection String oder der Konfiguration angegeben:

redis://default:my-auth-token-here@my-redis-cluster.abc123.ng.0001.use1.cache.amazonaws.com:6379

Oder für TLS-Verbindungen:

rediss://default:my-auth-token-here@my-redis-cluster.abc123.ng.0001.use1.cache.amazonaws.com:6379

Beachten Sie das doppelte s in rediss:// — dies kennzeichnet eine TLS-Verbindung. Die Verwendung von redis:// bei erforderlichem TLS führt zu einem Verbindungsfehler.

Ein häufiger Fehler ist das Speichern des Auth-Tokens in einer Konfigurationsdatei oder Umgebungsvariable mit versehentlichem nachgestelltem Leerzeichen oder Zeilenumbruch. Überprüfen Sie den exakten Wert:

# Auf versteckte Zeichen in der Umgebungsvariable prüfen
echo -n "$REDIS_AUTH_TOKEN" | xxd | tail -5

Ursache 2: TLS erforderlich, aber Client nicht konfiguriert

Die Aktivierung der Transit-Verschlüsselung ändert die Verbindungsanforderungen grundlegend. Ihr Client muss TLS verwenden, und der Port kann sich je nach Konfiguration ebenfalls ändern.

TLS-Konnektivität mit OpenSSL testen:

openssl s_client -connect \
  my-redis-cluster.abc123.ng.0001.use1.cache.amazonaws.com:6379 \
  -servername my-redis-cluster.abc123.ng.0001.use1.cache.amazonaws.com

Wenn dies mit einer abgelehnten Verbindung oder einem Timeout fehlschlägt, ist TLS auf dem Cluster nicht aktiviert, oder Sie haben ein Problem auf Netzwerkebene. Wenn es erfolgreich ist und Zertifikatsinformationen anzeigt, funktioniert TLS und Ihr Anwendungsclient muss entsprechend konfiguriert werden.

Für Node.js-Anwendungen mit ioredis:

const Redis = require('ioredis');
const client = new Redis({
  host: 'my-redis-cluster.abc123.ng.0001.use1.cache.amazonaws.com',
  port: 6379,
  password: 'my-auth-token-here',
  tls: {} // Dieses leere Objekt aktiviert TLS
});

Der häufigste Fehler, den ich sehe, ist das Vergessen der tls: {}-Option. Ohne sie versucht der Client eine unverschlüsselte Verbindung zu einem TLS-only-Port und erhält einen Connection Reset.

Ursache 3: Probleme bei der Auth-Token-Rotation

ElastiCache unterstützt gleichzeitig zwei aktive Auth-Tokens während der Rotation. Dies ermöglicht Token-Updates ohne Ausfallzeit. Wenn die Rotation jedoch nicht korrekt abgeschlossen wird, können Verbindungen fehlschlagen.

Der Rotationsprozess hat bestimmte Schritte:

# Schritt 1: Neues Auth-Token setzen (alt und neu funktionieren in dieser Phase)
aws elasticache modify-replication-group \
  --replication-group-id my-redis-cluster \
  --auth-token 'new-auth-token-here' \
  --auth-token-update-strategy SET \
  --apply-immediately

# Schritt 2: Warten bis die Änderung abgeschlossen ist
aws elasticache describe-replication-groups \
  --replication-group-id my-redis-cluster \
  --query 'ReplicationGroups[0].Status'

# Schritt 3: Alle Anwendungsinstanzen auf das neue Token aktualisieren

# Schritt 4: Rotation durchführen, damit nur das neue Token gültig ist
aws elasticache modify-replication-group \
  --replication-group-id my-redis-cluster \
  --auth-token 'new-auth-token-here' \
  --auth-token-update-strategy ROTATE \
  --apply-immediately

Der kritische Fehler ist, den ROTATE-Schritt auszuführen, bevor alle Anwendungsinstanzen aktualisiert wurden. Sobald Sie ROTATE ausführen, funktioniert das alte Token sofort nicht mehr. Wenn eine Instanz noch das alte Token verwendet, verliert sie ihre Verbindung.

Ausstehende Änderungen prüfen:

aws elasticache describe-replication-groups \
  --replication-group-id my-redis-cluster \
  --query 'ReplicationGroups[0].PendingModifiedValues'

Ursache 4: Security Group blockiert Port 6379

Selbst bei korrekter Authentifizierung sehen Sie Timeouts statt NOAUTH-Fehler, wenn die Security Group die Verbindung blockiert. Diese Unterscheidung ist wichtig für die Diagnose.

# Security Groups des ElastiCache-Clusters ermitteln
aws elasticache describe-cache-clusters \
  --cache-cluster-id my-redis-cluster-001 \
  --query 'CacheClusters[0].SecurityGroups'

# Security-Group-Regeln prüfen
aws ec2 describe-security-groups \
  --group-ids sg-abc123 \
  --query 'SecurityGroups[0].IpPermissions[?FromPort==`6379`]'

Die Security Group muss eingehenden TCP-Verkehr auf Port 6379 von der Security Group oder dem CIDR-Bereich Ihrer Anwendung erlauben. Ein häufiges Problem nach einer Migration: Die Anwendung ist in ein neues Subnetz oder eine neue VPC umgezogen, aber die ElastiCache-Security-Group referenziert noch die alte Quelle.

# Regel hinzufügen, um die Security Group Ihrer Anwendung zuzulassen
aws ec2 authorize-security-group-ingress \
  --group-id sg-elasticache-123 \
  --protocol tcp \
  --port 6379 \
  --source-group sg-application-456

Ursache 5: Subnet Group in falscher VPC

ElastiCache-Nodes werden in Subnetzen gestartet, die durch die Subnet Group definiert sind. Wenn die Subnet Group in einer anderen VPC als Ihre Anwendung liegt, ist keine Verbindung möglich, unabhängig von den Security-Group-Regeln.

aws elasticache describe-cache-subnet-groups \
  --cache-subnet-group-name my-redis-subnet-group \
  --query 'CacheSubnetGroups[0].{
    VpcId: VpcId,
    Subnets: Subnets[*].{
      SubnetId: SubnetIdentifier,
      AZ: SubnetAvailabilityZone.Name
    }
  }'

Vergleichen Sie diese VPC-ID mit der VPC Ihrer Anwendung. Wenn sie sich unterscheiden, müssen Sie entweder Ihre Anwendung verschieben, einen neuen ElastiCache-Cluster in der richtigen VPC erstellen oder VPC-Peering einrichten.

Ursache 6: Unterschiede bei Cluster-Mode-Verbindungen

ElastiCache Cluster Mode Enabled (CME) und Cluster Mode Disabled (CMD) erfordern unterschiedliche Client-Konfigurationen. Die Verwendung des falschen Verbindungsansatzes verursacht verwirrende Fehler.

Für Cluster Mode Disabled verbinden Sie sich mit dem Primary Endpoint:

aws elasticache describe-replication-groups \
  --replication-group-id my-redis-cluster \
  --query 'ReplicationGroups[0].NodeGroups[0].PrimaryEndpoint'

Für Cluster Mode Enabled müssen Sie den Configuration Endpoint und einen cluster-fähigen Client verwenden:

aws elasticache describe-replication-groups \
  --replication-group-id my-redis-cluster \
  --query 'ReplicationGroups[0].ConfigurationEndpoint'

Die Verwendung eines nicht cluster-fähigen Clients mit einem Cluster-Mode-Enabled-Endpoint führt zu MOVED- oder ASK-Fehlern:

(error) MOVED 5798 10.0.1.42:6379

Dies ist kein Authentifizierungsfehler, wird aber häufig damit verwechselt, weil die Verbindung scheinbar fehlschlägt.

Ursache 7: Parameter-Group-Änderungen erfordern Neustart

Bestimmte Parameteränderungen werden erst nach einem Neustart der Cluster-Nodes wirksam. Wenn Sie kürzlich Parameter bezüglich Authentifizierung oder Netzwerk geändert haben, sind möglicherweise noch die alten Einstellungen aktiv.

# Auf ausstehende Parameteränderungen prüfen
aws elasticache describe-cache-clusters \
  --cache-cluster-id my-redis-cluster-001 \
  --query 'CacheClusters[0].CacheParameterGroup.CacheParameterGroupName'

# Bestimmten Node neu starten, um Änderungen anzuwenden
aws elasticache reboot-cache-cluster \
  --cache-cluster-id my-redis-cluster-001 \
  --cache-node-ids-to-reboot 0001

Ebenso erfordert die Aktivierung der Transit-Verschlüsselung auf einem bestehenden Cluster, dass dieser die In-Place-Verschlüsselungsmigration unterstützt. Nicht alle Engine-Versionen unterstützen dies. Prüfen Sie den Änderungsstatus:

aws elasticache describe-replication-groups \
  --replication-group-id my-redis-cluster \
  --query 'ReplicationGroups[0].TransitEncryptionMode'

Der Wert sollte nach der Aktivierung required sein. Wenn er preferred anzeigt, befindet sich der Cluster in einem Übergangszustand, in dem sowohl TLS- als auch Nicht-TLS-Verbindungen akzeptiert werden.

Ursache 8: Redis-ACL-Benutzer und Berechtigungen

ElastiCache Redis 6.0 und höher unterstützt Redis-ACLs, die eine Berechtigungsebene auf Benutzerebene über die Auth-Tokens hinaus hinzufügen. Wenn ACLs konfiguriert sind, benötigen Sie sowohl den korrekten Benutzernamen als auch das Passwort.

aws elasticache describe-users \
  --query 'Users[*].{
    UserId: UserId,
    UserName: UserName,
    Status: Status,
    AccessString: AccessString,
    Engine: Engine
  }'

aws elasticache describe-user-groups \
  --query 'UserGroups[*].{
    UserGroupId: UserGroupId,
    Status: Status,
    UserIds: UserIds,
    ReplicationGroups: ReplicationGroups
  }'

Wenn ein Benutzer einen restriktiven Access String wie ~app:* +@read hat, kann er nur auf Keys zugreifen, die dem Muster app:* entsprechen, und nur Leseoperationen ausführen. Ein Schreibversuch schlägt mit einem Berechtigungsfehler fehl, der einem Auth-Fehler ähnelt.

Prävention und Best Practices

Speichern Sie Auth-Tokens in AWS Secrets Manager und rotieren Sie sie automatisch. Hardcodieren Sie Tokens niemals in Anwendungskonfigurationen.

Verwenden Sie konsistent das gleiche Security-Group-Referenzmuster. Statt CIDR-basierter Regeln referenzieren Sie die Anwendungs-Security-Group, damit Regeln IP-Änderungen überdauern.

Testen Sie die Konnektivität innerhalb der VPC, bevor Sie Anwendungsänderungen deployen. Verwenden Sie einen Bastion Host oder eine EC2-Instanz im selben Subnetz:

# Von einem Bastion Host in derselben VPC
redis-cli -h my-redis-cluster.abc123.ng.0001.use1.cache.amazonaws.com \
  -p 6379 --tls -a "$REDIS_AUTH_TOKEN" ping

Überwachen Sie Authentifizierungsfehler mit ElastiCache-CloudWatch-Metriken. Die AuthenticationFailures-Metrik steigt an, wenn Clients falsche Tokens senden.

Dokumentieren Sie den Transit-Verschlüsselungsstatus jedes Clusters. Zu wissen, ob TLS erforderlich ist, verhindert stundenlange Fehlersuche, wenn ein neuer Service hinzugefügt wird.

Verwenden Sie den Configuration Endpoint für Cluster Mode Enabled Setups und stellen Sie sicher, dass Ihre Client-Bibliothek das Redis-Cluster-Protokoll unterstützt.

Wann Sie Hilfe holen sollten

ElastiCache-Verbindungsprobleme, die der obigen Diagnose widerstehen, betreffen normalerweise die Komplexität des VPC-Netzwerks — VPC-Peering-Routen, Transit-Gateway-Konfigurationen oder DNS-Auflösungsprobleme innerhalb privater Subnetze. Wir helfen Teams regelmäßig beim Design von ElastiCache-Architekturen, die sicher, performant und wartbar sind. Wenn Ihre Redis-Konnektivität unzuverlässig ist oder Sie eine Migration zu ElastiCache planen, kontaktieren Sie uns für eine kostenlose Beratung. Wir überprüfen Ihre Netzwerkarchitektur und Auth-Konfiguration, um das Problem zu finden.

Brauchen Sie Hilfe mit Ihrer AWS-Infrastruktur?

Buchen Sie ein kostenloses 30-Minuten-Gespräch.

Kostenloses Erstgespräch buchen