Thoughts on the extended support contract? Is it ever worth it?

I'm a DevOps lead at a mid-market SaaS company, and we've run Barracuda CloudGen Firewalls in AWS for our production workloads for three years, managing them with Terraform like you.

* **Replacement Timing in Cloud Scenarios:** In our two hardware failures, advanced replacement meant a configured instance was handed to us in their AWS account within 4 hours. The bottleneck was then our own process to import and validate. For a true cloud outage affecting their service portal, your RTO is still tied to Barracuda's own DR, not just the contract.
* **Cost vs. Architectural Redundancy:** The extended support for our primary fleet was about $15k/year more. We spent that difference on a second, passively-synced firewall in another AZ with a lower support tier. A failover event now is a Route 53 change, not a support ticket. For us, that bought more actual resilience.
* **Policy Restoration & Automation:** The crucial detail is that Terraform can build a new instance, but restoring the exact policy state requires a backup. Extended support includes access to their Cloud Guardian for config backups. Without it, you're relying on your own exported config files, and we've had subtle mismatches when reapplying those to a fresh box.
* **Real Support Responsiveness:** The 24/7 phone for extended got an engineer on the line in under 10 minutes for a critical BGP issue. The basic tier, which we use for dev, averages 4-6 hours for an email response during business hours. For a production outage at 2 AM, that delta is everything.

I'd recommend the extended support only for your single, business-critical production firewall where multi-AZ redundancy isn't feasible yet. For any setup where you can run a pair, go basic on both and invest in automated config sync. To decide cleanly, tell us your actual RTO target for the production VPC and whether you have a tested, automated config backup restored recently.

Four hours for an advanced replacement is still four hours of downtime for a critical path. That's a full outage window.

Your redundancy point is the real takeaway. Throwing money at a vendor's premium support instead of building actual fault tolerance is how you stay trapped.

And Terraform with exported config files is fine if you actually test the restore. Everyone loves the idea of automation until they need it and find the JSON drift from six months of manual hotfixes.

You're absolutely right that four hours is still an outage for most business-critical applications. It reinforces that the premium contract isn't a redundancy plan, it's a repair plan.

I'd push back slightly on the idea that buying it keeps you "trapped." For some teams, that 40% extra is cheaper than the engineering time needed to build, test, and maintain a fully automated, cross-AZ redundant setup. The trap is thinking the support contract *is* the architecture.

Your last point about Terraform and config drift is the real gem, though. The contract's value plummets if you can't redeploy fast. If your automation isn't production-ready, the replacement hardware just sits there while you manually untangle things.

Thanks for sharing those real numbers, that's really helpful. I've been wondering about the actual timeline for advanced replacement. So even with the contract, the four-hour clock starts from the moment you get the new instance, and then your own validation process adds to that.

I'm curious about the policy restoration point you were making with Cloud Guardian. If you're already managing with Terraform, are those config backups really worth the extra cost compared to just storing exported configs in your own version control? Or is there something in the backup format that makes restoring policy state more reliable?

Good question on the config backups versus exported configs. The backup format is usually a proprietary archive with the complete system state - think internal device IDs, certificate stores, and that persistent session table you forgot about. If you're restoring to identical hardware or a vendor-provided image, that backup can be a lifesaver.

But that's also the problem. If your Terraform defines the *desired* state and you restore a full backup, you might be resurrecting old config drift you've since corrected. It creates two sources of truth. Personally, I'd only pay for the backup service if my automation pipeline wasn't fully trusted to rebuild from a known-good, version-controlled source.

Has anyone compared the restore success rate from a Cloud Guardian backup versus a fresh Terraform apply? I'm skeptical the backup adds enough reliability to justify the cost if you've already invested in infrastructure-as-code.

That automation angle you brought up is the key part a lot of people miss. You've hit on the exact tension: Terraform builds the box, but the contract restores the state.

If your IaC and policy exports are truly tested and reliable for a full rebuild, the advanced replacement hardware is just a compute resource you could provision yourself. The real value of the extended contract is for those teams where the config backup is their only reliable recovery artifact. If that's not you, that 40% might be better spent on hardening and testing that Terraform restore process.

Exactly. Your gut's on the right track with separate tiers for dev and prod.

That automation angle is where I'd focus. If your Terraform can rebuild the box but restoring the policies is the tricky bit, the value of the extended contract hinges on whether those config backups solve your actual problem. If your policy exports aren't reliable, you're paying them to hand you a resource you can't use quickly.

Have you run a full disaster recovery test from scratch using just your version-controlled configs? The result tells you everything.

The four-hour clock starts when you get their email, not when you finish debugging why their replacement image is a patch version behind. Good luck matching your state.

On config backups, you're asking the right question. The backup isn't more reliable, it's just a different kind of unreliable. It restores *everything*, including the ephemeral state and manual tweaks you were trying to eliminate with Terraform. If your version-controlled exports are solid, the backup is a liability.

Your third point about the Terraform config being able to spin up a new box is the critical path here. You're right, the specific state and policies are the real challenge.

If your policy management is already externalized and versioned, the value of their config backup service diminishes significantly. I've seen teams pay the premium for that backup, only to realize during a test that restoring it overwrote six months of deliberate, version-controlled policy changes with old, forgotten tweaks. The backup becomes a source of technical debt, not a recovery tool.

The 40% premium is justifiable only if your own restore process from version-controlled sources is unreliable or untested. Before you decide, run a timed rebuild of a production-like firewall in a sandbox VPC using only your Terraform and exported configs. The success and duration of that exercise will give you a data-driven answer.