Why measure performance in AWS production after migration After an infrastructure migration to AWS, the performance observed in a test or staging environment often differs from real production conditions. Real users, unpredictable traffic, geographic load distribution, and real access patterns create scenarios that no pre-migration test can fully reproduce. Measuring performance in AWS production is therefore not optional: it is the only way to validate that your migration has not introduced hidden regressions, that the externalized services meet business expectations, and that the deployed architecture really supports the load without degradation. This step, often neglected in the rush to close out the project, avoids unpleasant discoveries three months after go-live, when load increases or a seasonal peak reveals a bottleneck that was imperceptible under normal conditions. It is also in production that you can measure the real financial impact of your migration: a latency reduced from 200 ms to 50 ms is only useful if it translates into better customer conversion or observed user satisfaction. Finally, these production measurements become the reference baselines against which you will compare all future changes, alerts, and optimizations. ## Defining the key metrics to measure in AWS production Measuring performance in AWS production requires focusing on the right metrics, the ones that truly reflect the user experience and the health of the system. The three pillars are latency, throughput, and load. Latency breaks down into several levels: the end-to-end response time perceived by the end user, the backend latency (API, database, computation), and the network latency (notably toward the front end, CDN included). In production, you generally measure the P50 (median), the P95, and the P99 to detect tail behavior, because an average alone masks the peaks that will frustrate 1% of your users. Throughput is the number of requests processed per second (RPS) or operations completed per minute depending on your domain: it must be measured globally and per critical endpoint. The CPU, memory, and disk I/O load on your EC2 instances or ECS containers indicates your reserve capacity: an average utilization of 70% at nominal load means you have a 30% buffer before saturation, which is generally healthy. Also add the error rate (4xx, 5xx) and the observed availability (real uptime during the measurement week), because low latency has no value if the service goes down. For data, measure the read and write latency in the database, the database capacity (IOPS, active connections), and the real size of the data, which will validate your AWS sizing. These metrics must be collected continuously for at least one to two weeks of real production, in order to capture a complete activity cycle and at least one peak. ## Tools and AWS services to capture performance in production AWS provides several native services to measure performance without adding significant overhead. CloudWatch is the foundation: its standard metrics (CPU, memory, disk I/O, network traffic) are free and collected automatically for EC2, RDS, ECS, ALB, and almost all AWS services. Create custom dashboards in CloudWatch to display latency, throughput, and errors side by side. CloudWatch Logs Insights lets you query application logs to extract performance statistics: filter your API requests, calculate latency percentiles, aggregate by endpoint or by user. This is useful when you have structured logs (JSON). X-Ray, AWS's distributed tracing service, captures the calls between your services (EC2, Lambda, RDS, external third parties) and automatically calculates the cascading latencies, revealing which component is slowing things down: very powerful for debugging unexpected latency, but it requires code instrumentation (X-Ray SDK) and generates marginal costs. For web and API applications, enable the fine-grained metrics of your Application Load Balancer (ALB) in CloudWatch: you will see the target-side latency, the number of new connections, and connection resets. If you have an RDS, enable Enhanced Monitoring to access operating-system metrics inside the database: I/O, locks, transactions per second. Finally, integrate synthetic tests (CloudWatch Synthetic Canaries): these small scripts simulate real transactions at regular intervals and alert if they fail or slow down, complementing your view of real production. Most of these services have a negligible cost or are included in your AWS usage reserve. ## Conducting a realistic load test before asserting that all is well The passive metrics collected in production show you the current state, but they do not tell you what happens during the next load peak or during a viral surge of your application. That is why, during the first days following the migration, before considering the project closed, you must simulate a load that reproduces your real business usage: not a generic test, but a test based on the real patterns you observed on your old system or that you project for the months to come. Proceed in stages: start with 20% of your estimated peak load, observe the metrics for 10 to 15 minutes, then move to 40%, then 60%, until you reach 100% or slightly exceed it to identify your breaking point. An abrupt load test at 100% without ramp-up risks causing timeouts and error cascades that mask the real bottlenecks. Use a tool such as JMeter (free, open-source, configured for your API) or Locust (Python-based) to generate the load from one or several external points, preferably from an AWS region close to your infrastructure to reduce the network latency of the test itself. Never generate a test load from your own data center if you have migrated to the cloud, because WAN latency would bias your measurements. During the test, observe not only latency and throughput, but also auto-scaling: do your EC2 Auto Scaling groups or your ECS replicas scale up as expected? Are there instance startup delays that transiently degrade the service? Do database connections explode or stay under control? A typical result: you find that your P99 latency stays under 500 ms up to 80% load, then climbs to 2 seconds beyond that. That is your real alert threshold, more useful than a theoretical assumption. If these tests reveal insufficient capacity, note it immediately and adjust your instances or your architecture before declaring the project a success. ## Establishing alert thresholds based on real observations Once you have measured your real production for at least a week, and you have conducted at least one controlled load test, you have enough data to define meaningful alert thresholds. Do not copy generic thresholds found on the Internet ("ALB latency > 200 ms = red alert"): your business has its own requirements. If your application is a back-office API for internal operators, a latency of 1 second may be acceptable; if it is an e-commerce site where every hundredth of a second of improvement increases conversion, you will want an alert at 300 ms. Alert thresholds should be defined at three levels: warning (yellow), critical (red), and disaster (pages). For latency, set your warning threshold at the P95 observed at nominal load (not the P50, which is generally stable), and critical at your P99 + 20%. For throughput, warning = 85% of your demonstrated maximum capacity, critical = 95%. For CPU utilization, 70% warning and 85% critical leaves a buffer before auto-scaling catches up. For the error rate, anything above 0.5% should generate an alert, because even a slight degradation suggests a problem to investigate. Do not forget business-logic alerts: the API latency may be normal, but if your database stops synchronizing, that is a silent disaster. Document each threshold with its justification ("P95 latency at nominal load + 20% for daily variations"), because you will have to explain it to your team and adjust it regularly as your traffic grows. Finally, test your alerts: trigger them manually, verify that they reach the right channels (Slack, PagerDuty, email), and that your team knows how to interpret them. An alert that generates too many false positives will be disabled out of frustration, so a few relevant alerts are better than a lot of noise. ## Documenting and sharing performance results for the team and stakeholders The performance measurements you have collected are only useful if they are clearly documented and permanently accessible to your team. Create a performance baseline report document that consolidates the observed results: P50/P95/P99 latency per endpoint or service, maximum sustained throughput before degradation, resource utilization at nominal load and at peak, database capacity (maximum active connections, real size), error rate observed under normal conditions, and uptime measured over the observation week. This report must include the measurement date, the duration, the conditions (real traffic vs load test, region, estimated active users), and above all the assumptions and limits: "These figures reflect a load of 500 concurrent RPS; we did not test beyond that, so we do not know how the infrastructure behaves at 1000 RPS." Attach captures of your CloudWatch dashboards and the curves from your load tests, because a picture is worth a thousand numbers. Share this report with the IT department, the CTO, and the development team, and use it as an anchor point to justify future investments in scalability. For non-technical stakeholders (management, business), summarize in three points: "The migration is a success; users see a latency reduced by 45%, and the system supports 3x its current load before saturation. Here is the monitoring plan so that we detect any problem before it impacts customers." Finally, this baseline becomes the gold standard for future regression tests: every architecture change, every major deployment, must be validated against these figures to ensure it does not introduce a silent regression.