Senior AWS Cloud Engineer 面试题

介绍

Senior AWS Cloud Engineer 面试通常考察你如何做生产环境取舍，而不只是能否说出服务名称。你需要说明架构选择、安全模型、成本影响、故障恢复计划，以及上线后如何运营和排查问题。

本指南提供高级 AWS 面试问题和实用回答，覆盖架构、网络、计算、成本优化、IAM 安全、数据库、监控和故障排查。

架构与设计

1. 在 AWS 上设计一个高可用性的多层 Web 应用程序。

回答： 一个生产就绪的多层架构需要冗余、可扩展性和安全性：

Loading diagram...

关键组件：

1. DNS & CDN：

# Route 53 用于 DNS，带健康检查
aws route53 create-health-check \
  --health-check-config IPAddress=203.0.113.1,Port=443,Type=HTTPS

# CloudFront 用于全球内容分发
aws cloudfront create-distribution \
  --origin-domain-name myapp.example.com

2. 负载均衡和自动伸缩：

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

# 创建 Auto Scaling Group
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. 数据库与缓存：

RDS Multi-AZ 用于高可用性
读取副本用于读取扩展
ElastiCache 用于会话/数据缓存

设计原则：

跨多个可用区部署
尽可能使用托管服务
实施自动伸缩
使用安全组隔离层
使用 S3 存储静态内容

常见程度： 非常普遍 难度： 困难

2. 解释 VPC Peering 及其使用场景。

回答： VPC Peering（VPC 对等连接） 使用 AWS 网络私下连接两个 VPC。

特点：

私有连接（无需互联网）
无单点故障
无带宽瓶颈
支持跨区域对等连接
非传递性（A↔B，B↔C 不意味着 A↔C）

使用场景：

连接生产和管理 VPC
跨 VPC 共享资源
多账户架构
混合云连接

# 创建 VPC 对等连接
aws ec2 create-vpc-peering-connection \
  --vpc-id vpc-1a2b3c4d \
  --peer-vpc-id vpc-5e6f7g8h \
  --peer-region us-west-2

# 接受对等连接
aws ec2 accept-vpc-peering-connection \
  --vpc-peering-connection-id pcx-1234567890abcdef0

# 更新路由表
aws ec2 create-route \
  --route-table-id rtb-12345 \
  --destination-cidr-block 10.1.0.0/16 \
  --vpc-peering-connection-id pcx-1234567890abcdef0

替代方案：

Transit Gateway（传输网关）： 中心辐射型，传递路由
PrivateLink： 服务到服务的连接
VPN： 加密连接

常见程度： 常见 难度： 中等

高级计算

3. Auto Scaling 如何工作？如何优化它？

回答： Auto Scaling 根据需求自动调整容量。

伸缩策略：

1. 目标跟踪：

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

2. 步进伸缩：

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

3. 计划伸缩：

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

优化策略：

对已知模式使用预测伸缩
设置适当的冷却时间
监控伸缩指标
使用混合实例类型
实施生命周期挂钩以实现优雅关闭

常见程度： 非常普遍 难度： 中等到困难

无服务器与高级服务

4. 何时使用 Lambda vs EC2？

回答： 根据工作负载特性进行选择：

在以下情况下使用 Lambda：

事件驱动型工作负载
短时间运行的任务（< 15 分钟）
可变/不可预测的流量
希望零服务器管理
针对零星使用的成本优化

在以下情况下使用 EC2：

长时间运行的进程
需要完全的操作系统控制
特定软件要求
持续的高负载
有状态的应用程序

Lambda 示例：

import json
import boto3

def lambda_handler(event, context):
    """
    处理 S3 上传事件
    """
    s3 = boto3.client('s3')
    
    # 从事件中获取存储桶和键
    bucket = event['Records'][0]['s3']['bucket']['name']
    key = event['Records'][0]['s3']['object']['key']
    
    # 处理文件
    response = s3.get_object(Bucket=bucket, Key=key)
    content = response['Body'].read()
    
    # 使用内容做一些事情
    process_data(content)
    
    return {
        'statusCode': 200,
        'body': json.dumps('Processing complete')
    }

成本比较：

Lambda：按请求次数 + 持续时间付费
EC2：按运行时间付费（即使空闲）

常见程度： 常见 难度： 中等

成本优化

5. 如何优化 AWS 成本？

回答： 高级候选人的回答应把成本优化视为持续运营流程，而不是一次性清理：

策略：

1. 调整实例大小：

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

2. 预留实例和 Savings Plans：

1 年或 3 年承诺
与按需实例相比，最多可节省 72%
在检查 Cost Explorer 建议、现有承诺和未来路线图变化后，用于稳定的计算负载

3. Spot 实例：

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

4. S3 生命周期策略：

{
  "Rules": [
    {
      "Id": "Move to IA after 30 days",
      "Status": "Enabled",
      "Transitions": [
        {
          "Days": 30,
          "StorageClass": "STANDARD_IA"
        },
        {
          "Days": 90,
          "StorageClass": "GLACIER"
        }
      ]
    }
  ]
}

5. 自动伸缩：

在非工作时间缩减
使用预测伸缩

6. 监控：

AWS Cost Explorer
预算警报
标记资源以进行成本分配

常见程度： 非常普遍 难度： 中等

安全与合规

6. 如何在 AWS 上实施纵深防御？

回答： 高级回答应在每一层结合预防控制、检测和快速响应：

层：

1. 网络安全：

# 带有私有子网的 VPC
# 安全组（仅允许必要的端口）
# 用于子网级别控制的 NACL
# 用于应用程序保护的 WAF

# 示例：仅将 SSH 限制为堡垒主机
aws ec2 authorize-security-group-ingress \
  --group-id sg-app-servers \
  --protocol tcp \
  --port 22 \
  --source-group sg-bastion

2. 身份与访问：

对人员和工作负载优先使用联合身份和临时凭证
对仍然存在的长期凭证或 root 凭证强制 MFA
授予最小权限，并定期审查未使用权限
使用 IAM Access Analyzer 验证策略，并识别公开、跨账户或未使用访问

{
  "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. 数据保护：

静态加密 (KMS)
传输中加密 (TLS)
S3 存储桶策略
RDS 加密

4. 监控与日志记录：

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

# 启用 VPC Flow Logs
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. 合规：

用于合规监控的 AWS Config
用于集中查找结果的 Security Hub
用于威胁检测的 GuardDuty

常见程度： 非常普遍 难度： 困难

数据库服务

7. 解释 RDS Multi-AZ vs Read Replicas，以及何时使用它们。

回答： 两者都提供冗余，但服务于不同的目的：

Multi-AZ 部署：

目的： 高可用性和灾难恢复
同步复制到不同可用区中的备用数据库
自动故障转移（1-2 分钟）
故障转移后相同的端点
标准 RDS Multi-AZ DB 实例不会从 standby 提供读取；Multi-AZ DB 集群可以提供可读 standby，因此需要明确具体 RDS 拓扑
增加 standby 容量和存储成本；应与恢复要求一起评估

# 创建 Multi-AZ RDS 实例
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

读取副本：

目的： 扩展读取操作
异步复制
多个副本可能（Aurora 最多 15 个）
每个副本不同的端点
可以在不同的区域
可以提升为独立数据库

# 创建读取副本
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

# 将读取副本提升为独立数据库
aws rds promote-read-replica \
  --db-instance-identifier mydb-replica-1

比较表：

特性	Multi-AZ	读取副本
复制	同步	异步
目的	HA/DR	读取扩展
故障转移	自动	手动提升
端点	相同	不同
区域	仅限同一区域	支持跨区域
性能	标准 DB instance Multi-AZ 主要用于可用性；Multi-AZ cluster 可以增加可读 standby	提高读密集型工作负载的读取吞吐量
使用场景	生产数据库	分析、报告

最佳实践： 一起使用

Multi-AZ 用于高可用性
读取副本用于读取扩展

常见程度： 非常普遍 难度： 中等到困难

8. 如何以最小的停机时间实施数据库迁移？

回答： 生产系统的数据库迁移策略：

策略 1：AWS DMS（数据库迁移服务）

# 创建复制实例
aws dms create-replication-instance \
  --replication-instance-identifier my-replication-instance \
  --replication-instance-class dms.t3.medium \
  --allocated-storage 100

# 创建源端点
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

# 创建目标端点
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

# 创建迁移任务
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

迁移阶段：

1. 完全加载：

复制现有数据
可能需要数小时/数天
应用程序仍在使用源数据库

2. CDC（变更数据捕获）：

复制正在进行的更改
使目标数据库保持同步
最小延迟（秒）

3. 切换：

# 迁移切换脚本
import boto3
import time

def perform_cutover():
    """
    以最小的停机时间切换到新数据库
    """
    # 1. 启用维护模式
    enable_maintenance_mode()
    
    # 2. 等待复制延迟为零
    wait_for_replication_sync()
    
    # 3. 更新应用程序配置
    update_database_endpoint(
        old_endpoint='source-db.example.com',
        new_endpoint='target-db.cluster-xxx.us-east-1.rds.amazonaws.com'
    )
    
    # 4. 重新启动应用程序
    restart_application()
    
    # 5. 验证连接
    verify_database_connection()
    
    # 6. 禁用维护模式
    disable_maintenance_mode()
    
    print("切换完成！")

def wait_for_replication_sync(max_lag_seconds=5):
    """等待复制延迟最小"""
    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"复制延迟：{lag}s - 准备好切换")
            break
        
        print(f"复制延迟：{lag}s - 等待...")
        time.sleep(10)

策略 2：蓝绿部署

# 创建 Aurora 克隆（即时，写时复制）
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

# 在暂存环境进行测试
# 准备就绪后，交换 DNS/端点

停机时间比较：

DMS： < 1 分钟（仅切换）
蓝绿： < 30 秒（DNS 切换）
传统转储/恢复： 数小时到数天

常见程度： 常见 难度： 困难

监控与故障排除

9. 如何排除 AWS 成本过高的问题？

回答： 成本优化需要系统分析：

调查步骤：

1. 使用 Cost Explorer：

# 按服务获取成本细分
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

# 按资源标签获取成本
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. 识别成本异常：

import boto3
from datetime import datetime, timedelta

def analyze_cost_anomalies():
    """
    识别异常的成本峰值
    """
    ce = boto3.client('ce')
    
    # 获取过去 30 天的成本
    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'}]
    )
    
    # 分析每项服务
    for result in response['ResultsByTime']:
        date = result['TimePeriod']['Start']
        for group in result['Groups']:
            service = group['Keys'][0]
            cost = float(group['Metrics']['BlendedCost']['Amount'])
            
            # 标记成本 > 100 美元/天
            if cost > 100:
                print(f"⚠️  {date}: {service} = ${cost:.2f}")
    
    return response

# 常见的成本罪魁祸首
cost_culprits = {
    'EC2': [
        '实例过大',
        '空闲实例',
        '未附加的 EBS 卷',
        '旧快照'
    ],
    'RDS': [
        '不需要时使用 Multi-AZ',
        '实例过大',
        '过度备份保留'
    ],
    'S3': [
        '错误的存储类',
        '没有生命周期策略',
        '过多的请求'
    ],
    '数据传输': [
        '跨区域流量',
        'NAT 网关使用',
        '未使用 CloudFront'
    ]
}

3. 资源清理脚本：

#!/bin/bash
# 查找并报告未使用的资源

echo "=== 未附加的 EBS 卷 ==="
aws ec2 describe-volumes \
  --filters Name=status,Values=available \
  --query 'Volumes[*].[VolumeId,Size,CreateTime]' \
  --output table

echo "=== 空闲 EC2 实例（7 天内 CPU < 5%） ==="
# 使用 CloudWatch 识别
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 "=== 未附加的弹性 IP ==="
aws ec2 describe-addresses \
  --filters "Name=domain,Values=vpc" \
  --query 'Addresses[?AssociationId==null].[PublicIp,AllocationId]' \
  --output table

echo "=== 旧快照（> 90 天） ==="
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. 设置成本警报：

# 创建预算警报
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"
}

快速获胜：

删除未附加的 EBS 卷
停止/终止空闲 EC2 实例
使用 S3 Intelligent-Tiering
启用 S3 生命周期策略
对非关键工作负载使用 Spot 实例
调整过度配置的实例大小

常见程度： 非常普遍 难度： 中等

高级网络

10. 解释 AWS Transit Gateway 及其使用场景。

回答： Transit Gateway（传输网关） 是一种中心辐射型网络拓扑服务，可简化网络架构。

没有 Transit Gateway：

Loading diagram...

问题： N² 个连接（网状拓扑）

使用 Transit Gateway：

Loading diagram...

解决方案： 中心辐射型（N 个连接）

主要特点：

传递路由： A→TGW→B→TGW→C 可用
集中管理
最多支持 5,000 个 VPC
跨区域对等连接
用于流量控制的路由表

设置：

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

# 附加 VPC
aws ec2 create-transit-gateway-vpc-attachment \
  --transit-gateway-id tgw-1234567890abcdef0 \
  --vpc-id vpc-1234567890abcdef0 \
  --subnet-ids subnet-1234567890abcdef0 subnet-0987654321fedcba0

# 在 VPC 路由表中创建路由
aws ec2 create-route \
  --route-table-id rtb-1234567890abcdef0 \
  --destination-cidr-block 10.0.0.0/8 \
  --transit-gateway-id tgw-1234567890abcdef0

# 创建 Transit Gateway 路由表
aws ec2 create-transit-gateway-route-table \
  --transit-gateway-id tgw-1234567890abcdef0

# 添加路由
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

使用场景：

1. 多 VPC 架构：

# 示例：集中出口
vpc_architecture = {
    'production_vpcs': ['vpc-prod-1', 'vpc-prod-2', 'vpc-prod-3'],
    'shared_services': 'vpc-shared',  # NAT、代理等
    'on_premises': 'vpn-connection'
}

# 所有生产 VPC 都通过共享服务 VPC 路由互联网流量
# 集中式安全控制、日志记录、NAT

2. 网络分段：

# 针对不同环境的独立路由表
# 生产环境无法访问开发环境
# 开发环境可以访问共享服务

3. 多区域连接：

# 在 us-east-1 中创建 Transit Gateway
aws ec2 create-transit-gateway --region us-east-1

# 在 eu-west-1 中创建 Transit Gateway
aws ec2 create-transit-gateway --region eu-west-1

# 对等连接它们
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

成本考虑因素：

attachment 和数据处理会产生费用，集中化前应估算流量
集中式 inspection、NAT 和跨区域路由可能快速改变账单
在选择 Transit Gateway、VPC Peering 或 PrivateLink 前，检查当前区域价格

替代方案：

VPC Peering： 适用于少数 VPC，更简单、更便宜
PrivateLink： 服务到服务的连接
VPN： 直接连接

常见程度： 常见 难度： 困难

结论

高级 AWS 云工程师面试需要深入的技术知识和实践经验。重点关注：

架构： 多层设计、高可用性、灾难恢复
高级网络： VPC 对等连接、Transit Gateway、PrivateLink
计算： Auto Scaling 优化、Lambda vs EC2 决策
成本优化： 调整实例大小、预留实例、生命周期策略
安全： 纵深防御、IAM 最佳实践、加密
卓越运营： 监控、日志记录、自动化

每个回答都应结合生产示例：你做出的取舍、预判的故障模式、监控的指标，以及下一步会改进什么。

最新职业建议

Senior AWS Cloud Engineer 面试题与答案

介绍

架构与设计

1. 在 AWS 上设计一个高可用性的多层 Web 应用程序。

2. 解释 VPC Peering 及其使用场景。

高级计算

3. Auto Scaling 如何工作？如何优化它？

无服务器与高级服务

4. 何时使用 Lambda vs EC2？

成本优化

5. 如何优化 AWS 成本？

安全与合规

6. 如何在 AWS 上实施纵深防御？

数据库服务

7. 解释 RDS Multi-AZ vs Read Replicas，以及何时使用它们。

8. 如何以最小的停机时间实施数据库迁移？

监控与故障排除

9. 如何排除 AWS 成本过高的问题？

高级网络

10. 解释 AWS Transit Gateway 及其使用场景。

结论

真正有效的每周职业建议

真正有效的每周职业建议

相关文章

Node.js 高级后端面试题

Python 高级后端开发面试题

Go后端开发工程师面试题：实用指南

创建一份让您被录用速度提高60%的简历

分享这篇文章

将简历撰写时间减少90%