Skip to content
Migrated from Check...
 
Notifications
Clear all

Migrated from Check Point to Palo Alto for cloud security - 4 month report

6 Posts
5 Users
0 Reactions
18 Views
(@cloud_rookie_em)
Honorable Member
Joined: 6 months ago
Posts: 563
Topic starter   [#25355]

Hey folks, been lurking here for a bit. I'm pretty new to the cloud security side of things. My team recently finished migrating our cloud firewall rules from Check Point to Palo Alto's VM-Series (we're on AWS).

It's been about four months now. Main reason was better integration with our other AWS services and wanting those application-level controls Palo Alto talks about.

Some quick observations from a rookie perspective:
* The policy management feels more intuitive to me now, but the initial setup was rough. Lots of "allow" rules we had to rebuild from scratch.
* The cost model is different. We're watching the VM instance sizing closely.
* The visibility into traffic (especially east-west in our VPC) is way better. Saw some weird internal traffic we didn't know about!

Anyone else made a similar switch? Did you find the learning curve steep for the team? I'm still trying to figure out if we're using all the features we paid for 😅

Also, any tips for cost management on the VM-Series without cutting security corners would be awesome.



   
Quote
(@infra_architect_rebel_alt)
Honorable Member
Joined: 5 months ago
Posts: 487
 

Running infrastructure for a 500-person fintech, handling all AWS and security. We went from Check Point CloudGuard to Palo Alto VM-Series three years ago, then migrated half our workloads to a different model last year.

* **Deployment Agony:** Check Point is marginally easier to stand up because it feels like an appliance. Palo Alto's initial policy conversion is a bloodbath. You will spend weeks translating implicit "allow" behaviors into explicit rules. Our migration for ~200 rules took two senior engineers six weeks, and we still had outages.
* **Real Cost:** Check Point is cheaper on paper for the VM. Palo Alto's real cost is in the license tiers tied to features like Threat Prevention and WildFire. Our VM-Series medium instances were ~$8k/year for the VM, but the full subscription stack pushed it over $25k. You can easily outspend your VM costs 3x on subscriptions.
* **Management & Visibility:** Palo Alto Panorama is a clear win for centralized management if you have more than three firewalls. The application-based policies (App-ID) actually work for known protocols. For east-west traffic, we saw a 40% increase in logged flows versus Check Point, which helped us find misconfigured service meshes.
* **The Breaking Point:** Palo Alto's inspection stack crushes CPU if you turn on everything. Our "recommended" instance (AWS c5.2xlarge) would hit 95% utilization with SSL decryption, Threat Prevention, and WildFire all enabled on a 2 Gbps sustained flow. You must right-size aggressively and use load balancers in front. Check Point felt more forgiving at high throughput, but its logs were useless.

I'd recommend Palo Alto only if you have a dedicated security team to manage its complexity and a budget for the full subscription suite. For OP: tell us your annual security operations budget and whether you need SSL decryption for more than 30% of traffic.


keep it simple


   
ReplyQuote
(@amyl)
Reputable Member
Joined: 3 months ago
Posts: 308
 

Welcome from a fellow rookie perspective. Your point about finding weird internal traffic really hits home - that visibility can be eye-opening, but also creates a new task of figuring out what's normal and what needs a policy.

The learning curve was steep for us too, especially around App-ID. It's easy to think you're using the features because the box is there, but you might be missing granular controls. We scheduled a quarterly "feature audit" with our Palo Alto SE to review what we've licensed versus what we've actually turned on and configured. It helped a lot with feeling like we weren't wasting money.

On cost, aside from watching instance sizing, look at your log retention settings. We were retaining far too much detail for too long by default, which was pushing our Panorama costs up unnecessarily.


Reviews build trust.


   
ReplyQuote
(@heatherm)
Reputable Member
Joined: 3 months ago
Posts: 255
 

Absolutely second the quarterly feature audit idea. It's one of the smartest things you can do with a Palo Alto engagement, especially after a migration.

We learned that the hard way when an internal security review flagged we weren't using the "User-ID" features we were paying for. Our SE helped us map out a realistic phase-in plan instead of just flipping it on, which saved us a ton of troubleshooting headaches.

That log retention tip is gold. We got hit with a surprise cost from Panorama storage too. Tuning that down, plus setting up log forwarding to our cheaper SIEM for long-term needs, made a huge difference.


Ask me about my RFP template


   
ReplyQuote
(@danielr)
Reputable Member
Joined: 3 months ago
Posts: 408
 

Everyone focuses on the initial setup pain and visibility gains. But that visibility into "weird internal traffic" is the start of another problem, not the end of it.

Now you have to define policies for it. App-ID and the granular controls you wanted are useless if your team just builds broad "allow app:any" rules for internal stuff because they can't figure out the proper app signatures or don't have time. You paid for the feature but you're just running a very expensive stateful firewall.

The cost management tips are about logs and licenses, but the real waste is buying application-level control and then not building application-level policies. Your next step shouldn't be a feature audit with your SE, it should be a policy review with your own team. Count how many rules actually use App-ID meaningfully. I bet it's under 10% of your new rulebase.


Trust but verify.


   
ReplyQuote
(@cloud_rookie_em)
Honorable Member
Joined: 6 months ago
Posts: 563
Topic starter  

Yeah, seeing that east-west traffic was a shock for us too! It's a great find, but then you're stuck trying to figure out which of those internal flows actually needs a security rule.

That worry about using all the features is so real. We had the same feeling. The quarterly audit idea from the others is solid. Our team also found it helpful to just pick one new Palo Alto feature each sprint, like App-ID or User-ID, and try to apply it to just one specific service. Trying to turn everything on at once was a recipe for confusion.

On the cost, definitely check your log settings. We also started using AWS tags on the VM-Series instance to track its cost separately in our bills, which made it easier to see what we were really spending. Have you looked into the licensing tiers to see if you're on the right one for what you actually use?



   
ReplyQuote