惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

美团技术团队
W
WeLiveSecurity
Stack Overflow Blog
Stack Overflow Blog
L
LangChain Blog
S
SegmentFault 最新的问题
Apple Machine Learning Research
Apple Machine Learning Research
Google DeepMind News
Google DeepMind News
F
Full Disclosure
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
The Register - Security
The Register - Security
G
Google Developers Blog
C
Check Point Blog
GbyAI
GbyAI
A
About on SuperTechFans
V
Vulnerabilities – Threatpost
T
The Blog of Author Tim Ferriss
T
Tor Project blog
AWS News Blog
AWS News Blog
Cyberwarzone
Cyberwarzone
C
CERT Recently Published Vulnerability Notes
MongoDB | Blog
MongoDB | Blog
Latest news
Latest news
aimingoo的专栏
aimingoo的专栏
U
Unit 42
Y
Y Combinator Blog
P
Privacy International News Feed
Cisco Talos Blog
Cisco Talos Blog
S
Securelist
S
Schneier on Security
雷峰网
雷峰网
cs.CV updates on arXiv.org
cs.CV updates on arXiv.org
Attack and Defense Labs
Attack and Defense Labs
P
Proofpoint News Feed
C
Cisco Blogs
Webroot Blog
Webroot Blog
T
Troy Hunt's Blog
Google Online Security Blog
Google Online Security Blog
月光博客
月光博客
P
Privacy & Cybersecurity Law Blog
Security Archives - TechRepublic
Security Archives - TechRepublic
罗磊的独立博客
Cloudbric
Cloudbric
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
Recent Commits to openclaw:main
Recent Commits to openclaw:main
Application and Cybersecurity Blog
Application and Cybersecurity Blog
Hacker News: Ask HN
Hacker News: Ask HN
H
Hackread – Cybersecurity News, Data Breaches, AI and More
博客园 - 司徒正美
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
Microsoft Security Blog
Microsoft Security Blog

Datadog | The Monitor blog

Introducing our open source AI-native SAST Instrument and monitor Boomi integration flows with OpenTelemetry and Datadog Not all index scans are equal: How we cut query latency by over 99% Platform engineering metrics: What to measure and what to ignore Integrate Recorded Future threat intelligence with Datadog Cloud SIEM CI/CD security: threat modeling using a MITRE-style threat matrix CI/CD security: How to secure your GitHub ecosystem Ingress NGINX is EOL: A practical guide for migrating to Kubernetes Gateway API Operating agentic AI with Amazon Bedrock AgentCore and Datadog LLM Observability: Lessons from NTT DATA Introducing the Datadog Code Security MCP Capture and analyze custom heatmaps in Session Replay Understand session replays faster with AI summaries and smart chapters Monitor ClickHouse query performance with Datadog Database Monitoring How we designed empathetic alert sounds for on-call engineers Search and act across Datadog to resolve issues faster with Bits Assistant Measure the business impact of every product change with Datadog Experiments Analyzing round trip query latency Configuring JavaScript caches for better performance Introducing Bits AI Dev Agent for Code Security Datadog achieves ISO 42001 certification for responsible AI Monitor Nutanix clusters, hosts, and VMs with Datadog Monitor Juniper Mist in Datadog A new Host Map for modern infrastructure Annotate traces to improve LLM quality with Datadog LLM Observability What’s new in Cloud SIEM: AI-powered investigations, enhanced threat intelligence, and scalable security operations Explore Kubernetes with native OpenTelemetry data Monitor Oracle Fusion Cloud Applications with Datadog Announcing the Datadog Terraform provider v4.0.0 Scaling Kubernetes workloads on custom metrics How to design cloud environments for AI-powered threat analysis Monitor Aruba Central in Datadog How we centralize and remediate risks with Datadog Case Management Accelerate incident response with Datadog and ServiceNow Monitor your application and network load balancer logs Understanding Karpenter architecture for Kubernetes autoscaling Tools for collecting metrics and logs from Karpenter Monitor Karpenter with Datadog What your product data is actually saying Key metrics for monitoring Karpenter Securing Datadog’s platform in the AI age: The role of observability data Four ways engineering teams use the Datadog MCP Server to power AI agents Approaching your observability migration with the right mindset Meet the new Bits AI SRE: Deeper reasoning, twice as fast Key learnings from the 2026 State of DevSecOps study Use plain English to query your multi-cloud infrastructure in Resource Catalog Simplifying troubleshooting across the user journey with Datadog Synthetic Monitoring Protect your OCI resources with Datadog Cloud Security This Month in Datadog - February 2026 Amazon EC2 security: How misconfigured and public AMIs expand your cloud attack surface Enable end-to-end visibility into your Java apps with a single command Measure and improve mobile app startup performance with Datadog RUM Evaluating our AI Guard application to improve quality and control cost Identify untested code across every level of your codebase Make use of guardrail metrics and stop babysitting your releases Monitor Versa Networks SD-WAN performance in Datadog Improve performance and reliability with APM Recommendations Remediate transitive vulnerabilities faster with Datadog Software Composition Analysis Generate audit-ready vulnerability and compliance reports with Datadog Sheets Monitor Fortinet FortiManager performance in Datadog Improve test coverage across codebases with Datadog Code Coverage Move fast, don’t break things: Consistent testing standards at scale Enrich logs with ServiceNow CMDB context before routing to any SIEM or logging tool Monitor Lustre with Datadog Make faster, better product decisions with Datadog Product Analytics Surface and remediate runtime posture issues with Workload Protection Findings Protect agentic AI applications with Datadog AI Guard How to optimize JavaScript code with CSS Trace Google Pub/Sub workloads in Cloud Run with Datadog Detect human names in logs with ML in Sensitive Data Scanner How we cut our NLQ agent debugging time from hours to minutes with LLM Observability Debug PostgreSQL query latency faster with EXPLAIN ANALYZE in Datadog Database Monitoring Datadog acquires Propolis Unify and correlate frontend and backend data with retention filters Scale compliance across global frameworks with Datadog Cloud Security Monitor Arista VeloCloud SD-WAN performance with Datadog Building reliable dashboard agents with Datadog LLM Observability Simplify log collection and aggregation for MSSPs with Datadog Observability Pipelines Mitigation for Node.js denial-of-service vulnerability affecting Datadog APM Automate flaky test fixes with the Bits AI Dev Agent and Test Optimization How we built an AI SRE agent that investigates like a team of engineers Datadog integrations 2025 recap: Observability for AI, security, and hybrid cloud Design effective executive dashboards with Datadog Implement dbt data quality checks with dbt-expectations Bring faster visibility into AWS Lambda functions with remote instrumentation Troubleshoot faster with the GitLab Source Code integration in Datadog How Cambia Health Solutions saved $30,000 monthly with Cloud Cost Management and the Datadog Resource Catalog Normalize any logs for Cloud SIEM with Datadog's OCSF processor Optimizing Datadog at scale: Cost-efficient observability at Zendesk Detect, diagnose, and resolve network issues easily with CNM Network Health Connect engineering errors to user impact in early-stage products Cilium configuration for Kubernetes operations at scale Designing feedback loops for progressive delivery Ship features faster and safer with Datadog Feature Flags Choosing the right OpenTelemetry Collector distribution Route your monitor alerts with Datadog monitor notification rules Automate Cloud SIEM investigations with Bits AI Security Analyst Cloud threat detection: How to identify risky activity across control and data planes Collecting Kafka performance metrics Monitoring Kafka with Datadog Monitoring Kafka performance metrics
Are all AWS ECUs created equal?
Alexis Lê-Quôc · 2013-08-28 · via Datadog | The Monitor blog
Alexis Lê-Quôc

Alexis Lê-Quôc

While Amazon Web Services (AWS) has a large number of physical servers under management, it does not rent them per se. Rather AWS grants access to these servers in the form of virtual machines, which they call EC2 instances.

Renting instances instead of physical has a number of advantages: it allows AWS to keep its product line the same even if the underlying hardware gets bigger, better and faster every year. As users of servers, we have been accustomed to having a measure to compare servers with one another. Does the same apply to EC2 instances?

To standardize its compute to create various instance types and account for Moore’s Law, AWS created a logical computation unit known as an Elastic Compute Unit (ECU). Unlike units commonly used in engineering, there are scant public details about what an ECU precisely is.

The performance you receive, and the price you pay for an EC2 instance is impacted by the way that AWS has split up compute into these abstracted “chunks” of virtual CPU. In this post we look at the data publicly available about ECUs and draw conclusions about relative performance and price.

Noted Differences in AWS ECU Performance

ECUs equate to a certain amount of computing cycles in a way that is purportedly independent of the actual hardware – 1 ECU is defined as the compute power of a 1.0-1.2Ghz of a 2007 server CPU. As an example, the most common and oldest instance type, m1.large, is rated at 4 ECUs (2 cores of 2 ECUs each). A beefier instance with 64GB of memory, m2.4xlarge, suitable for most databases, is rated at 26 ECUs (8 cores of 3.25 ECUs each). http://ec2instances.info has a very handy summary of the various instance types and their ECU rating.

However, compute, even if split into “equivalent” ECU capacity still relies on underlying hardware to do the work. In other words, the performance of an instance’s compute will ultimately be determined in part by what’s running under the hood. As different instances draw from different physical server models, there is a difference in underlying physical processor quality based on which EC2 instance type is purchased to host an application. ECUs reflect that only partially.

For instance, the server CPUs have more on-die cache (20MB for the E5-2670, 8MB for the X5550, 4MB for the E5507), which helps CPU-intensive applications. Multiple instances of the same instance type, rated with the same ECU will likely have different CPUs. To find out, you can run cat /proc/cpuinfo | grep “model name” if your instance runs linux.

Here is an excerpt of the same command run across instances of the same type.

i-44b2.... model name: Intel(R) Xeon(R) CPU E5410 @ 2.33GHz

i-9634.... model name: Intel(R) Xeon(R) CPU E5410 @ 2.33GHz

i-58a2.... model name: Intel(R) Xeon(R) CPU E5506 @ 2.13GHz

i-00b7.... model name: Intel(R) Xeon(R) CPU E5506 @ 2.13GHz

i-7244.... model name: Intel(R) Xeon(R) CPU E5506 @ 2.13GHz

i-aa21.... model name: Intel(R) Xeon(R) CPU E5506 @ 2.13GHz

i-54c5.... model name: Intel(R) Xeon(R) CPU E5506 @ 2.13GHz

i-d860.... model name: Intel(R) Xeon(R) CPU E5506 @ 2.13GHz

i-5592.... model name: Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz

i-3200.... model name: Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz

i-4ebd.... model name: Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz

i-703c.... model name: Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz

You can notice the disparity in CPU models. This means that if you care about which CPU model is running under the hood, you should check using the command above on all your instances.

Additionally, the number of “neighbors”, with whom you’re sharing physical compute can impact performance. The table below presents benchmarks for different instance types:

Instance typePhysical CPU(core count)PassMark per coreCores per EC2 instanceECUs per instanceECU per core
m1.largeIntel E5507 (4)812242
m2.4xlargeIntel X5550 (8)6638263.25
cc2.8xlargeIntel E5-2670 (16)83232882.75

The main conclusion to draw from this table is that on larger instances you are much more likely to run by yourself or with very few neighbors.

The cc2.8xlarge offers 32 cores, which happens to be the total number of “threads” (a.k.a. vCPU) available on a server with 2 Intel E5-2670. So very few instances can run on that server at the same time without compromising its performance.

Conversely, one Intel 5507 CPU with its 4 cores can host at a bare minimum 2 instances. This makes the probability of having neighbors on the same physical hardware higher.

Another aspect to keep in mind when evaluating CPU performance is that noisy neighbors, as well as ECU mismatches in an instance can cause performance issues. These are further detailed, along with remediation recommendations, in our free eBook, The Top 5 AWS EC2 Performance Problems.

AWS ECU Differences in Price

If ECUs were truly a “universal yardstick”, you would pay the same per ECU hour. However, as shown in the table below, the more powerful instances are priced per ECU at roughly 50% of the less powerful instances.

Instance TypeECUs per instanceCost per Instance-hourCost per ECU-hour
m1.large4$0.24$0.06
m2.4xlarge26$1.64$0.06
cc2.8xlarge88$2.40$0.03

Essentially, this leads to a “volume discount” based off of larger instance types. Hence by choosing a larger instance type you can not only achieve higher performance, but also get that capacity at a lower marginal price.

Stay tuned for a more in-depth discussion on how to select the appropriate amount of CPU in your AWS instances.