Deploy it for real

Everything so far ran inside CloudSynth's sandbox — real cdk synth, but never a real deploy, and never a real running server. This lesson closes that gap: clone a finished version of the same stack and run cdk deploy in your own AWS account.

What you already built

Across the last three lessons you wrote the exact pieces this stack needs: an Instance sized t3.micro running the latest Ubuntu 24.04 LTS AMI, a SecurityGroup open on port 80, and a bootstrap script wired in as userData. The starter template is exactly that construct — nothing new to read, just something new to run for real.

Why this can't run in the browser

The sandbox synthesizes your code and asserts against the resulting CloudFormation — it never holds AWS credentials and never calls cdk deploy. Seeing a real public DNS name respond in a browser means running the CLI against your own account, so this step is deliberately outside the sandbox's trust boundary: no CLI check-in, no server-side tracking of whether you actually deployed. Clone it, read it, run it.

Heads up: unlike the S3 concept, this one has a real hourly charge the moment it's running — a t3.micro instance bills whether or not anyone visits it. cdk destroy when you're done; see the cost breakdown on the right for exact numbers.

One more thing worth reading in the template

Open bin/app.ts in the cloned repo and you'll see the stack is instantiated with an explicit env:

new WebServerStack(app, 'Ec2InstanceAppStack', {
  env: {
    account: process.env.CDK_DEFAULT_ACCOUNT,
    region: process.env.CDK_DEFAULT_REGION,
  },
});

Without it, the stack would be environment-agnostic — CDK wouldn't know your account or region at synth time, so the Vpc construct couldn't look up your account's real Availability Zone names and would fall back to resolving them later, at deploy time, via a CloudFormation intrinsic instead of a plain string. That fallback isn't reliable and can fail the stack partway through creating your subnets. Passing env lets Vpc resolve the real AZ names once, at synth time, and bake them into the template as literals — no surprises when CloudFormation actually runs. CDK_DEFAULT_ACCOUNT/CDK_DEFAULT_REGION are populated by the CDK CLI itself from your local AWS credentials, so nothing here is hardcoded to any one account — this is a pattern worth reaching for any time a construct needs to know account/region-specific facts (AZs, an SSM parameter's value, an existing resource's properties) before your stack deploys.

What you'll see

cdk deploy prints a WebServerUrl output when it finishes. Open it, and you'll see the status page your own bootstrap script produces: "Your EC2 instance is running!", followed by that instance's own instance ID, instance type, and Availability Zone — read live off the real instance, not hardcoded.