As a member of the FinOps organization, Umbrella is excited to sponsor the upcoming FinOps X event in Austin, TX.  Umbrella's mission has always been to help organizations solve one of the most recognized challenges associated with public cloud adoption — cost control and optimization. Every feature of our Umbrella cloud cost management platform has been built by taking a core FinOps market concern and working backward to deliver a capability that fills that need. Our product team works closely with customers from different business segments and companies of all sizes, including Nice and Trax, to identify and address their cloud adoption challenges. We develop solutions that directly address our customers’ needs and provide significant value. Examples include the development of features such as K8s container costs, unit economics, anomaly detection, budgeting, forecasting, and more. These enhancements are  the result of listening and working with our customers to solve their most pressing issues. The FinOps Foundation We’re proud to announce that Umbrella is sponsoring the FinOps Foundation’s premier event, FinOps X. The FinOps Foundation is a program of The Linux Foundation ,dedicated to advancing people who practice the discipline of cloud financial management through best practices, education, and standards. The foundation has developed the FinOps framework, an evolving cloud financial management discipline and cultural practice designed to bring accountability to cloud spend and enable organizations to get maximum value by helping engineering, finance and business teams to collaborate on data-driven spending decisions.  The framework also outlines six guiding principles needed for a successful FinOps journey: Establish a culture of collaboration across IT, product, operations, and finance teams.  Accountability for cloud costs at the feature and product team level A centralized team responsible for purchasing commitments and negotiating vendor agreements.  All teams using cloud infrastructure should have access to timely reports.  Make decisions based on business KPIs.  Take advantage of the cloud's variable cost model. The FinOps journey consists of three iterative phases — Inform, Optimize, and Operate. The Inform phase provides visibility into cloud costs, allocation, budgeting, forecasting, and helps develop shared accountability by showing teams what they spend and why. In the Optimize phase, teams are empowered to take the right optimization actions based on their goals. During  the Operate phase, objectives shared by IT, Finance, and business leadership  are refined to focus and scale operational efforts through continuous improvement by breaking down the silos between teams. To succeed in this journey, an organization must create a culture of FinOps which involves building a Cloud Cost Center of Excellence built around business, financial, and operational stakeholders and defining appropriate governance policies and models. FinOps phases by FinOps Foundation Umbrella has developed a next generation Cloud Cost Management solution that is well aligned with the FinOps Framework and our customers' needs. Let's take a closer look at how Umbrella supports the successful FinOps journey through the inform, optimize and operate phases, as well as aligns with the FinOps Foundation principles.   Inform — Visibility & Allocation Umbrella provides full visibility into AWS, Azure, and GCP costs and usage data. Our dashboards and reporting are easy-to-use and accessible to anyone in the organization, and we process the data every few hours so it’s always up to date.  Using a robust data collection mechanism, we can support complex customer organization structures with multiple organizations, thousands of accounts, and millions of records. Additionally, we've developed advanced reporting capabilities to address some of the most complex challenges organizations face, such as Kubernetes cost monitoring, allocation, and optimization.  With Umbrella, you can analyze Kubernetes clusters usage reports, drill down on node and pod utilization, and breakdown costs by namespaces, deployments and more. Umbrella provides cross-organizational visibility into costs and usage data, tracks business KPIs, and is used by Finance teams for financial reporting, chargebacks, and cost allocation.   Optimize — Rates & Usage Umbrella has developed the most advanced recommendation engine available on the market today. The engine tracks your usage data, utilization metrics, and pricing options across AWS, Azure, and GCP to support your FinOps journey, and pin-point and prioritize optimization efforts.  Umbrella provides immediate (day 0) savings opportunities that go beyond compute and storage rightsizing with personalized cost optimization recommendations, waste trends, and exclusions for over 40 types of waste. Umbrella’s recommendation engine allows our customers to take continuous action to avoid waste, overprovisioning, and save millions of dollars every day. “Umbrella gives us visibility and control on cloud billing at a granularity that we have never seen before. The recommendations that they generate save us a huge amount in our cloud bill.” Rubi Cohen - Cloud Manager, Amdocs Operate — Continuous Improvement & Operations Umbrella for Cloud Cost was developed with design partners which run large scale Enterprise-grade cloud operations, such as Amdocs and Nice. As part of this process, we partnered with leading CCoE teams to learn about their needs and developed the tools to enable cross-team collaboration, continuous improvements in KPIs, and organization accountability for cloud costs. With advanced budgeting, forecasting, and anomaly detection capabilities, we help operations better control cloud spend and respond to usage spikes immediately. ”Umbrella gives me visibility into how much each of my SaaS customers costs within a dynamic microservice architecture . This information is key for our pricing strategy.” Mark Serdze - Director of Cloud Infrastructure, Trax Take your FinOps to the next level with Umbrella Umbrella’s alignment with the vision of the FinOps Foundation strengthens our ability to continue innovating for our customers and developing the best Cloud Cost Management  platform.  By seamlessly combining all cloud spend into a single platform our customers can optimize their cloud architecture across AWS, GCP, and Azure; make data-driven trade-offs; and get a handle on true cloud costs by focusing on FinOps to drive better revenue and profitability.  Getting started is easy! Try Umbrella for Cloud Costs with a 30-day free trial to instantly get an overview of your cloud usage, costs, and expected annual savings — or Book a demo with our Cloud Optimization experts.

96% of companies now use or are in the process of evaluating Kubernetes. As the maturity and complexity of Kubernetes environments grow, costs quickly spiral out of control when an effective strategy for visibility and optimization is not in place. Managing Kubernetes (K8s) Costs is Critical to Realizing Cloud-Driven Revenue Growth The COVID-19 pandemic accelerated digital transformation, driving businesses to double down on the cloud to scale up services and support ‘never-seen-before’ load and demand (e.g., Zoom), and in some cases, efficiently scale down applications in response to changing user patterns (e.g., Uber). As a result, organizations have scrambled to modernize application development processes and re-architect static, on-premises monoliths as agile, microservice-powered cloud apps, fueling the adoption of containers and container orchestration tools like Kubernetes. All major public cloud providers now offer managed K8s services, and according to CNCF’s Annual Survey for 2021, 96% of organizations are already using or evaluating Kubernetes. The promises of Kubernetes are shorter software development and release cycles, easier application upgrades and maintenance, better utilization of cloud resources, on-demand scale, and portability between clouds — all potential drivers of corporate revenue growth. However, in practice, Kubernetes has introduced potent risks to revenue growth, primarily due to the complexity it drives: Lack of internal experience and expertise with K8s architecture and management have forced businesses to invest in training, outside services, and expensive consultant engagements High-profile attacks have heightened concerns about security, driving additional budget and investment against vulnerability testing, hardening, and policy enforcement Engineers and architects, who historically did not have to worry about operational costs, are now on the hook for the financial impact of their code’s resource utilization, their node selections, and pod/container configurations This guide is designed to help your cross-functional Kubernetes value realization team — whether you call it cloud FinOps, your Cloud Center of Excellence, or it is a simple partnering of DevOps and Finance — come together and remove barriers to maximizing the revenue return on your business’ investment in Kubernetes. Inform: Empower Kubernetes Stakeholders with Visibility Relevant to Their Role Stakeholders in managing your Kubernetes deployment costs extend far beyond your end users. Typical K8s cost stakeholder parties include: Application end-users Business unit leaders App users within each line-of-business Your application engineering team Your DevOps team and practitioners Kubernetes admins, engineers, and architects Your Finance or IT Finance team Any formalized FinOps organization with your business or Cloud Center of Excellence Delivering transparency and a single-source-of-truth system for Kubernetes usage data is table stakes for each of these personas, and is required to align business, operations, and DevOps teams. Dashboard, reports, and alerts are all common methodologies of providing visibility, and leading tools will enable customization of views per persona so that each user sees only the data that impacts their role. Specific visibility requirements will vary per persona and per team. Typical requirements include varying levels of granular visibility (from your clusters to their containers) and analytics across all your public clouds, including non-container resources and workloads. From a reporting and dashboards perspective, users demand instant data on current K8s cost trends and forecasted costs. Sophisticated multicloud cost management platforms like Umbrella enable the per-role visibility business stakeholders need by: Visualizing and tracking Kubernetes spending and usage across clusters, namespaces, nodes, and pods Correlating cloud spending with business KPIs Enabling the deepest visibility, analysis, and breakdowns for the costs of non-K8s and Kubernetes cloud components as individual and shared costs, by cost center, and by other levels of categorization and virtual tagging Enabling you to unify Kubernetes label keys and traditional resource tag keys to build a combined allocation model Optimize: Leverage Intelligent Recommendations to Continuously Optimize Kubernetes Costs and Usage After enabling appropriate visibility across all your stakeholders, you and your FinOps team can finally take on the task of optimizing and reducing Kubernetes spending. With comprehensive K8s visibility, you can fine-tune Kubernetes resource allocation — allocating the exact amount of resources required per cluster, namespace/label, node, pod, and container.  Monitoring and configuring your Kubernetes deployments properly will improve infrastructure utilization, reduce instances of overprovisioning, and reduce application infrastructure costs. Actually implementing continuous optimization procedures proves challenging for many organizations, even with enough visibility. Prioritizing optimizations is a challenge, and in many organizations, getting the engineering buy-in and cycles to actually implement the infrastructure changes that have been identified as cost-saving measures is difficult (as evidenced by multiple FinOps Foundation studies that have identified “Getting Engineers to Take Action” as the recurring primary priority of FinOps teams). Umbrella  provides a shared source of cost visibility and cost optimization recommendations, making continuous improvement a scalable task for multi-stakeholder teams by: Making next-step actions to implement optimizations blatantly evident (with explicit management console instructions or CLI commands) Specifically outlining the cost impact of each optimization change Helping your team to Identify anomalies and underutilization at the node and pod level in an ongoing way Check out these tips for maximizing cloud ROI Operate: Formalize Accountability and Allocation for Kubernetes Costs As a FinOps strategy leader, you must gain consensus and instill proper financial control structures for Kubernetes within your organization. FinOps strategies without accountability and alignment are doomed to failure. Financial governance controls further reduce the risk of overspending and improve predictability. This operating phase is where the rubber meets the road as far as what results you will gain from your Kubernetes FinOps efforts. If you have put the right controls in place and have an effective formalized cost management process, your team will be enabled to: Effectively and fully transition from the slow, on-premises CapEx model to the elastic, real-time OpEx model enabled by the cloud Move from the old-world paradigm of Engineering as requestors/Finance as approvers to Engineering and Finance acting as one Rully replace predictable, static hardware spend (with long procurement processes) with predictable budgets for on-demand (instant procurement) container resources All of which helps your organization transition from the antiquated physical infrastructure world with high cost of failure to a paradigm that enables affordable “fast failing” and agile experimentation. But, how do you ensure formalized accountability practices and procedures are in place? We have established that cost efficiency is a shared responsibility, with the FinOps team in charge of standards. Your FinOps stakeholders must stand up the proper guidelines, cost monitoring, alerting, and optimization processes. Within these constructs, Engineering is tasked with making sure their investments are cost-minded and efficient. There are additional specific actions you can take to enforce and enhance accountability and cost allocation practices, through: Organizing resources by application and, when possible, using dedicated clusters for each app Flexibly and strategically defining and assigning namespaces and labels to align usage with cost centers (application, team, or business unit), and unify this approach with traditional resource tagging so you can allocate costs, analyze by cost centers, and perform full allocation across K8s and non-Kubernetes workloads. Making sure that the teams that are driving costs (in DevOps/Engineering) have cost and usage information at hand, in addition to providing these same details to your product, project, and system owners and managers Delivering visibility into which committed-use strategies are in place: this can help incentivize Engineers to leverage Savings-Plan-ready instances over incumbent choices Regularly hosting review sessions with stakeholders to review high level dashboards and socialize the cost impact of optimizations Have a solid and comprehensive Kubernetes showback model in place, and leverage the aforementioned visibility and reporting capabilities (like those enabled by Umbrella) to help your teams understand how they are doing in terms of costs. Chargeback approaches (where stakeholders are directly invoiced for their cloud spend impact) are appropriate for teams that have required visibility and education, but avoid creating a culture of Kubernetes cost shameback — which emphasizes inefficiencies and weaknesses rather than building communication, mentorship, and shared education efforts that enable cross-organizational wins. Above all, create a fluid flow of communication about what efforts are being made,  and what savings results are being achieved. Loudly champion any and all wins and successes. Cloud and Kubernetes cost management tools like Umbrella help automate and centralize much of this work: Automated alerting and reporting can appear within the tools and interfaces your teams already use to show them usage and savings impact without forcing them to regularly open and consult another solution Calculate Kubernetes unit costs and answer the question, “for each dollar spent in K8s, how many dollars of revenue did we generate?” Help Engineers to take ownership of the cost impact of their choices by showing the results of cost-conscious resource provisioning and utilization [CTA id="dcd803e2-efe9-4b57-92d5-1fca2e47b892"][/CTA] Building Your Strategy for Operationally Maximizing K8s ROI A successful financial management strategy for Kubernetes infrastructures in the public cloud — whether on AWS, Azure, or GCP — requires educating and uniting stakeholders from parties as diverse as Finance and DevOps around shared goals and processes. Step 1: Understand Kubernetes Cost Drivers First, stakeholders from each line of business that consumes Kubernetes services and the FinOps governing team must develop at least a basic awareness and understanding of each K8s cost driver’s function and importance (both direct and indirect). Step 2: Align on K8s Optimization Strategy and Tools Next, these same stakeholders can evaluate different strategies for controlling and optimizing costs against each cost driver and identify those that make sense in accordance with the business’ specific focus and goals and objectives. At this time, it also makes sense to evaluate the Umbrella Cloud Cost Management  tool that provides comprehensive, cross-cloud (multicloud) and cross-technology (AWS, Azure, GCP + Kubernetes) visibility, optimization, and forecasting capabilities. Umbrella is often selected at this stage by organizations that are focused specifically on financial management of cloud and Kubernetes, and who prefer to have a single, focused tool that drives cloud and K8s ROI. Step 3: Implement a Continuous Kubernetes Optimization Practice Finally, a FinOps plan for operationalizing the selected strategies in an ongoing manner can be created by leveraging the Inform > Optimize > Operate cyclical framework. Detecting Kubernetes Cost Anomalies “Bill shock” is too common an occurrence for businesses that have invested in Kubernetes. Anomaly detection intelligence will continuously monitor your usage and cost data and automatically and immediately alert relevant stakeholders on your team so they can take corrective action. Anomalies can occur due to a wide variety of factors and in many situations. Common anomaly causes include: A new deployment consuming more resources than a previous one A new pod being added to your cluster Suboptimal scaling rules causing inefficient scale-up Misconfigured (or not configured) pod resource request specifications (for example, specifying GiB instead of MiB) Affinity rules causing unneeded nodes to be added Save your team the pain of end-of-month invoice shock. Any organization running Kubernetes clusters should have mechanisms for K8s anomaly detection and anomaly alerting in place. Umbrella for Kubernetes Cost Management  Umbrella’s cloud cost management solution gives organizations visibility into their Kubernetes costs, down to the node and pod level. By combining Kubernetes costs with non-containerized costs and business metrics, businesses get an accurate view of how much it costs to run a microservice, feature, or application. Umbrella provides granular insights about your Kubernetes deployment that no other cloud cost optimization platform offers, with the ability to easily connect to AWS, Azure and GCP.  Umbrella helps your FinOps and DevOps teams work together to identify and eliminate waste, so you can maximize the value you get from your cloud environments. Try Umbrella with a 30-day free trial. Instantly get an overview of your cloud usage, costs, and expected annual savings.

As the complexity of Kubernetes environments grow, costs can quickly spiral out of control if an effective strategy for optimization is not in place. We've compiled expert recommendations and best practices for running cost-optimized Kubernetes workloads on AWS, Microsoft Azure, and Google Cloud (GCP).   What Is Kubernetes Cost Optimization?   Kubernetes cost optimization is the practice of maintaining Kubernetes infrastructure and workload performance while optimizing cost-efficiency to the max. In other words, it’s a way of improving your Kubernetes performance while maintaining reliability. This entails identifying areas of the Kubernetes environment that are less cost-efficient than others.  Cost optimization strategies include: Minimizing your number of servers and reducing environment services. Autoscaling your application or cluster to meet demands and saving costs by shutting down when demands decrease. Sharing resources across multiple servers.  Optimizing network usage.  Improving node configurations.  Optimizing storage space.  Regularly using sleep more.  The Importance of Kubernetes Cost Optimization   Kubernetes cost optimization is vital because of how much money it can save your organization while improving infrastructure value, operational efficiency, and scalability. It enables you to deliver high quality services while saving money on Kubernetes spend.   Without cost optimization, Kubernetes spend can become inefficient, leading to wasted resources, budgets, and your company time.  Which Factors Contribute to Kubernetes Costs?   Something important to note is that there is no one thing that leads to your Kubernetes bill breaking your budget. The tricky part of Kubernetes cost optimization is that often a lot of very small costs can pile up, unnoticed, in the background. The following are all factors that are likely contributing to your Kubernetes bill:  Compute costs. Since Kubernetes requires compute resources to power workloads and operate the control panel, it can be tricky to keep track of how much you're spending. Monitor how many applications you're running and keep an eye on the number of servers that you join to your clusters – because that's all going on your bill! Storage costs. Kubernetes storage costs vary depending on your chosen storage class and the amount of data you want to store. For example, costs vary enormously depending on if you use HDD or SSD storage.  Network costs. If you're using a public cloud to run Kubernetes, you need to pay networking costs. This includes degrees fees, fees which cloud provides require when you move data from their cloud to another infrastructure.  External cloud service costs. Depending on how many third-party services and APIs you use in your Kubernetes clusters, your external cloud services costs might be quite high. Your bill will increase depending on the type of service, the amount of data or calls exchanged, and the service-specific pricing model.    What Are Kubernetes Cost Optimization Tools?   If you're looking for the best way to improve your Kubernetes spend without spending hours of your time combing through data, you need a Kubernetes optimization tool. Kubernetes optimization tools provide a real-time view into your cloud usage. Expect granular levels of detail about cost and resource allocation, as well as spending anomaly detection and budget forecasting.  A Kubernetes optimization tool can improve anything from organizational visibility into the cloud, task automation for scaling and cost management, deployment scalability, to regular updates and support.  Considering adding a Kubernetes cost improvement tool to your digital suite? Umbrella provides Kubernetes cloud cost management tool to help you optimize your cloud spend so you can put your dollars to work elsewhere.  Gaining Complete Kubernetes Cost Visibility   Gaining visibility into your container cost and usage data is the first step to controlling and optimizing Kubernetes costs. Visibility is critical at each level of your Kubernetes deployment: Clusters Nodes Pods (Namespaces,  Labels, and Deployments) Containers You will also want visibility within each business transaction. Having deep visibility will help you: Avoid cloud “bill shock” (a common compelling incident where stakeholders find out after-the-fact that they have overspent their cloud budget) Detect anomalies Identify ways to further optimize your Kubernetes costs For example, when using Kubernetes for development purposes, visibility helps you identify Dev clusters running during off-business hours so you can pause them. In a production environment, visibility helps you identify cost spikes originating from a deployment of a new release, see the overall costs of an application, and identify cost per customer or line of business. Detecting Kubernetes Cost Anomalies   “Bill shock” is too common an occurrence for businesses that have invested in Kubernetes. Anomaly detection intelligence will continuously monitor your usage and cost data and automatically and immediately alert relevant stakeholders on your team so they can take corrective action. Anomalies can occur due to a wide variety of factors and in many situations. Common anomaly causes include: A new deployment consuming more resources than a previous one A new pod being added to your cluster Suboptimal scaling rules causing inefficient scale-up Misconfigured (or not configured) pod resource request specifications (for example, specifying GiB instead of MiB) Affinity rules causing unneeded nodes to be added Save your team the pain of end-of-month invoice shock. Any organization running Kubernetes clusters should have mechanisms for K8s anomaly detection and anomaly alerting in place — full stop. [CTA id="dcd803e2-efe9-4b57-92d5-1fca2e47b892"][/CTA] Optimizing Pod Resource Requests   Have organizational policies in place for setting pod CPU and memory requests and limits in your YAML definition files. Once your containers are running, you gain visibility into the utilization and costs of each portion of your cluster: namespaces, labels, nodes, and pods. This is the time to tune your resource request and limit values based on actual utilization metrics. Kubernetes allows you to fine-tune resource requests with granularity up to the MiB (RAM) and a fraction of a CPU, so there is no reason to overprovision and end up with low utilization of the allocated resources. Node Configuration    Node cost is driven by various factors, many of which can be addressed at the configuration level. These include the CPU and memory resources powering each node, OS choice, processor type and vendor, disk space and type, network cards, and more.  When configuring your nodes: Use open-source OSes to avoid costly licenses like those required for Windows, RHEL, and SUSE Favor cost-effective processors to benefit from the best price-performance processor option: On AWS, use Graviton-powered instances (Arm64 processor architecture) In GCP, favor Tau instances powered by the latest AMD EPYC processors Pick nodes that best fit your pods' needs. This includes picking nodes with the right amount of vCPU and memory resources, and a ratio of the two that best fits your pod’s requirements. For example, if your containers require resources with a vCPU to memory ratio of 8, you should favor nodes with such a ratio, like: AWS R instances Azure Edv5 VMs GCP n2d-highmem-2 machine types In such a case, you will have specific nodes options per pod with the vCPU and memory ratio needed. Processor Selection   For many years, all three leading cloud vendors offered only Intel-powered compute resources. But, recently, all three cloud providers have enabled various levels of processor choice, each with meaningful cost impacts. We have benefited from the entry of AMD-powered (AWS, Azure, and GCP) and Arm architecture Graviton-powered instances (AWS). These new processors introduce ways to gain better performance while reducing costs. In the AWS case, AMD-powered instances cost 10% less than Intel-powered instances, and Graviton instances cost 20% less than Intel-powered instances. To run on Graviton instances, you should build multi-architecture containers that comply with running on Intel, AMD, and Graviton instance types. You will be able to take advantage of reduced instance prices while also empowering your application with better performance.  Purchasing Options   Take advantage of cloud provider purchasing options. All three leading cloud providers (AWS, GCP, Azure) offer multiple purchasing strategies, such as: On-Demand: Basic, list pricing Commitment-Based: Savings Plans (SPs), Reserved Instances (RIs), and Commitment Use Discounts (CUDs), which deliver discounts for pre-purchasing capacity Spot: Spare cloud service provider (CSP) capacity (when it is available) that offers up to a 90% discount over On-Demand pricing Define your purchasing strategy choice per node, and prioritize using Spot instances when possible to leverage the steep discount this purchasing option provides. If for any reason Spot isn't a fit for your workload — for example, in the case that your container runs a database — purchase the steady availability of a node that comes with commitment-based pricing. In any case, you should strive to minimize the use of On-Demand resources that aren't covered by commitments.  Autoscaling Rules   Set up scaling rules using a combination of horizontal pod autoscaling (HPA), vertical pod autoscaling (VPA), the cluster autoscaler (CA), and cloud provider tools such as the Cluster Autoscaler on AWS or Karpenter to meet changes in demand for applications. Scaling rules can be set per metric, and you should regularly fine-tune these rules to ensure they fit your application's real-life scaling needs and patterns. Kubernetes Scheduler (Kube-Scheduler) Configuration   Use scheduler rules wisely to achieve high utilization of node resources and avoid node overprovisioning. As described earlier, these rules impact how pods are deployed.  In cases such as where affinity rules are set, the number of nodes may scale up quickly (e.g., setting a rule for having one pod per node).  Overprovisioning can also occur when you forget to specify the requested resources (CPU or memory) and instead, only specify the limits. In such a case, the scheduler will seek nodes with resource availability to fit the pod’s limits. Once the pod is deployed, it will gain access to resources up to the limit, causing node resources to be fully-allocated quickly, and causing additional, unneeded nodes to be spun up.  Managing Unattached Persistent Storage   Persistent storage volumes have an independent lifecycle from your pods, and will remain running even if the pods and containers they are attached to cease to exist. Set a mechanism to identify unattached EBS volumes and delete them after a specific period has elapsed. Optimizing Network Usage to Minimize Data Transfer Charges   Consider designing your network topology so that it will account for the communication needs of pods across availability zones (AZs) and can avoid  added data transfer fees. Data transfer charges may also happen when pods communicate across AZs with each other, with the control plan, load balancers, and with other services.  Another approach for minimizing data transfer costs is to deploy namespaces per availability zone (one per AZ), to get a set of single AZ namespace deployments. With such an architecture, pod communication remains within each availability zone, preventing data transfer costs, while allowing you to maintain application resiliency with a cross-AZ, high-availability setup. Minimizing Cluster Counts   When running Kubernetes clusters on public cloud infrastructure such as AWS, Azure, or GCP, you should be aware that you are charged per cluster. In AWS, you are charged $73 per month per cluster you run with Amazon Elastic Kubernetes Service (EKS). Consider minimizing the number of discreet clusters in your deployment to eliminate this additional cost. Mastering Kubernetes Cost Optimization   Now that you have a better understanding of Kubernetes cost optimization strategies, it’s time to implement best practices for maximizing your Kubernetes ROI.  Optimize: Leverage intelligent recommendations to continuously optimize Kubernetes costs and usage After enabling appropriate visibility across all your stakeholders, you and your FinOps team can finally take on the task of optimizing and reducing Kubernetes spending. With comprehensive K8s visibility, you can fine-tune Kubernetes resource allocation — allocating the exact amount of resources required per cluster, namespace/label, node, pod, and container.  Operate: Formalize accountability and allocation for Kubernetes costs  As a FinOps strategy leader, you must gain consensus and instill proper financial control structures for Kubernetes within your organization. FinOps strategies without accountability and alignment are doomed to failure. Financial governance controls further reduce the risk of overspending and improve predictability. This operating phase is where the rubber meets the road as far as what results you will gain from your Kubernetes FinOps efforts. Learn details on these strategies to maximize K8s ROI here Umbrella for Kubernetes Cost Optimization    Umbrella provides granular insights about your Kubernetes deployment that no other cloud optimization platform offers. Easily track your spending and usage across your clusters with detailed reports and dashboards. Umbrella’s powerful algorithms and multi-dimensional filters enable you to deep dive into your performance and identify under-utilization at the node level.  With Umbrella’s continuous monitoring and deep visibility, engineers gain the power to eliminate unpredictable spending. Umbrella automatically learns each service usage pattern and alerts relevant teams to irregular cloud spend and usage anomalies, providing the full context of what is happening for the fastest time to resolution. Umbrella seamlessly combines all of your cloud spend into a single platform so you can optimize your cloud cost and resource utilization across AWS, GCP, and Azure. Transform your FinOps, take control of cloud spend and reduce waste with Umbrella's cloud cost management solution. Getting started is easy! Book a demo to learn more. 

Understanding Kubernetes Cost Drivers Optimizing Kubernetes costs isn’t an easy task. Kubernetes is as deep a topic as cloud (and even more complex), containing subtopics like: Scheduler and kernel processes Resource allocation and monitoring of utilization (at each level of K8s infrastructure architecture) Node configuration (vCPU, RAM, and the ratio between those) Differences between architectures (like x86 and Arm64) Scaling configuration (up and down) Associating billable components with business key performance indicators (KPIs) and much more! That’s a lot for a busy DevOps team to understand and manage, and doesn’t even consider that line-of-business stakeholders and finance team members should have some understanding of each cost driver’s function and importance to contribute to a successful FinOps Strategy. Following is a description of the seven major drivers of Kubernetes costs, the importance and function of each, and how each contributes to your cloud bill. These descriptions should be suitable for the consumption of all business stakeholders, and can be used to drive cross-functional understanding of the importance of each cost driver to Kubernetes FinOps. The Underlying Nodes Most likely, the cost of the nodes you select will drive a large portion of your Kubernetes costs. A node is the actual server, instance, or VM your Kubernetes cluster uses to run your pods and their containers. The resources (compute, memory, etc.) that you make available to each node drive the price you pay when it is running. For example, in Amazon Web Services (AWS), a set of three c6i.large instances running across three availability zones (AZs) in the US East (Northern Virginia) region can serve as a cluster of nodes. In this case, you will pay $62.05 per node, per month ($0.085 per hour). Selecting larger instance sizes, such as c6i.xlarge, will double your costs to $124.1 per node per month. Parameters that impact a node's price include the operating system (OS), processor vendor (Intel, AMD, or AWS), processor architecture (x86, Arm64), instance generation, CPU and memory capacity and ratio, and the pricing model (On-Demand, Reserved Instances, Savings Plans, or Spot Instances). You pay for the compute capacity of the node you have purchased whether your pods and their containers fully utilize it or not. Maximizing utilization without negatively impacting workload performance can be quite challenging, and as a result, most organizations find that they are heavily overprovisioned with generally low utilization across their Kubernetes nodes. [CTA id="03a6f09d-945f-4144-863f-39866f305afb"][/CTA] Request and Limit Specifications for Pod CPU and Memory Resources Your pods are not a billable component, but their configurations and resource specifications drive the number of nodes required to run your applications, and the performance of the workloads within. Assume you are using a c6i.large instance (powered with 2 vCPUs and 4 GiB RAM) as a cluster node, and that 2 GiB of RAM and 0.2 vCPUs are used by the OS, Kubernetes agents, and eviction threshold. In such a case, the remaining 1.8 vCPU and 2 GiB of RAM are available for running your pods. If you request 0.5 GiB of memory per pod, you will be able to run up to four pods on this node. Once a fifth pod is required, a new node will be added to the cluster, adding to your costs. If you request 0.25 GiB of memory per pod, you will be able to run eight pods on each node instance.  Another example of how resource requests impact the number of nodes within a cluster is a case where you specify a container memory limit, but do not specify a memory request. Kubernetes automatically assigns a memory request that matches the limit. Similarly, if you specify a CPU limit, but do not specify a CPU request, Kubernetes will automatically assign a CPU request that matches the limit. As a result, more resources will be assigned to each container than necessarily required, consuming node resources and increasing the number of nodes. In practice, many request and limit values are not properly configured, are set to defaults, or are even totally unspecified, resulting in significant costs for organizations. Persistent Volumes Kubernetes volumes are directories (possibly containing data), which are accessible to the containers within a pod, providing a mechanism to connect ephemeral containers with persistent external data stores. You can configure volumes as ephemeral or persistent. Unlike ephemeral volumes, which are destroyed when a pod ceases to exist, persistent volumes are not affected by the shutdown of pods. Both ephemeral nor persistent are preserved across individual container restarts. Volumes are a billable component (similar to nodes). Each volume attached to a pod has costs that are driven by the size (in GB) and the type of the storage volume attached — solid-state drive (SSD) or hard disk drive (HDD). For example, a 200 GB gp3 AWS EBS SSD volume will cost $16 per month. Affinity and The K8s Scheduler The Kubernetes scheduler is not a billable component, but it is the primary authority for how pods are placed on each node, and as a result, has a great impact on the number of nodes needed to run your pods. Within Kubernetes, you can define node and pod affinity (and pod anti-affinity), which constrains where pods can be placed. You can define affinities to precisely control pod placement, for use cases such as: Dictating the maximum number of pods per node Controlling which pods can be placed on nodes within a specific availability zone or on a particular instance type Defining which types of pods can be placed together and powering countless other scenarios Such rules impact the number of nodes attached to your cluster, and as a result, impact your Kubernetes costs.  Consider a scenario where an affinity is set to limit pods to one per node and you suddenly need to scale to ten pods. Such a rule would force-increase the number of nodes to ten, even if all ten pods could performantly run within a single node.  Data Transfer Costs Your Kubernetes clusters are deployed across availability zones (AZs) and regions to strengthen application resiliency for disaster recovery (DR) purposes, however data transfer costs are incurred anytime pods deployed across availability zones communicate in the following ways: When pods communicate with each other across AZs When pods communicate with the control plane When pods communicate with load balancers, in addition to regular load balancer charges When pods communicate with external services, such as databases When data is replicated across regions to support disaster recovery Network Costs When running on cloud infrastructure, the number of IP addresses that can be attached to an instance or a VM is driven by the size of the instance. For example, an AWS c6i.large instance can be associated with up to three network interfaces, each with up to ten private IPv4 addresses (for a total of 30). A c6i.xlarge instance can be associated with up to four network interfaces, each with up to 15 private IPv4 addresses (for a total of 60).  Now, imagine using a c6i.large instance as your cluster node, while you require over 30 private IPv4 addresses. In such cases, many Kubernetes admins will pick the c6i.xlarge instance to gain the additional IP addresses, but it will cost them double, and the node’s CPU and memory resources will likely go underutilized. Application Architecture Applications are another example of non-billable drivers that have a major impact on your realized Kubernetes costs. Often, engineering and DevOps teams will not thoroughly model and tune the resource usage of their applications. In these cases, developers may specify the amount of resources needed to run each container, but pay less attention to optimizations that can take place at the code and application level to improve performance and reduce resource requirements.  Examples of application-level optimizations include using multithreading versus single-threading or vice versa, upgrading to newer, more efficient versions of Java, selecting the right OS (Windows, which requires licenses, versus Linux), and building containers to take advantage of multiprocessor architectures like x86 and Arm64. Optimizing Kubernetes Costs As the complexity of Kubernetes environments grow, costs can quickly spiral out of control if an effective strategy for optimization is not in place. The key components to running cost-optimized workloads in Kubernetes include: Gaining complete visibility - Visibility is critical at each level of your Kubernetes deployment, including the cluster, node, pod and container levels. Detecting Kubernetes cost anomalies - Intelligent anomaly detection solutions continuously monitor your usage and cost data and immediately alert relevant stakeholders on your team so they can take corrective action. Optimizing pod resource requests - Once your containers are running, you gain visibility into the utilization and cost of each portion of your cluster. This is the time to tune your resource requests and limit values based on actual utilization metrics. Node configuration - Node cost is driven by various factors which can be addressed at the configuration level. These include the CPU and memory resources powering each node, OS choice, processor type and vendor, disk space and type, network cards, and more. Autoscaling rules - Set up scaling rules using a combination of horizontal pod autoscaling (HPA), vertical pod autoscaling (VPA), the cluster autoscaler (CA), and cloud provider tools such as the Cluster Autoscaler on AWS or Karpenter to meet changes in demand for applications. Kubernetes scheduler configuration - Use scheduler rules to achieve high utilization of node resources and avoid node over provisioning. In cases such as where affinity rules are set, the number of nodes may scale up quickly. Umbrella for Kubernetes Cost Management Umbrella’s cloud cost management solution gives organizations visibility into their Kubernetes costs, down to the node and pod level. Easily track your spending and usage across your clusters with detailed reports and dashboards. Umbrella provides granular insights about your Kubernetes deployment that no other cloud cost optimization platform offers.  By combining Kubernetes costs with non-containerized costs and business metrics, businesses get an accurate view of how much it costs to run a microservice, feature, or application. Umbrella’s powerful algorithms and multi-dimensional filters also enable you to deep dive into your performance and identify under-utilization at the node level.  To keep things simple, the solution seamlessly combines all of your cloud spend into a single platform so you can optimize your cloud cost and resource utilization across AWS, GCP, and Azure.

Few organizations remain today without some of their business operating in the cloud. According to a study from 451 Research, part of S&P Global Market Intelligence, 96 percent reported enterprises using or planning to use at least two cloud application providers (Software-as-a-Service), with 45 percent using cloud applications from five or more providers. In 2024, global spending on public cloud services is expected to reach $679 billion, surpassing $1 trillion by 2027. Most companies move to the cloud to take advantage of cloud computing solutions' speed, innovation, and flexibility. Cloud operations can also provide cost savings and improved productivity.  However, controlling cloud costs has become increasingly difficult and complex as cloud adoption grows. That is why cloud cost management has become a priority for CIOs to understand the true ROI for cloud operations.  When cloud assets are fragmented across multiple teams, vendors, and containerized environments, it is easy to lose sight of the budget. As a result, cloud financial management is a must-have for understanding cloud cost and usage data and making more informed cloud-related decisions.  Plus, it's an opportunity for more savings! According to McKinsey, businesses using CFM can reduce their cloud costs by 20% to 30%. But what exactly is Cloud Financial Management (CFM)? Is it merely about cutting costs? What kind of tools are best for multiple cloud environments? If you have these and other questions, we have the answers. Let’s jump in!   Table of Contents: What’s Cloud Financial Management? Cloud Financial Management Benefits  Cloud Financial Management Challenges Building a Cloud Center of Excellence Umbrella for Cloud Financial Management  Umbrella’s 7 Core Features for Cloud Success   [CTA id="6c56537c-2f3f-4ee7-bcc1-1b074802aa4c"][/CTA] <h2id="toc-what">What's Cloud Financial Management? Cloud Financial Management is a system that enables companies to identify, measure, monitor, and optimize finances to maximize return on their cloud computing investments.  CFM also enhances staff productivity, workflow efficiency, and other aspects of cloud management. However, it is important to remember that while cost is a major focus, it’s not the only one.  A subset of CFM is FinOps, which is essentially a combination of Finance and DevOps. The idea behind FinOps is to foster collaboration and communication between the engineering and business teams to align the cost and budget to their technical, business, and financial goals.   Cloud Financial Management Benefits  Better Track Cloud Spend Cloud Financial Management helps companies oversee operations, tasks, and resources that drive usage billing. This insight can be used to identify projects, apps, or teams that are driving your cloud costs. Optimize Cloud Costs With visibility into cloud resources and spend, your organization can identify and remove unutilized resources, redundant integrations, and wasteful processes. Financial Accountability   Instead of reacting to unexpected cost spend and spikes, cloud financial management allows businesses to plan and predict budgets by making delivery teams financially accountable. By aligning cloud financial data to business metrics, organizations can establish common goals and outcomes.  Cloud Financial Management Challenges Budgeting Migrating from on-premise to the cloud often means transitioning from a CapEx to an OpEx model. On the surface, switching to a predictable OpEx-based strategy seems attractive. However, the change can create more issues than it solves.  Optimizing costs is the biggest driver for moving to OpEx. However, cloud spend is vulnerable to waste and overspend if not carefully managed. Many companies haven't reaped the expected cloud benefits due to poor visibility and control. Some have taken the dramatic step of ‘repatriating’ workloads while others have adopted a hybrid approach.  Visibility Into Cloud Assets and Usage Monitoring cloud assets makes or breaks FinOps. But employees often find it challenging to track asset performance, resource needs, and storage requirements. Tagging offers a simple solution, allowing easy categorization of cloud assets by department, performance, usage, costs, and more. Even when you look at the infrastructure, there are numerous departments in an organization, and there are different purposes for them to use the cloud. So, unless and until there is a proper tagging system for these departments, operations, and costs, it is very difficult to monitor cloud assets.  Calculating Unit Costs The unit cost calculation becomes a tedious job, considering the complexity of the cloud infrastructure and the sheer number of assets. In addition, calculating and comparing the investment and the revenue being generated becomes difficult when there are so many multiple interdependencies.  Identifying Inefficiencies Companies that lack full visibility into cloud spend find it difficult to identify where there are inefficiencies, waste, or overuse of resources. The result is that decisions can’t be made regarding the efficient allocation of resources, and companies are in the dark regarding questions such as whether an increase in spend results from business growth or from sheer inefficiencies. Building a Cloud Center of Excellence A Cloud Center of Excellence (CCoE), or FinOps practice, is an important next step for companies using ad hoc methods for cloud cost management. A CCoE provides a roadmap to execute the organization’s cloud strategy and governs cloud adoption across the enterprise. It is meant to establish repeatable standards and processes for all organizational stakeholders to follow in a cloud-first approach. The CCoE has three core pillars: Governance - The team creates policies with cross-functional business units and selects governance tools for financial and risk management. Brokerage - Members of the CCoE help users select cloud providers and architect the cloud solution. Community - It's the responsibility of the CCoE to improve cloud knowledge in the organization and establish best practices through a knowledge base. With those pillars as a foundation, CCoEs are generally responsible for the following activities: Optimizing cloud costs - Managing and optimizing cloud spend is a key task of the CCoE. They are also accountable for tying the strategic goals of the company with the cost of delivery value in the cloud. Managing cloud transformation - In the initial phase of transformation, the CCoE should assess cloud readiness and be responsible for identifying cloud providers. During migration, the team should provide guidance and accurate reports on progress. Enforce cloud policies - Security and regulatory requirements can change frequently in complex and changing cloud ecosystems. It's important that CCoE members enforce security standards and provide operational support across the business. Umbrella for Cloud Financial Management  Umbrella’s Cloud Cost Management solution helps organizations get a handle on their true cloud costs by focusing on FinOps to drive better revenue and profitability. From a single platform, Umbrella provides complete, end-to-end visibility into your entire cloud infrastructure and related billing costs. By tracking cloud metrics alongside revenue and business metrics, Umbrella helps cloud teams grasp the actual cost of their resources. Umbrella's 7 Core Features for Cloud Success   Forecasting and Budgeting with 98.5% Accuracy Use historical data to predict cloud spending and usage based on selected metrics and changing conditions to make necessary adjustments to avoid going into the red. Cost Visibility Manage multi-cloud expenses on AWS, Azure, Google Cloud, and Kubernetes with customizable dashboards, multi-cloud cost tagging, and anomaly detection. Real-Time Cost Monitoring  Monitoring cloud spend is quite different from other organizational costs in that it can be difficult to detect anomalies in real-time. Cloud activity that isn’t tracked in real-time opens the door to potentially preventable runaway costs. Umbrella enables companies to detect cost incidents in real-time and get engineers to take immediate action.  Saving Recommendations Get 80+ CTA recommendations throughout all major cloud providers and enjoy a 40% reduction in annual cloud spending. Real-time Alerts & Detection Eliminate uncertainty surrounding anomalies through precise, targeted notifications and machine learning (ML) models. Stay consistent with cloud activity by analyzing data to accurately differentiate normal fluctuations from actual risks, thereby minimizing false positives. 360° View of the Multicloud Never waste time searching for a spending transaction again. Simplify cost management with an all-in-one platform offering billing flexibility and cost allocation for enterprise and MSP models. AI Tool for Cloud Spending With a simple search, cloud cost management can be automated with CostGPT. Get instant answers to address common cost challenges, including complex pricing models, hidden costs, and inadequate monitoring and reporting. Automatic Savings Trackers Track the effects of applied recommendations using automated savings reports and a savings tracker.   CFM just got a lot easier with Umbrella. Try it out and see the difference.  

While both platforms offer cloud cost management, Umbrella’s continuous monitoring and unit economics empower teams to proactively identify, understand and eliminate waste to significantly reduce cloud spend.

Amazon EC2 Explained Amazon Elastic Compute Cloud (EC2) is one of the core services of AWS, designed to help users reduce the cost of acquiring and reserving hardware.  EC2 represents the compute infrastructure of Amazon's cloud service offerings, providing organizations a customizable selection of processors, storage, networking, operating systems, and purchasing models.  It is known for assisting organizations to simplify and speed up their deployments for less cost and enabling them to increase or decrease capacity as requirements change quickly.  However, the costs associated with instances and features in EC2 can soon get out of control if not properly managed and optimized. The first cost consideration is usually selecting an instance type.  EC2 Instance Types Even for experienced cloud engineers and FinOps practitioners, EC2 pricing is extraordinarily complex. Many options impact cost, with instances optimized for workload categories like compute, memory, accelerated computing, and storage.  The default option for purchasing is on-demand instances, which bills based on seconds or hours of usage but require no long-term commitments. EC2 instances are grouped together into families. Each EC2 family is designed to meet a target application profile in one of these buckets: General Purpose Instances General-purpose instances provide a balance of computing power, memory, and networking resources and can be used for everyday workloads like web servers and code repositories.  Compute Optimized Compute-optimized instances are best suited for applications that benefit from high-performance processors. Memory-Optimized  Memory-Optimized instances deliver faster performance for workloads that process large data sets in memory.  Accelerated Computing Accelerated Computing instances leverage hardware acceleration and co-processors to perform complex calculations and graphics processing tasks. Storage Optimized Storage optimized instances are designed for workloads requiring high performance, sequential read and write access to large-scale datasets.  When considering the cost, each instance type above can vary by region or operating system selections. The Hidden Cost of EC2 While AWS documents the cost of each instance type by region in their EC2 Pricing, getting to the actual price of using these services requires much more consideration. The first thing to consider is the status of the EC2 instance. Customers pay for computing time, disk space, and data traffic if in a running state.  Customers may still incur charges for unattached IPs and any active (not deleted) storage when in a stopped state. Unfortunately, many users mistakenly believe that stopping their servers will stop further costs from accruing, and this is not the case.  Another potential hidden cost of using EC2 is data traffic. AWS calculates data traffic costs by tier, based on a pre-defined volume with traffic falling below the volume incurring less cost and anything above paying more.  Because AWS charges for data traffic at the account level, many manual monitoring processes fall short in projecting actual costs. Considering how many AWS services comprise the AWS account of a large-scale program or company, it's easy to imagine how difficult it would be to monitor and control cloud spending in AWS. How to reduce AWS EC2 Spending Here are some of the best practices to reduce EC2 spending in AWS: EC2 Right-Sizing Many developers fail to consider right-sizing when spinning up AWS resources, but it's a critical component of optimizing AWS costs. AWS also defaults to many flexible but pricey options like On-Demand instances. Choosing a suitable instance type and service tier can significantly reduce cost without impacting performance.  EC2 Generation Upgrade AWS offers different instances tuned specifically for various workloads, as discussed above. When selecting an instance type, look for the latest generation options because they often provide the best performance and pricing.  Unnecessary Data Transfers AWS charges for inter-Availability Zone data transfer between EC2 instances even if they are located in the same region. Whenever possible, co-locate all instances within a single Availability Zone to avoid unnecessary data transfer charges.  Stopped Instances Stopping EC2 instances does not eliminate the potential for charges. Resources attached to stopped instances like EBS volumes, S3 storage, and public IPs continue to accrue costs. Consider terminating attached resources or the instance if it is no longer in use. [CTA id="dcd803e2-efe9-4b57-92d5-1fca2e47b892"][/CTA] Optimize EC2 Cost with Umbrella Umbrella’s Cloud Cost Management solution makes optimization easy. It can easily connect to AWS, Azure and GCP to monitor and manage your spending. Even with multi-cloud environments, Umbrella seamlessly combines all cloud spending into a single platform allowing for a holistic approach to optimization measures.  What makes Umbrella for Cloud unique is how it learns each service usage pattern, considering essential factors like seasonality to establish a baseline of expected behavior. That allows it to identify irregular cloud spend and usage anomalies in real-time, providing contextualized alerts to relevant teams so they can resolve issues immediately.  Proprietary ML-based algorithms offer deep root cause analysis and clear guidance on the steps for remediation. Customers are already using Umbrella to align FinOps, DevOps, and finance teams' efforts to optimize cloud spending.  Accurate forecasting is one of the central pillars of FinOps and cloud cost optimization. Umbrella leverages AI-powered forecasting with deep learning to automatically optimize cloud cost forecasts and enable businesses to react to changing conditions before impacting cost. Rather than manually watching cloud resources and billing, your analysis teams will view cloud metrics with a business context in the same place as revenue and business metrics. That allows FinOps practitioners to optimize cloud investments to drive strategic business initiatives continually.

Amazon S3 Explained Amazon Simple Storage Service (S3) is an essential cornerstone of AWS and among its most popular service offerings. S3 allows tenants to store, secure, and retrieve data from S3 buckets on demand. It is widely used for its high availability, scalability, and performance. It supports six storage classes and several use cases, including website hosting, backups, application data storage, and data lake storage. There are two primary components of Amazon S3: Buckets and Objects. Users create and configure S3 buckets according to their needs, and the buckets store the objects they upload in the cloud. The six storage classes of Amazon S3 and the price differentiation While S3 prides itself on its simplicity of use, choosing the correct storage class isn't always as easy and can have a tremendous impact on costs. The free tier limits storage to 5GB in the standard class, but it's only available for new customers. AWS has six S3 storage classes above the free tier: Standard, Intelligent Tiering, Infrequent Access, One-Zone Infrequent Access, Glacier, and Glacier Deep Archive. Each one offers different features, access availability, and performance. Here is an overview of each class: Standard S3 standard storage is best suited for frequently accessed data. It's elastic in that you only pay for what you use, and customers typically use it for data-intensive content that they want access to at all times, from anywhere. Infrequent Access Storage S3 Infrequent Access Storage is best suited for use cases where data access requirements are ad hoc or infrequent and available quickly when needed. An example could be backup and recovery images for a web or application server. The cost model for infrequent storage is cheaper than standard storage but scales more each time you access the data. One-Zone Infrequent Access The "regular" Infrequent Access Storage ensures the highest availability by distributing data between at least three availability zones within a region. For use cases where data access is infrequent, lower availability is acceptable, but that still need quick retrieval times, One-Zone Infrequent Access Storage is the best option. S3 will store the data in one availability zone, but the cost will be 20% less than Infrequent Access Storage. Intelligent Tiering Amazon offers a premium S3 service called Intelligent Tiering. It analyzes usage patterns and automatically transfers data between Standard and Infrequent tiers based on access requirements. The selling point of this tier is it saves operators the labor of monitoring and transferring the data themselves. That said, it comes with a charge of $.0025 for every thousand items monitored. [CTA id="dcd803e2-efe9-4b57-92d5-1fca2e47b892"][/CTA] Glacier Most customers use S3 Glacier for record retention and compliance purposes. Retrieval requests take hours to complete, making Glacier unsuitable for any use case requiring fast access. That said, the lower cost makes it ideal when access speed isn't a concern. Glacier Deep Archive S3 Glacier Deep Archive offers additional cost savings but carries further data access limitations. Deep archive is best suited for data that customers only need to access 1-2 times per year and when they can tolerate retrieval times upwards of 12 hours. How to Reduce AWS S3 Spending AWS S3 owes its popularity to its simplicity and versatility. It helps companies and customers across the globe store personal files, host websites and blogs, and empower data lakes for analytics. The only downside is the price tag, which can become pretty hefty in a hurry depending on how much data is stored and how frequently it's accessed. Here are some helpful tips for reducing AWS S3 Spend: Use Compression AWS bases so much S3 cost on the amount of data stored, so compressing data before uploading into S3 can reap significant savings. When users need to access the file, they can download it compressed and decompress it on their local machines. Continuously monitor S3 objects and access patterns to catch anomalies and right-size storage class selections Each storage class features different costs, strengths, and weaknesses. Active monitoring to ensure S3 buckets and objects are right-sized into the correct storage class can drastically reduce costs. Remember that you can leverage multiple tiers within the same bucket, so make sure all files have the right tier selected. Remove or downgrade unused or seldom-used S3 buckets One common mistake in managing S3 storage is users will delete the contents of an S3 bucket, leaving it empty and unused. It's best to remove these buckets entirely to reduce costs and eliminate unnecessary system vulnerabilities. Use a dedicated cloud cost optimization service rather than relying only on cloud provider tools The most important recommendation we can make to keep cloud costs under control is to use a dedicated, third-party cost optimization tool instead of relying strictly on the cloud provider. The native cost management tools cloud providers offer do not go far enough in helping customers understand and optimize their cloud cost decisions. - Disable versioning if not required. - Leverage endpoint technologies to reduce data transfer costs. Cloud Cost Management with Umbrella Organizations seeking to understand and control their cloud costs need a dedicated tool. Umbrella's Cloud Cost solutions easily connect to cloud providers like AWS to monitor and manage cloud spending in real-time and alert teams to critical cost-savings recommendations. Here are some of the key features: Umbrella makes lifecycle recommendations in real-time, based on actual usage patterns and data needs. Rather than teams manually monitoring S3 buckets and trying to figure out if and when to switch tiers, Umbrella provides a detailed, staged plan for each object considering patterns of seasonality. Versioning can significantly impact S3 costs because each new version is another file to maintain. Umbrella continuously monitors object versions and provides tailored, actionable recommendations on which versions to keep. Many customers don't realize how uploading files into S3 can significantly impact costs. In particular, large uploads that get interrupted reserve space until completed, resulting in higher charges. Umbrella provides comprehensive recommendations for uploading files and which files to delete in which bucket.  

In this article: What is a Reserved Instance? RI Normalization factor Optimizing AWS EC2 with Umbrella What is a Reserved Instance?   An Amazon EC2 Reserved Instance (RI) is one of the most powerful cost savings tools available on AWS. It’s officially described as a billing discount applied to the use of an on-demand instance in your account. To truly understand what RI is, we need to take a step back and look at the different payment options for AWS. On-Demand – pay as needed. No commitments. Today you can use 1,000 servers and tomorrow it can only be 10 servers. You are charged for what you actually use. Spot - Amazon sells its server Spot. This means Amazon sells its leftover server space that it has not been able to sell without the use of a data center. The server is the same server that they provide with the on-demand option. The significant difference is that Amazon can request the server back at 2 minutes notice (this can cause your services to have an interruption). On the other side, the price can reach a discount of up to 90%. In most cases, the chances of them asking for the servers back is very low (around 5%). Reserved Instances - Simply put, you are committing to Amazon that you are going to use a particular server for a set period of time and in return for a commitment, Amazon will give you a discount that can reach as high as 75%. One of the most confusing things about RI (as opposed to On-Demand and Spot) is that with RI you don’t buy a specific server but your on-demand servers still get the RI discounted rate. What is being committed?   Let’s look at the parameters that affect the height of the RI premise: The period: 1 year 3 year The Payment option: Full up-front Partial up-front No up-front (will charge 1st of each month) Offering Class: Standard Convertible Of course, the longer the commitment, and the upfront payment is higher, the assumption that Amazon offers is more significant. The above graph illustrates different RI options with respect to on-demand and recommending a specific RI that is tailored to each customer’s specific needs. In addition, when you purchase a RI, you are also committing to the following parameters: Platform (Operation system) Instance Type Region The RI is purchased for a specific region and at no point can the region be modified. To be clear, when we commit to Amazon on a particular server, we also have to commit to the operating system, region and, in some cases, instance size. Usually, after a few months the RI usage has improved its on-demand price and after the break-even point, every minute of running is considered “free” in relation to on-demand.   Related content: Read our guide to AWS Pricing Load Balancer Standard or Convertible offering   With RI, you can choose if we want the Standard or Convertible offering class. This decision is based on how much flexibility we need. We can decide how long we are willing to commit to using the RI and we can choose both our form of payment and if we prefer to pay in advance. Obviously, the more committed you can be to Amazon (longer period, prepay, with less change options etc.) the greater the discount you will get. We still need to clarify the differences between Standard and Convertible. In the Offering Class Standard, you commit to specific servers while Convertible is a financial commitment. This means, you commit to spend X money during this time period and are more open to flexibility in terms of the type of server. Below is a comparison from the AWS website about the differences between Convertible and Standard. Now that we have a better understanding of what RI is, we need to understand how to know how much you should commit to Amazon and what kind of commitment meets your needs. As we know, we cannot predict the future, but we can make educated conclusions on the future based on our past activity. It is also important to note that when you commit to RI, you must run the particular server 744 hours a month (assuming there are 31 days). The discount only applies per hour so if you were to run 744 servers in one hour, only one server will get the discount. In addition, it can be difficult to understand how Amazon figures out the charge. For example, if at some point there are 6 servers running together, Amazon can decide to give each server 10 minutes of the RI rate and 50 minutes of standard on-demand rate. The decision which server gets the discounted rate is Amazon’s alone. If a particular account has multiple linked accounts, and the linked account that bought the RI did not utilize the RI at a given time, the RI discount can be applied to another linked account that is under the same payer account. RI Normalization factor   Recently Amazon introduced a special deal for RI running on the Linux operating system. The benefit is that you do not have to commit to the size of the server but rather only to the server type. So assuming I bought m5.large but actually used m5.xlarge, 50% of my server cost would be discounted. The reverse is also true if I bought m5.xlarge but in practice, I ran m5.large it will get the discount (both servers will get the discount). Amazon has created a table, which normalizes server sizes, and it allows you to commit to a number of server-type units rather than size. In order to intelligently analyze which RI is best for you, it is necessary to take all the resources used, convert the sizes to a normalization factor and check how many servers were used every hour, keeping in mind that you will only get the discount for one hour of usage at a time. You also need to deduct RI that you have already purchased to avoid unnecessary additional RI purchases. Additionally, there will be some instances where servers may not run in succession and there is a need to unite between different resources. Lastly, it is also possible that certain servers may run for hours but do not complete a full month. Despite the above complexity and the need to analyze all of these factors, the high discount obtained through RI, may still result in a significant reduction in costs. Umbrella’s algorithm takes all the above factors and data into account, converts the Normalization factor wherever possible, tracks 30 days of history, and uses its expertise to provide the optimal mix for each customer. Undoubtedly, RI is one of the most significant tools for reducing your cloud costs. By building the proper mix of services combined with an understanding of the level of commitment you can safely reduce your cloud costs by tens of percent. Optimizing AWS EC2 with Umbrella   Umbrella’s Cloud Cost Management solution makes optimization EC2 compute services easy. Even with multi-cloud environments, Umbrella seamlessly combines all cloud spending into a single platform allowing for a holistic approach to optimization measures. Umbrella offers built in, easy-to-action cost-saving recommendations specifically for EC2, including: Amazon EC2 rightsizing recommendations EC2 rightsizing EC2 operating system optimization EC2 generation upgrade Amazon EC2 purchasing recommendations EC2 Savings Plans EC2 Reserved Instances Amazon EC2 management recommendations EC2 instance unnecessary data transfer EC2 instance idle EC2 instance stopped EC2 IP unattached Umbrella helps FinOps teams prioritize recommendations by justifying their impact with a projected  performance and savings impact. Umbrella learns each service usage pattern, considering essential factors like seasonality to establish a baseline of expected behavior. That allows it to identify irregular cloud spend and usage anomalies in real-time, providing contextualized alerts to relevant teams so they can resolve issues immediately. Proprietary ML-based algorithms offer deep root cause analysis and clear guidance on steps for remediation.