评估带宽时，需要以业务流量模型为基础，分别考虑日常流量、峰值流量和促销（秒杀）场景的瞬时并发。要收集并分析历史访问日志（PV/UV、平均会话时长、单请求大小、图片与视频比例）来估算平均和峰值带宽需求。
先算出平均并发用户与峰值并发用户，然后根据每个用户平均每秒请求数与响应包大小计算带宽。例如：峰值并发10,000，单次响应平均50KB，每秒请求率0.2次，则峰值带宽≈10,000×0.2×50KB≈100MB/s≈800Mbps。
静态资源（图片、JS、CSS、视频）通常占用大量带宽，应评估静态资源比例并优先使用CDN来削减源站带宽。
建议在估算带宽基础上预留30%~100%的冗余（视促销强度而定），并结合自动扩缩容、弹性网络带宽或按需提升方案来保证短时峰值。
ALB和NLB各有优劣：ALB支持七层路由、基于内容的转发、WebSocket和更丰富的健康检查，适用于HTTP/HTTPS场景；NLB适用于超高吞吐、低延迟的TCP/UDP流量与静态IP需求。电商多数为HTTP/HTTPS，首选ALB，但在极端并发或需要保持二层兼容时可引入NLB。
如果要做基于路径或主机的流量分发、WebSocket会话或WAF集成，应使用ALB。为提升并发处理能力，可使用多AZ部署与多个目标组、启用HTTP/2、调优超时与连接复用。
当需要每秒数十万到百万级连接、极低延迟或静态弹性IP时，选择NLB并在目标上做接入层转发，再由应用层处理HTTP逻辑。
常见做法是外层使用NLB接流量并做TCP层的快速分发，内层用ALB或直接到服务做应用层转发，或将ALB前端放在CloudFront后面以减少源站压力。
在日本及全球电商场景中，使用CDN（如Amazon CloudFront）可以显著削减源站带宽并降低延迟。关键是合理缓存策略、文件压缩与合并，以及图片/视频的按需转码与自适应分发。
针对静态文件设置长TTL（如7天或更长），对促销页、首页等常变内容使用Cache-Control与版本化文件名（例如带时间戳或hash），以避免频繁回源。
启用gzip或brotli压缩、合并小文件、使用Sprite或现代打包工具，图片使用WebP/AVIF并按客户端能力提供不同分辨率，从而降低每次请求的带宽占用。
使用Lambda@Edge可在CDN边缘实现A/B测试、重写URL、动态压缩与鉴权，减少源站频繁计算和回源次数，间接降低带宽压力。
多AZ部署可以提高可用性，但会带来内部东-西向（AZ间）网络流量，需要考虑数据同步、会话保持与跨AZ费用。负载均衡器通常自动处理跨AZ流量，但数据层（数据库、缓存）的同步流量会占用带宽并增加延迟。
如果使用主从或多主数据库，备份与同步流量在高写场景会消耗大量带宽。建议在日本区域内部使用同区域只读副本或将缓存（如ElastiCache）尽量本地化，减少跨AZ频繁同步。
粘性会话（Session Stickiness）会影响负载均衡效率。推荐将会话状态外置到Redis或DynamoDB，以便任意可用区的应用实例都能无状态处理请求，从而优化负载均衡使用。
分析AZ间流量费用并考虑使用私有子网内传输、合并同步任务、异步复制或批量传输以降低跨AZ带宽成本。
监控与自动化策略是保障促销期间稳定性的核心。需要在多个层面设置指标、告警与自动化动作，包括ELB/ALB的请求数、目标健康情况、EC2或ECS的CPU/内存/网络I/O、CloudFront缓存命中率等。
关注如下指标：ALB请求数(RequestCount)、目标响应时间(TargetResponseTime)、目标健康(TargetHealthyHostCount)、EC2网络入/出量(NetworkIn/NetworkOut)、CloudFront命中率(CacheHitRate)。基于这些指标设置多级告警并触发扩缩容。
结合AWS Auto Scaling设置基于CPU、请求数或自定义CloudWatch指标的扩容策略。为保证扩容速度，可预留冷启动池（预热实例）或使用Warm Pool机制，避免促销突发流量导致拉伸时间过长。
在大型促销前进行压测并预热CDN、负载均衡和后端实例；对负载均衡的连接数上限、目标组容量和健康检查进行模拟，确保在真实高并发下能快速扩容并维持健康。
