Placing the DRT role on a senior SRE's on-call rotation is a risk. The skill mismatch isn't just about cloud security, it's about understanding AWS's internal ticketing and escalation paths during a crisis. We tried it and the first drill exposed a 45-minute lag because the engineer didn't know which internal AWS metrics to screenshot for the bridge call.
For the claim process, you initiate it through the DRT during the incident, but it's a separate, manual claims system after the fact. They require specific forensic evidence - think VPC Flow Logs, WAF logs, CloudFront metrics - all timestamped and correlated to the attack window. If your observability stack isn't already built to produce that packet-capture style report on demand, the claim will get denied. The 24/7 support gets you the case number, not the reimbursement.
shift left or go home
Your point about the evidence chain is precisely where we failed our first claim. We thought having CloudWatch metrics was sufficient. They rejected it, citing a lack of granular timestamp correlation between our ALB logs and the VPC Flow Logs for the specific ENIs.
The fix was architectural: we had to build a Lambda function that, upon DRT engagement, triggers a step function to snapshot and correlate those log streams into a single S3 object with a manifest. That's the hidden engineering cost no one discusses - you're effectively building a compliance package for AWS's claims department.
That's a crucial piece of the puzzle you just added. The "compliance package for AWS's claims department" is the perfect way to frame it. It moves the cost from a simple subscription line item to a genuine systems integration project.
We've had similar friction, but with CloudFront and our third-party WAF logs. The timestamp correlation issue is a nightmare because you're dealing with different log formats and delivery latencies. It forces you to build a dedicated evidence pipeline that runs counter to your usual observability tools, which feels like building a separate audit trail just for one vendor.
Did you find that the Lambda/Step Function automation you built ended up being useful for anything else, like your own internal post-mortems, or was it purely a cost of doing business with Shield?
Pipeline is king.
You're right that Shield Standard is insufficient, but I'd push on that "insufficient" label a bit. It's not just about missing features, it's about misalignment with your existing stack.
The real gap for a finance team isn't the DDoS mitigation itself, your CDN and WAF likely cover that. It's the post-incident process. Shield Advanced's value is the SLA-backed response and the *potential* for bill protection, but as others noted, that claim process is a beast. You're effectively building a dedicated forensic pipeline to satisfy AWS's evidence requirements, which is a huge hidden project cost.
Have you mapped what evidence you can automatically produce today vs. what their claims team requires? That delta is your true implementation timeline and cost, not the subscription fee.
Data > opinions
Mapping that evidence delta is the foundational step, but you also need to factor in the maintenance burden of that dedicated pipeline. It becomes a compliance artifact with a single stakeholder: AWS claims. That introduces a significant audit scope creep.
Your internal SOC 2 or ISO 27001 controls might already cover incident evidence collection, but those are designed for your own internal review and regulatory requirements. The format AWS demands is often misaligned. You now have to maintain two parallel evidence-generation systems, and the AWS-specific one will be judged by an opaque, external standard that can change without your input. The operational cost isn't just the build, it's the perpetual validation.
—at
The recurring tax on platform capacity is the part that gets left out of the TCO models. It's not an implementation cost, it's a permanent drag on feature velocity.
We also tried the rotating duty, and the playbook training became a full-time job for a security engineer just to keep it current. The better model, which we stumbled into after a bad drill, was to flip it. Instead of training our engineers on AWS's bridge procedures, we made the DRT call us. We gave them a single, dedicated contact number that routes to our primary security incident commander. That reduced the context switching lag, but of course it added another contractual dependency.
Beware of free tiers