Senior AWS Cloud Engineer Interviewfragen

Einführung

In Senior-Interviews für AWS Cloud Engineers geht es meist nicht darum, Services aufzuzählen, sondern Produktionsentscheidungen sauber zu begründen. Sie sollten erklären können, warum eine Architektur funktioniert, wie das Sicherheitsmodell aussieht, welche Kostenfolgen entstehen, wie Failover geplant ist und wie der Betrieb nach dem Launch überwacht wird.

Dieser Leitfaden behandelt senior-gerechte AWS-Interviewfragen mit praxisnahen Antworten zu Architektur, Networking, Compute, Kostenoptimierung, IAM-Sicherheit, Datenbanken, Monitoring und Troubleshooting.

Architektur & Design

1. Entwerfen Sie eine hochverfügbare, mehrschichtige Webanwendung auf AWS.

Antwort: Eine produktionsreife, mehrschichtige Architektur erfordert Redundanz, Skalierbarkeit und Sicherheit:

Loading diagram...

Wichtige Komponenten:

1. DNS & CDN:

# Route 53 für DNS mit Integritätsprüfungen
aws route53 create-health-check \
  --health-check-config IPAddress=203.0.113.1,Port=443,Type=HTTPS

# CloudFront für globale Inhaltsbereitstellung
aws cloudfront create-distribution \
  --origin-domain-name myapp.example.com

2. Load Balancing & Auto Scaling:

# Application Load Balancer erstellen
aws elbv2 create-load-balancer \
  --name my-alb \
  --subnets subnet-12345 subnet-67890 \
  --security-groups sg-12345

# Auto Scaling Group erstellen
aws autoscaling create-auto-scaling-group \
  --auto-scaling-group-name my-asg \
  --launch-template LaunchTemplateName=my-template \
  --min-size 2 \
  --max-size 10 \
  --desired-capacity 4 \
  --target-group-arns arn:aws:elasticloadbalancing:...

3. Datenbank & Caching:

RDS Multi-AZ für hohe Verfügbarkeit
Read Replicas für Leseskalierung
ElastiCache für Sitzungs-/Datencaching

Designprinzipien:

Bereitstellung über mehrere AZs hinweg
Verwenden Sie nach Möglichkeit verwaltete Dienste
Implementieren Sie Auto Scaling
Trennen Sie Schichten mit Sicherheitsgruppen
Verwenden Sie S3 für statische Inhalte

Seltenheit: Sehr häufig Schwierigkeitsgrad: Schwer

2. Erläutern Sie VPC Peering und wann es verwendet werden sollte.

Antwort: VPC Peering verbindet zwei VPCs privat über das AWS-Netzwerk.

Eigenschaften:

Private Konnektivität (kein Internet)
Kein Single Point of Failure
Kein Bandbreitenengpass
Unterstützt regionsübergreifendes Peering
Nicht transitiv (A↔B, B↔C bedeutet nicht A↔C)

Anwendungsfälle:

Verbinden Sie Produktions- und Management-VPCs
Gemeinsame Nutzung von Ressourcen über VPCs hinweg
Multi-Account-Architekturen
Hybrid-Cloud-Konnektivität

# VPC-Peering-Verbindung erstellen
aws ec2 create-vpc-peering-connection \
  --vpc-id vpc-1a2b3c4d \
  --peer-vpc-id vpc-5e6f7g8h \
  --peer-region us-west-2

# Peering-Verbindung akzeptieren
aws ec2 accept-vpc-peering-connection \
  --vpc-peering-connection-id pcx-1234567890abcdef0

# Routing-Tabellen aktualisieren
aws ec2 create-route \
  --route-table-id rtb-12345 \
  --destination-cidr-block 10.1.0.0/16 \
  --vpc-peering-connection-id pcx-1234567890abcdef0

Alternativen:

Transit Gateway: Hub-and-Spoke, transitives Routing
PrivateLink: Service-to-Service-Konnektivität
VPN: Verschlüsselte Konnektivität

Seltenheit: Häufig Schwierigkeitsgrad: Mittel

Erweiterte Rechenleistung

3. Wie funktioniert Auto Scaling und wie optimiert man es?

Antwort: Auto Scaling passt die Kapazität automatisch an die Nachfrage an.

Skalierungsrichtlinien:

1. Zielverfolgung:

{
  "TargetValue": 70.0,
  "PredefinedMetricSpecification": {
    "PredefinedMetricType": "ASGAverageCPUUtilization"
  }
}

2. Step Scaling:

{
  "AdjustmentType": "PercentChangeInCapacity",
  "MetricAggregationType": "Average",
  "StepAdjustments": [
    {
      "MetricIntervalLowerBound": 0,
      "MetricIntervalUpperBound": 10,
      "ScalingAdjustment": 10
    },
    {
      "MetricIntervalLowerBound": 10,
      "ScalingAdjustment": 30
    }
  ]
}

3. Geplante Skalierung:

aws autoscaling put-scheduled-update-group-action \
  --auto-scaling-group-name my-asg \
  --scheduled-action-name scale-up-morning \
  --recurrence "0 8 * * *" \
  --desired-capacity 10

Optimierungsstrategien:

Verwenden Sie Predictive Scaling für bekannte Muster
Legen Sie geeignete Abkühlungsphasen fest
Überwachen Sie Skalierungsmetriken
Verwenden Sie gemischte Instance-Typen
Implementieren Sie Lifecycle Hooks für ein ordnungsgemäßes Herunterfahren

Seltenheit: Sehr häufig Schwierigkeitsgrad: Mittel bis schwer

Serverlos & Erweiterte Dienste

4. Wann würden Sie Lambda vs. EC2 verwenden?

Antwort: Wählen Sie basierend auf den Workload-Eigenschaften:

Verwenden Sie Lambda, wenn:

Ereignisgesteuerte Workloads
Kurz laufende Aufgaben (< 15 Minuten)
Variabler/unvorhersehbarer Traffic
Sie keine Serververwaltung wünschen
Kostenoptimierung für sporadische Nutzung

Verwenden Sie EC2, wenn:

Lang laufende Prozesse
Sie die vollständige Betriebssystemkontrolle benötigen
Spezifische Softwareanforderungen
Konstante hohe Last
Stateful-Anwendungen

Lambda-Beispiel:

import json
import boto3

def lambda_handler(event, context):
    """
    S3-Upload-Ereignis verarbeiten
    """
    s3 = boto3.client('s3')
    
    # Bucket und Schlüssel aus dem Ereignis abrufen
    bucket = event['Records'][0]['s3']['bucket']['name']
    key = event['Records'][0]['s3']['object']['key']
    
    # Datei verarbeiten
    response = s3.get_object(Bucket=bucket, Key=key)
    content = response['Body'].read()
    
    # Etwas mit dem Inhalt tun
    process_data(content)
    
    return {
        'statusCode': 200,
        'body': json.dumps('Verarbeitung abgeschlossen')
    }

Kostenvergleich:

Lambda: Bezahlung pro Anfrage + Dauer
EC2: Bezahlung für Betriebszeit (auch im Leerlauf)

Seltenheit: Häufig Schwierigkeitsgrad: Mittel

Kostenoptimierung

5. Wie optimieren Sie die AWS-Kosten?

Antwort: Eine starke Senior-Antwort behandelt Kostenoptimierung als laufenden Betriebsprozess, nicht als einmalige Aufräumaktion:

Strategien:

1. Richtig dimensionieren (Right-Sizing):

# AWS Compute Optimizer verwenden
aws compute-optimizer get-ec2-instance-recommendations \
  --instance-arns arn:aws:ec2:us-east-1:123456789012:instance/i-1234567890abcdef0

2. Reserved Instances & Savings Plans:

1-Jahres- oder 3-Jahres-Verpflichtungen
Bis zu 72 % Einsparungen gegenüber On-Demand
Für stabile Compute-Lasten nutzen, nachdem Cost-Explorer-Empfehlungen, bestehende Commitments und geplante Änderungen geprüft wurden

3. Spot-Instances:

# Spot-Instances starten
aws ec2 request-spot-instances \
  --spot-price "0.05" \
  --instance-count 5 \
  --type "one-time" \
  --launch-specification file://specification.json

4. S3-Lifecycle-Richtlinien:

{
  "Rules": [
    {
      "Id": "Nach 30 Tagen in IA verschieben",
      "Status": "Enabled",
      "Transitions": [
        {
          "Days": 30,
          "StorageClass": "STANDARD_IA"
        },
        {
          "Days": 90,
          "StorageClass": "GLACIER"
        }
      ]
    }
  ]
}

5. Auto Scaling:

Herunterskalieren außerhalb der Geschäftszeiten
Verwenden Sie Predictive Scaling

6. Überwachung:

AWS Cost Explorer
Budgetwarnungen
Taggen Sie Ressourcen für die Kostenaufteilung

Seltenheit: Sehr häufig Schwierigkeitsgrad: Mittel

Sicherheit & Compliance

6. Wie implementieren Sie Defense in Depth auf AWS?

Antwort: Eine Senior-Antwort sollte präventive Kontrollen, Erkennung und schnelle Reaktion über alle Ebenen verbinden:

Schichten:

1. Netzwerksicherheit:

# VPC mit privaten Subnetzen
# Sicherheitsgruppen (nur erforderliche Ports zulassen)
# NACLs für die Steuerung auf Subnetzebene
# WAF für Anwendungsschutz

# Beispiel: Beschränken Sie SSH nur auf den Bastion Host
aws ec2 authorize-security-group-ingress \
  --group-id sg-app-servers \
  --protocol tcp \
  --port 22 \
  --source-group sg-bastion

2. Identität & Zugriff:

Federation und temporäre Credentials für Menschen und Workloads bevorzugen
MFA erzwingen, wenn langlebige oder Root-Credentials noch existieren
Least Privilege vergeben und ungenutzte Berechtigungen regelmäßig prüfen
IAM Access Analyzer nutzen, um Policies zu validieren und öffentlichen, kontoübergreifenden oder ungenutzten Zugriff zu finden

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-bucket/*",
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": "203.0.113.0/24"
        }
      }
    }
  ]
}

3. Datenschutz:

Verschlüsselung im Ruhezustand (KMS)
Verschlüsselung bei der Übertragung (TLS)
S3-Bucket-Richtlinien
RDS-Verschlüsselung

4. Überwachung & Protokollierung:

# CloudTrail aktivieren
aws cloudtrail create-trail \
  --name my-trail \
  --s3-bucket-name my-bucket

# VPC Flow Logs aktivieren
aws ec2 create-flow-logs \
  --resource-type VPC \
  --resource-ids vpc-12345 \
  --traffic-type ALL \
  --log-destination-type s3 \
  --log-destination arn:aws:s3:::my-bucket

5. Compliance:

AWS Config für die Compliance-Überwachung
Security Hub für zentralisierte Ergebnisse
GuardDuty zur Erkennung von Bedrohungen

Seltenheit: Sehr häufig Schwierigkeitsgrad: Schwer

Datenbankdienste

7. Erläutern Sie RDS Multi-AZ vs. Read Replicas und wann Sie welche verwenden sollten.

Antwort: Beide bieten Redundanz, dienen aber unterschiedlichen Zwecken:

Multi-AZ-Bereitstellung:

Zweck: Hohe Verfügbarkeit und Notfallwiederherstellung
Synchrone Replikation auf Standby in einer anderen AZ
Automatisches Failover (1-2 Minuten)
Gleicher Endpunkt nach dem Failover
Standard-Multi-AZ-DB-Instances bedienen keine Lesezugriffe vom Standby; Multi-AZ-DB-Cluster können lesbare Standbys bieten, daher die genaue RDS-Topologie klären
Erhöht die Kosten für Standby-Kapazität und Storage; gegen Recovery-Anforderungen abwägen

# Multi-AZ-RDS-Instance erstellen
aws rds create-db-instance \
  --db-instance-identifier mydb \
  --db-instance-class db.t3.medium \
  --engine postgres \
  --master-username admin \
  --master-user-password MyPassword123 \
  --allocated-storage 100 \
  --multi-az \
  --backup-retention-period 7

Read Replicas:

Zweck: Skalierung von Lesevorgängen
Asynchrone Replikation
Mehrere Replikate möglich (bis zu 15 für Aurora)
Unterschiedliche Endpunkte für jedes Replikat
Kann sich in verschiedenen Regionen befinden
Kann zu einer eigenständigen Datenbank hochgestuft werden

# Read Replica erstellen
aws rds create-db-instance-read-replica \
  --db-instance-identifier mydb-replica-1 \
  --source-db-instance-identifier mydb \
  --db-instance-class db.t3.medium \
  --availability-zone us-east-1b

# Read Replica zu Standalone hochstufen
aws rds promote-read-replica \
  --db-instance-identifier mydb-replica-1

Vergleichstabelle:

Funktion	Multi-AZ	Read Replica
Replikation	Synchron	Asynchron
Zweck	HA/DR	Leseskalierung
Failover	Automatisch	Manuelle Hochstufung
Endpunkt	Gleich	Unterschiedlich
Regionen	Nur gleiche Region	Regionsübergreifend unterstützt
Leistung	Standard-Multi-AZ für DB-Instances dient der Verfügbarkeit; Multi-AZ-Cluster können lesbare Standbys bieten	Verbessert den Lesedurchsatz bei read-heavy Workloads
Anwendungsfall	Produktionsdatenbanken	Analysen, Berichterstattung

Bewährte Methode: Verwenden Sie beides zusammen

Multi-AZ für hohe Verfügbarkeit
Read Replicas für Leseskalierung

Seltenheit: Sehr häufig Schwierigkeitsgrad: Mittel bis schwer

8. Wie implementieren Sie eine Datenbankmigration mit minimaler Ausfallzeit?

Antwort: Datenbankmigrationsstrategien für Produktionssysteme:

Strategie 1: AWS DMS (Database Migration Service)

# Replikations-Instance erstellen
aws dms create-replication-instance \
  --replication-instance-identifier my-replication-instance \
  --replication-instance-class dms.t3.medium \
  --allocated-storage 100

# Quell-Endpunkt erstellen
aws dms create-endpoint \
  --endpoint-identifier source-db \
  --endpoint-type source \
  --engine-name postgres \
  --server-name source-db.example.com \
  --port 5432 \
  --username admin \
  --password MyPassword123

# Ziel-Endpunkt erstellen
aws dms create-endpoint \
  --endpoint-identifier target-db \
  --endpoint-type target \
  --engine-name aurora-postgresql \
  --server-name target-db.cluster-xxx.us-east-1.rds.amazonaws.com \
  --port 5432 \
  --username admin \
  --password MyPassword123

# Migrationsaufgabe erstellen
aws dms create-replication-task \
  --replication-task-identifier migration-task \
  --source-endpoint-arn arn:aws:dms:us-east-1:123456789012:endpoint:source-db \
  --target-endpoint-arn arn:aws:dms:us-east-1:123456789012:endpoint:target-db \
  --replication-instance-arn arn:aws:dms:us-east-1:123456789012:rep:my-replication-instance \
  --migration-type full-load-and-cdc \
  --table-mappings file://table-mappings.json

Migrationsphasen:

1. Vollständiges Laden:

Kopieren Sie vorhandene Daten
Kann Stunden/Tage dauern
Anwendung verwendet weiterhin Quelle

2. CDC (Change Data Capture):

Replizieren Sie laufende Änderungen
Hält das Ziel synchron
Minimale Verzögerung (Sekunden)

3. Cutover:

# Migrations-Cutover-Skript
import boto3
import time

def perform_cutover():
    """
    Cutover zur neuen Datenbank mit minimaler Ausfallzeit
    """
    # 1. Wartungsmodus aktivieren
    enable_maintenance_mode()
    
    # 2. Warten Sie, bis die Replikationsverzögerung Null ist
    wait_for_replication_sync()
    
    # 3. Anwendungskonfiguration aktualisieren
    update_database_endpoint(
        old_endpoint='source-db.example.com',
        new_endpoint='target-db.cluster-xxx.us-east-1.rds.amazonaws.com'
    )
    
    # 4. Anwendung neu starten
    restart_application()
    
    # 5. Konnektivität überprüfen
    verify_database_connection()
    
    # 6. Wartungsmodus deaktivieren
    disable_maintenance_mode()
    
    print("Cutover abgeschlossen!")

def wait_for_replication_sync(max_lag_seconds=5):
    """Warten Sie, bis die Replikationsverzögerung minimal ist"""
    dms = boto3.client('dms')
    
    while True:
        response = dms.describe_replication_tasks(
            Filters=[{'Name': 'replication-task-id', 'Values': ['migration-task']}]
        )
        
        lag = response['ReplicationTasks'][0]['ReplicationTaskStats']['FullLoadProgressPercent']
        
        if lag < max_lag_seconds:
            print(f"Replikationsverzögerung: {lag}s - Bereit für Cutover")
            break
        
        print(f"Replikationsverzögerung: {lag}s - Warten...")
        time.sleep(10)

Strategie 2: Blue-Green Deployment

# Aurora-Klon erstellen (sofort, Copy-on-Write)
aws rds restore-db-cluster-to-point-in-time \
  --source-db-cluster-identifier production-cluster \
  --db-cluster-identifier staging-cluster \
  --restore-type copy-on-write \
  --use-latest-restorable-time

# Auf Staging testen
# Wenn bereit, DNS/Endpunkte austauschen

Vergleich der Ausfallzeiten:

DMS: < 1 Minute (nur Cutover)
Blue-Green: < 30 Sekunden (DNS-Switch)
Traditionelles Dump/Restore: Stunden bis Tage

Seltenheit: Häufig Schwierigkeitsgrad: Schwer

Überwachung & Fehlerbehebung

9. Wie beheben Sie hohe AWS-Kosten?

Antwort: Die Kostenoptimierung erfordert eine systematische Analyse:

Untersuchungsschritte:

1. Verwenden Sie Cost Explorer:

# Kostenaufschlüsselung nach Dienst abrufen
aws ce get-cost-and-usage \
  --time-period Start=2026-04-01,End=2026-04-30 \
  --granularity MONTHLY \
  --metrics BlendedCost \
  --group-by Type=DIMENSION,Key=SERVICE

# Kosten nach Ressourcentags abrufen
aws ce get-cost-and-usage \
  --time-period Start=2026-04-01,End=2026-04-30 \
  --granularity DAILY \
  --metrics BlendedCost \
  --group-by Type=TAG,Key=Environment

2. Kostenanomalien identifizieren:

import boto3
from datetime import datetime, timedelta

def analyze_cost_anomalies():
    """
    Ungewöhnliche Kostenspitzen identifizieren
    """
    ce = boto3.client('ce')
    
    # Kosten der letzten 30 Tage abrufen
    end_date = datetime.now()
    start_date = end_date - timedelta(days=30)
    
    response = ce.get_cost_and_usage(
        TimePeriod={
            'Start': start_date.strftime('%Y-%m-%d'),
            'End': end_date.strftime('%Y-%m-%d')
        },
        Granularity='DAILY',
        Metrics=['BlendedCost'],
        GroupBy=[{'Type': 'SERVICE', 'Key': 'SERVICE'}]
    )
    
    # Jeden Dienst analysieren
    for result in response['ResultsByTime']:
        date = result['TimePeriod']['Start']
        for group in result['Groups']:
            service = group['Keys'][0]
            cost = float(group['Metrics']['BlendedCost']['Amount'])
            
            # Kosten > 100 $/Tag kennzeichnen
            if cost > 100:
                print(f"⚠️  {date}: {service} = ${cost:.2f}")
    
    return response

# Häufige Kostentreiber
cost_culprits = {
    'EC2': [
        'Überdimensionierte Instances',
        'Leerlaufende Instances',
        'Nicht angehängte EBS-Volumes',
        'Alte Snapshots'
    ],
    'RDS': [
        'Multi-AZ, wenn nicht benötigt',
        'Überdimensionierte Instances',
        'Übermäßige Backup-Aufbewahrung'
    ],
    'S3': [
        'Falsche Speicherklasse',
        'Keine Lifecycle-Richtlinien',
        'Übermäßige Anfragen'
    ],
    'Data Transfer': [
        'Regionsübergreifender Traffic',
        'NAT-Gateway-Nutzung',
        'CloudFront nicht verwendet'
    ]
}

3. Skript zur Ressourcenbereinigung:

#!/bin/bash
# Nicht verwendete Ressourcen finden und melden

echo "=== Nicht angehängte EBS-Volumes ==="
aws ec2 describe-volumes \
  --filters Name=status,Values=available \
  --query 'Volumes[*].[VolumeId,Size,CreateTime]' \
  --output table

echo "=== Leerlaufende EC2-Instances (< 5 % CPU für 7 Tage) ==="
# CloudWatch verwenden, um zu identifizieren
aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUUtilization \
  --dimensions Name=InstanceId,Value=i-1234567890abcdef0 \
  --start-time $(date -u -d '7 days ago' +%Y-%m-%dT%H:%M:%S) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%S) \
  --period 86400 \
  --statistics Average

echo "=== Nicht angehängte Elastic IPs ==="
aws ec2 describe-addresses \
  --filters "Name=domain,Values=vpc" \
  --query 'Addresses[?AssociationId==null].[PublicIp,AllocationId]' \
  --output table

echo "=== Alte Snapshots (> 90 Tage) ==="
aws ec2 describe-snapshots \
  --owner-ids self \
  --query 'Snapshots[?StartTime<=`'$(date -u -d '90 days ago' +%Y-%m-%d)'`].[SnapshotId,StartTime,VolumeSize]' \
  --output table

4. Kostenwarnungen einrichten:

# Budgetwarnung erstellen
aws budgets create-budget \
  --account-id 123456789012 \
  --budget file://budget.json \
  --notifications-with-subscribers file://notifications.json

# budget.json
{
  "BudgetName": "Monthly-Budget",
  "BudgetLimit": {
    "Amount": "1000",
    "Unit": "USD"
  },
  "TimeUnit": "MONTHLY",
  "BudgetType": "COST"
}

Schnelle Erfolge:

Löschen Sie nicht angehängte EBS-Volumes
Stoppen/Beenden Sie leerlaufende EC2-Instances
Verwenden Sie S3 Intelligent-Tiering
Aktivieren Sie S3-Lifecycle-Richtlinien
Verwenden Sie Spot-Instances für nicht kritische Workloads
Richtig dimensionieren Sie überdimensionierte Instances

Seltenheit: Sehr häufig Schwierigkeitsgrad: Mittel

Erweiterte Vernetzung

10. Erläutern Sie AWS Transit Gateway und seine Anwendungsfälle.

Antwort: Transit Gateway ist ein Hub-and-Spoke-Netzwerktopologiedienst, der die Netzwerkarchitektur vereinfacht.

Ohne Transit Gateway:

Loading diagram...

Problem: N² Verbindungen (Mesh-Topologie)

Mit Transit Gateway:

Loading diagram...

Lösung: Hub-and-Spoke (N Verbindungen)

Hauptmerkmale:

Transitives Routing: A→TGW→B→TGW→C funktioniert
Zentralisierte Verwaltung
Unterstützt bis zu 5.000 VPCs
Regionsübergreifendes Peering
Routing-Tabellen für die Traffic-Steuerung

Einrichtung:

# Transit Gateway erstellen
aws ec2 create-transit-gateway \
  --description "Main Transit Gateway" \
  --options AmazonSideAsn=64512,AutoAcceptSharedAttachments=enable

# VPC anhängen
aws ec2 create-transit-gateway-vpc-attachment \
  --transit-gateway-id tgw-1234567890abcdef0 \
  --vpc-id vpc-1234567890abcdef0 \
  --subnet-ids subnet-1234567890abcdef0 subnet-0987654321fedcba0

# Route in VPC-Routing-Tabelle erstellen
aws ec2 create-route \
  --route-table-id rtb-1234567890abcdef0 \
  --destination-cidr-block 10.0.0.0/8 \
  --transit-gateway-id tgw-1234567890abcdef0

# Transit-Gateway-Routing-Tabelle erstellen
aws ec2 create-transit-gateway-route-table \
  --transit-gateway-id tgw-1234567890abcdef0

# Route hinzufügen
aws ec2 create-transit-gateway-route \
  --destination-cidr-block 10.1.0.0/16 \
  --transit-gateway-route-table-id tgw-rtb-1234567890abcdef0 \
  --transit-gateway-attachment-id tgw-attach-1234567890abcdef0

Anwendungsfälle:

1. Multi-VPC-Architektur:

# Beispiel: Zentralisierter Egress
vpc_architecture = {
    'production_vpcs': ['vpc-prod-1', 'vpc-prod-2', 'vpc-prod-3'],
    'shared_services': 'vpc-shared',  # NAT, Proxys usw.
    'on_premises': 'vpn-connection'
}

# Alle Produktions-VPCs leiten den Internet-Traffic über die VPC für gemeinsam genutzte Dienste
# Zentralisierte Sicherheitskontrollen, Protokollierung, NAT

2. Netzwerksegmentierung:

# Separate Routing-Tabellen für verschiedene Umgebungen
# Produktion kann Entwicklung nicht erreichen
# Entwicklung kann gemeinsam genutzte Dienste erreichen

3. Multi-Region-Konnektivität:

# Transit Gateway in us-east-1 erstellen
aws ec2 create-transit-gateway --region us-east-1

# Transit Gateway in eu-west-1 erstellen
aws ec2 create-transit-gateway --region eu-west-1

# Diese verbinden
aws ec2 create-transit-gateway-peering-attachment \
  --transit-gateway-id tgw-us-east-1 \
  --peer-transit-gateway-id tgw-eu-west-1 \
  --peer-region eu-west-1

Kostenüberlegungen:

Attachments und Datenverarbeitung sind kostenpflichtig; Traffic vor der Zentralisierung schätzen
Zentrale Inspection, NAT und regionsübergreifendes Routing können die Rechnung schnell verändern
Aktuelle regionale Preise prüfen, bevor Transit Gateway gegenüber Peering oder PrivateLink gewählt wird

Alternativen:

VPC Peering: Einfacher, günstiger für wenige VPCs
PrivateLink: Service-to-Service-Konnektivität
VPN: Direkte Verbindungen

Seltenheit: Häufig Schwierigkeitsgrad: Schwer

Fazit

Vorstellungsgespräche für erfahrene AWS Cloud Engineers erfordern fundierte technische Kenntnisse und praktische Erfahrung. Konzentrieren Sie sich auf:

Architektur: Mehrschichtige Designs, hohe Verfügbarkeit, Notfallwiederherstellung
Erweiterte Vernetzung: VPC Peering, Transit Gateway, PrivateLink
Rechenleistung: Auto Scaling-Optimierung, Lambda vs. EC2-Entscheidungen
Kostenoptimierung: Richtig dimensionieren, Reserved Instances, Lifecycle-Richtlinien
Sicherheit: Defense in Depth, bewährte IAM-Methoden, Verschlüsselung
Operative Exzellenz: Überwachung, Protokollierung, Automatisierung

Stützen Sie jede Antwort mit einem Produktionsbeispiel: welche Abwägung Sie getroffen haben, welchen Fehlermodus Sie geplant haben, welche Metrik Sie überwacht haben und was Sie als Nächstes verbessern würden.

Frische Karrieretipps

Senior AWS Cloud Engineer Interviewfragen mit Antworten

Einführung

Architektur & Design

1. Entwerfen Sie eine hochverfügbare, mehrschichtige Webanwendung auf AWS.

2. Erläutern Sie VPC Peering und wann es verwendet werden sollte.

Erweiterte Rechenleistung

3. Wie funktioniert Auto Scaling und wie optimiert man es?

Serverlos & Erweiterte Dienste

4. Wann würden Sie Lambda vs. EC2 verwenden?

Kostenoptimierung

5. Wie optimieren Sie die AWS-Kosten?

Sicherheit & Compliance

6. Wie implementieren Sie Defense in Depth auf AWS?

Datenbankdienste

7. Erläutern Sie RDS Multi-AZ vs. Read Replicas und wann Sie welche verwenden sollten.

8. Wie implementieren Sie eine Datenbankmigration mit minimaler Ausfallzeit?

Überwachung & Fehlerbehebung

9. Wie beheben Sie hohe AWS-Kosten?

Erweiterte Vernetzung

10. Erläutern Sie AWS Transit Gateway und seine Anwendungsfälle.

Fazit

Wöchentliche Karrieretipps, die wirklich funktionieren

Wöchentliche Karrieretipps, die wirklich funktionieren

Verwandte Beiträge

Senior GCP Cloud Engineer: Interviewfragen und Antworten

Cloud-Architect-Interviewfragen: Architektur, Migration, Sicherheit

Junior AWS Cloud Engineer Interviewfragen mit Antworten

Hören Sie auf, sich zu bewerben. Beginnen Sie, eingestellt zu werden.

Diesen Beitrag teilen

Überwinden Sie die 75% ATS-Ablehnungsrate