Let’s be honest- when an infrastructure team gets involved in a FinOps initiative at the beginning, the sentiments are often mixed. Some teams are happy to hear they will have extra hands to manage the AWS bill. They would be glad if someone else handled the commitment calculations and cost allocation questions, among other things.
However, others might feel those meetings are a waste of time on their calendars. Because they know every aspect of the infrastructure, they feel a FinOps Analyst lacks in-depth knowledge and won’t bring much value.
Regardless of where you fall on that spectrum, the value of this initiative doesn't come from spreadsheets- it comes from a shared understanding. So, while I was thinking about my most successful collaborations, I narrowed them down to 6 core principles that turn these meetings into meaningful wins for everyone involved.
1. We Are One Team
The most productive mindset is: "We are on the same team." We are here to discuss, investigate, and most importantly, think together. The goal is to maximize the value of every dollar spent so the business can reinvest those savings in future projects. We encourage you to ask questions, share opinions, or even setbacks so that, together as a team, we can determine the best possible path for your FinOps journey.
2. Second Set of Eyes: Turning Data into Discovery
Cost and usage data often reveal technical "ghosts" that standard monitoring tools might miss. When a FinOps expert looks at a bill, they aren't just looking at dollars; they are looking at behavior. Here are a few examples from my personal experience where a billing discrepancy led to a technical discovery:
- The Failed Automation: A database instance was scheduled to shut down after hours to save costs, but the billing data showed it was running 24/7. This alerted the team that the scheduling logic was quietly failing, allowing them to fix an operational gap they didn't know existed.
- The "Simple" Toggle: A sudden growth in CloudWatch charges was traced back to "Enhanced Observability" for Amazon ECS being enabled. The engineering team hadn't realized that it would add an unexpected $400 to their monthly bill. With the visibility, they were able to make an informed decision that the additional metrics weren't worth the cost.
- The Unexpected Pattern: While reviewing S3 costs, we noticed that ListBucket operations were the primary driver of API request expenses. While the total cost was manageable, the pattern was unexpected for the application's design. This "red flag" in the data tipped off the engineers to an inefficiency in their code’s retrieval logic that they were then able to optimize.
3. Context is King
The more we understand your infrastructure and business goals, the more impactful our recommendations become. We aren't just looking at numbers; we’re looking for the "why" behind the spend. Here are the topics that streamline the conversation:
- The Nature of the Application: Is this a steady-state legacy monolith or a bursty, auto-scaling microservice?
- Environment Purpose: Not all environments are created equal. If we can distinguish between Dev, QA, and Production, we can be much more precise. For example, does your QA environment truly need Multi-AZ high availability, or can we trade a bit of uptime for lower costs?
- Tagging Logic: Do you have a tagging strategy? Understanding what your tags mean and which ones represent cost centers or owners allows us to build reports that actually make sense to your leadership.
- Usage Patterns: If your user base drops off during the summer or on weekends, shouldn't your computing power scale down accordingly? Can we predict the lifecycle of S3 objects?
- Future Plans: Are you planning to migrate from EC2 to Fargate or move to a different region? Knowing this prevents us from locking you into a Reserved Instance and helps us propose a Savings Plan that gives you flexibility.
4. Ask Questions
Don't just listen to recommendations. Ask "Why?"
- "Why is this specific instance type recommended over what we use?"
- "How does this commitment model affect our flexibility?" Engaging in a dialogue ensures the solutions provided are actually feasible for your specific tech stack.
5. Not Every Expense Can (or Should) Be Optimized
An experienced FinOps expert knows that performance and speed-to-market often outweigh cost. If a certain expensive service is critical, tell them. Good FinOps is about informed spending, not just cutting costs. If an expense is necessary, a good expert will recognize that and move on to the next opportunity.
6. Be Honest About Your Bandwidth
Some teams simply don't have the time for deep architectural refactoring.
That is perfectly okay. If you’re short on time: Tell us. We can pivot the focus toward "Low-Hanging Fruit", quick wins like cleaning up unattached disks, adjusting commitment models (RIs/Savings Plans), or deleting orphaned snapshots that require zero code changes.
Furthermore, at CloudZone, we can assign additional capacity from your Max Squad to support your workload during these high-pressure periods.