azure未连接
Two of the more challenging causes of an increase in Azure costs are unused and unnecessary resources. Unused and unnecessary resources may not always be the same, even though they can overlap. If we know the difference between these resource categories or when these resources categories overlap then we will see improvements in preventing these from adding to our costs. In addition, when we think about unused resources, we should consider options that we have with Azure to optimize for these, as an unused resource may still be necessary sometimes. In this tip, we’ll look at these topics to assist us with reducing our Azure use.
Azure成本增加的两个更具挑战性的原因是未使用和不必要的资源。 即使未使用和不必要的资源可能会重叠，它们也不一定总是相同的。 如果我们知道这些资源类别之间的区别或这些资源类别何时重叠，那么我们将看到在防止这些资源增加成本方面的改进。 此外，在考虑未使用的资源时，我们应考虑Azure拥有的选项以针对这些资源进行优化，因为有时仍需要使用未使用的资源。 在本技巧中，我们将研究这些主题，以帮助我们减少Azure的使用。
什么是未使用和不必要的资源？ (What Are Unused and Unnecessary Resources?)
When we consider unused resources, which may be impacting our Azure costs, we want to first differentiate between unused and unnecessary while acknowledging that there may be some overlap with these.
当我们考虑未使用的资源时，这可能会影响我们的Azure成本，我们希望首先区分未使用的资源和不必要的资源，同时确认这些资源可能存在一些重叠。
- Unused resources. This category covers resources that serve no function in our architecture for a possible wide variety of reasons, such as their functionality being replaced or the functionality being completely unused (this could be temporary). A common example that we see is a team of developers created a resource that we use, but the team is replaced (or leaves), and a new team replaces the old resource with a new design with different resources. Our architecture uses the new design, but we still have the old design in place, affecting our Azure costs 未使用的资源 。 此类别涵盖由于各种可能的原因而在我们的体系结构中不起作用的资源，例如，其功能已被替换或功能未完全使用（这可能是暂时的）。 我们看到的一个常见示例是，开发人员团队创建了我们使用的资源，但是该团队被替换（或离开），而新团队则用具有不同资源的新设计替换了旧资源。 我们的体系结构使用新设计，但仍然有旧设计，这会影响Azure成本
- Unnecessary resources. This category covers resources that may or may not be in use, but is superfluous for our design – in some cases, functionality has replaced its need, but it still exists. A common example of this would be functionality that we have built and deployed in production, but this functionality has been replaced by other functionality, even if it still exists. In other cases, this type of functionality may be unused by clients, but hasn’t been deprecated. I include this because this category also affects our Azure costs in that we are paying for functionality that is not serving business value 不必要的资源 。 该类别涵盖可能正在使用或可能未使用的资源，但对我们的设计来说是多余的–在某些情况下，功能已取代了其需求，但仍然存在。 一个常见的示例是我们已经在生产中构建和部署的功能，但是即使该功能仍然存在，该功能也已被其他功能替代。 在其他情况下，客户端可能未使用这种类型的功能，但尚未弃用。 我之所以包括在内，是因为该类别还会影响我们的Azure成本，因为我们正在为无法提供业务价值的功能付费
Consider a scenario where we have an App Service that we’ve replaced with a new App Service and we keep the old App Service. It may (or may not) be unused, but the new App Service has made it unnecessary. There may be contexts in which we want to keep this unnecessary resource for a period of time before removing
考虑以下情形：我们拥有一个被新的App Service替换的App Service，而我们保留了旧的App Service。 它可能（也可能没有）未被使用，但是新的App Service使其不必要。 在某些情况下，我们希望在删除之前将这种不必要的资源保留一段时间
We can save on Azure costs by removing unused and unnecessary resources, whereas other candidates may require more insight 我们可以通过删除未使用和不必要的资源来节省Azure成本，而其他候选人可能需要更多的见解
In some cases, a resource may be both unused and unnecessary – extra copies of backups of applications that may not be able to be constructed due to requirements of old platforms are both unused and unnecessary – we couldn’t recreate these if we wanted. These are easy candidates for removal, as they are not used and they are unnecessary.
在某些情况下，资源可能既未使用又是不必要的–由于旧平台的要求而可能无法构建的应用程序备份的额外副本既未使用又是不必要的–如果需要，我们无法重新创建它们。 这些是很容易删除的候选对象，因为它们不使用并且是不必要的。
In the above image, we see an edited image breaking down costs – some of these may be unused while some may be unnecessary. For example, we may find that our use of virtual machines can be replaced with App Services – meaning our virtual machines are unnecessary because we have a superior replacement that will cost us fewer dollars and reduce our Azure costs. And we may also find that after we use App Services, we may find Function Apps serve us better at reducing our costs, making our App Services unnecessary.
在上图中，我们可以看到经过编辑的图像分解了成本–其中一些可能没有使用，而有些则不必要。 例如，我们可能发现我们可以使用App Services替换对虚拟机的使用-这意味着我们的虚拟机是不必要的，因为我们有一个卓越的替代品，它将使我们花费更少的钱并减少我们的Azure成本。 而且，我们可能还会发现，在使用App Services之后，我们可能会发现Function App在降低成本方面更好地为我们服务，从而使我们的App Services不必要。
In a different scenario involving unused resources, we may have virtual machines that we no longer use at all. These may have affiliated storage accounts for data storage, meaning that we can remove both the unused virtual machines and storage accounts once we’ve validated that these resources are no longer used and are impacting our Azure costs. But if we discovered that we used the virtual machines for one hour per day, these resources would only be unused in the context of a time period.
在涉及未使用资源的另一种情况下，我们可能拥有不再使用的虚拟机。 这些可能具有用于数据存储的关联存储帐户，这意味着一旦我们确认不再使用这些资源并影响了Azure成本，我们就可以删除未使用的虚拟机和存储帐户。 但是，如果我们发现每天使用虚拟机一小时，那么这些资源将仅在一定时间范围内未使用。
In general, developers and administrators can keep resources in existence just in case something happens, even if it’s impossible to restore those resources in their past state. Many of us have seen backups from versions of software that no longer exist and shouldn’t exist because they had numerous security problems or bugs, making the storage of these backups pointless. Even in these situations where we feel it may be obvious that storage won’t assist, we may still receive some pushback due to past habits.
通常，即使无法恢复以前的状态，开发人员和管理员也可以保留资源， 以防万一 。 我们中的许多人都已经看到了不再存在且不应存在的软件版本的备份，因为它们存在许多安全问题或错误，从而使这些备份的存储毫无意义。 即使在这些情况下，我们似乎很明显认为存储无用，但由于过去的习惯，我们可能还会收到一些推销。
固定费用与每次使用费用 (Flat Cost vs. Cost Per Use)
When we think about Azure costs, we should also consider a flat cost versus cost per use with resources. One of the best ways to avoid the challenge of unused and unnecessary resources is prevention and our design with flat costs or cost per use is one way to prevent this problem. An example is the Azure virtual machine model of pay-as-you-go versus reserved virtual machines (note that Azure will sometimes update its pages, so the comparison was present at the time of this article). What we term as unused in the example of virtual machines may be the fact that clients only need the virtual machine on 2 hours per day, so we have 22 hours of unused resource use. By contrast, we may need the virtual machine on every hour of the day because we know the pattern of use is throughout the day. In the pay-as-we-go model, we pay for capacity use, whereas with the reserved model, we have the equivalent of a contract with a virtual machine that we use.
在考虑Azure成本时，我们还应该考虑固定成本与资源使用成本之间的关系。 避免未使用和不必要的资源的挑战的最佳方法之一就是预防，而我们采用固定成本或每次使用成本的设计是防止此问题的一种方法。 一个示例是即付即用与保留虚拟机的Azure虚拟机模型（请注意，Azure有时会更新其页面，因此在本文撰写之时进行了比较）。 在虚拟机示例中我们所谓的未使用 ，可能是因为客户端每天仅需要2小时使用一次虚拟机，因此我们有22个小时未使用的资源。 相比之下，我们可能一天中的每个小时都需要虚拟机，因为我们知道一天中的整个使用模式。 在按需付款模型中，我们为容量使用付费，而在保留模型中，我们具有与使用的虚拟机的合同。
While we may be tempted to reduce our Azure costs by encouraging the use of pay-as-we-go with all resources, we must remember that the pay-as-we-go model may not always be an option with resources and that we may receive a better deal with the reserved model. As we see from Microsoft, we may receive up to a 72% price reduction if we can predict our costs ahead of time. We can think about both of these models in the context of unit and security tests on a virtual machine where both the pay-as-we-go model and the reserved model may work for us with various testing scenarios:
尽管我们可能会通过鼓励对所有资源使用现收现付的方式来降低Azure成本，但我们必须记住，现收现付模型可能并不总是资源的一种选择，而我们可能会更好地处理保留的模型。 正如我们从Microsoft看到的那样，如果我们可以提前预测成本，则价格可能会降低72％。 我们可以在虚拟机上进行单元测试和安全测试的情况下考虑这两种模型，即按需付款模型和保留模型都可以在各种测试场景下为我们工作：
- If our unit and security tests run on a cadence that is a few times per month, we will more than likely choose to pay-as-we-go. This is because we’ll be able to reduce our Azure costs by paying for the few times a month when we use the resources 如果我们的单元测试和安全测试以每月几次的节奏进行，则我们很可能选择按需付费。 这是因为我们可以通过每月使用资源几次来减少Azure成本
If we constantly run unit and security tests throughout the day and re-use the same virtual machine for all testing, we may prefer to use reserved instances since the reserved instances will cost us less if our use is predictable in the context of a budget
如果我们全天不间断地运行单元测试和安全测试，并在所有测试中重复使用同一虚拟机，则我们可能更喜欢使用预留实例，因为如果在预算范围内可以预测使用实例，那么预留实例将减少我们的花费
If our VM had this must idle time, the pay-as-we-go model would help us reduce our Azure costs 如果我们的虚拟机有一定的闲置时间，那么按需付费模型将帮助我们减少Azure成本
In general, I recommend reviewing the Azure cost material and comparing it with your needs along with testing ahead of time to ensure that our choice is correct. The below questions also make a good starting point when we comparing the options of pay-as-we-go versus reserved in situations where these are options:
通常，我建议检查Azure成本材料，并将其与您的需求进行比较，并提前进行测试，以确保我们的选择正确。 在比较现收现付选项和预留选项的情况下，以下问题也是一个很好的起点：
- Are we in the proof-of-concept state or have we already proven this concept? 我们是处于概念验证状态还是已经证明了这一概念？
- Do we have an estimate of our expected load and how could we show that (the latter part being more appropriate for startups)? With startups that don’t have any estimates of load, the pay-as-we-go model for Azure costs may be more appropriate if the budget is also unknown 我们是否估计了预期的负载？我们如何证明这一点（后一部分更适合于初创企业）？ 对于没有任何负载估算的初创公司，如果预算也不明的话，Azure成本的按需付费模型可能更合适
- Do we have a set budget for a year or longer and is this subject to be changed quickly? Reserved can be cheaper, but we’re also committed 我们是否有设定一年或更长的预算，并且此主题会Swift更改吗？ 预留可以便宜一些，但我们也承诺
- Are we moving to Azure from on-premise? Since this scenario means we have data points on our load, the reserved model may be more appropriate, unless our on-premise application is cyclical 我们是否要从本地迁移到Azure？ 由于这种情况意味着我们的负载上有数据点，因此保留的模型可能更合适，除非内部部署应用程序是周期性的
结论 (Conclusion)
As we’ve seen, unused and unnecessary resources in Azure may pose problems to our Azure costs. By identifying how these resource categories can differ along with situations where these resource categories overlap, we’ve seen design methods for reducing these from existing in the from the beginning. By considering models of cost-per-use versus flat costs, we’ve seen that we can prevent some of these issues before they begin. We’ve also seen why we want to consider our workloads, as we may get much better pricing with flat costs when we know this during our design.
如我们所见，Azure中未使用和不必要的资源可能会给我们的Azure成本带来问题。 通过确定这些资源类别如何变化以及这些资源类别重叠的情况，我们从一开始就看到了减少这些资源的设计方法。 通过考虑按使用成本与固定成本的模型，我们已经看到，在这些问题开始出现之前，我们可以防止它们发生。 我们还了解了为什么要考虑工作负载，因为在设计过程中知道这一点后，我们可能会以固定成本获得更好的定价。
目录 (Table of contents)
| 具有安全性和设计注意事项的Azure成本跟踪 |
| 使用扩展和标签控制Azure成本 |
| 用户安全和Azure成本风险 |
| 使用PowerShell提取Azure成本 |
| 通过成本管理跟踪Azure成本 |
| 处理影响Azure成本的未使用和不必要的资源 |
| 查找影响Azure成本的未使用资源 |
| 我们可能需要更高的Azure成本的情况 |
翻译自: https://www.sqlshack.com/handling-unused-and-unnecessary-resources-impacting-azure-costs/
azure未连接
228
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
