🛠️ Real World — AWS in QA

Real World — AWS in QA: Real-world AWS QA is not about learning commands — it is about designing a workflow where infrastructure is disposable.

Real-world AWS QA is not about learning commands — it is about designing a workflow where infrastructure is disposable. Picture an e-commerce team preparing for Black Friday: their load test requires 20 EC2 instances running JMeter for 4 hours. On dedicated hardware, those 20 servers cost $3,000 per month and sit idle 27 days before the test. But why is disposable infrastructure hard to trust? Because Java developers are trained to treat servers as persistent state — you SSH in, configure the JDK, tune the JVM flags, and never want to redo that work. AWS forces the opposite mindset: every instance must be reproducible from a script, or it is a ticking time bomb. Java analogy: EC2 instances are like JUnit test lifecycle — `@BeforeAll` provisions the instance, `@AfterAll` terminates it, and the test body runs in between. In a real QA incident, the team that cannot reproduce the exact environment where a test ran cannot answer "was the failure real or was it a flaky environment?" — AWS with tagged, scripted environments answers that question automatically.

Scenario: Selenium Grid on AWS EC2

This is the most common QA use case: running a distributed Selenium Grid on EC2 to execute browser tests in parallel. Here is the exact step-by-step flow a QA engineer follows.

When run-instances Runs, Is the EC2 VM Ready INSTANTLY?

run-instances only SUBMITS the request…

`aws ec2 run-instances` only SUBMITS the launch request to AWS — the command returns INSTANTLY but the machine is still in a "pending" state, NOT yet READY for an SSH connection.

describe-instances is needed because the…

`aws ec2 describe-instances --query ... PublicIpAddress` QUERIES the dynamically ASSIGNED IP address — since this IP is DIFFERENT on every `run-instances` call, it cannot be HARDCODED anywhere.

The ssh command only succeeds with the…

`ssh -i my-qa-key.pem ec2-user@ ` only SUCCEEDS with the `.pem` file matching the key specified in `--key-name` — the WRONG key file gives a "Permission denied (publickey)" error.

Scenario: Store Test Reports in S3

Why Does aws s3 sync Behave Differently from aws s3 cp?

aws s3 sync uploads the ENTIRE folder…

`aws s3 sync ./allure-report/ s3://.../` uploads the ENTIRE folder (HUNDREDS of files in an Allure report) with ONE command — it runs FASTER than `cp` by only sending CHANGED files.