Deployment Options on AWS

There are many ways to get your application running on AWS, and they sit on a spectrum from “click buttons by hand” to “fully automated pipelines.” Picking the right one is mostly about your team’s size and how often you ship. This page walks the whole spectrum, explains when each approach fits (and when it does not), and gives you the Console steps and the CLI commands side by side so you can try each one.

The deployment spectrum

Think of deployment as a ladder. Each rung trades a little setup effort for a lot more repeatability. AWS gives you the same end result at every rung, but the cost of running things changes as your needs grow.

Approach	What it is	Best for	Reproducible?
Manual Console	Clicking through the web UI	Learning, one-off experiments	No
Scripts / CLI	Shell commands and SDK calls	Repeatable tasks, automation glue	Partly
IaC (CloudFormation, CDK, Terraform)	Infrastructure defined as code	Anything with more than one environment	Yes
Managed platforms (Beanstalk, App Runner)	AWS provisions and runs it for you	Small teams who want to skip plumbing	Yes
CI/CD pipelines	Code change automatically deploys	Teams shipping daily	Yes

The real question is not whether to automate, but which tool. The moment you have more than one environment (say, staging and production), stop clicking and move to Infrastructure as Code (IaC) — defining your cloud resources in text files that you commit to Git.

Manual deployment in the Console

The AWS Management Console (the web dashboard at console.aws.amazon.com) is where most people start. You log in, find a service, and click through forms to create resources.

When to use this: learning a new service, debugging, or a true one-off you will never repeat. When NOT to: anything you need to do twice. Manual clicks are not recorded anywhere, so nobody can review them, repeat them, or roll them back.

To launch a single server (an EC2 instance, a virtual machine in AWS) by hand:

Open the EC2 service in the Console.
Click Launch instance.
Pick an Amazon Machine Image (AMI — a pre-built disk template), for example Amazon Linux 2023.
Choose an instance type such as t3.micro.
Select or create a key pair, pick a security group (a virtual firewall), then click Launch instance.

The same thing with the AWS Command Line Interface (CLI — the terminal tool, v2 in 2026):

aws ec2 run-instances \
  --image-id ami-0abcdef1234567890 \
  --instance-type t3.micro \
  --key-name my-key \
  --security-group-ids sg-0a1b2c3d \
  --subnet-id subnet-0a1b2c3d

Output:

{
    "Instances": [
        {
            "InstanceId": "i-0a1b2c3d4e5f",
            "InstanceType": "t3.micro",
            "State": { "Name": "pending" },
            "SubnetId": "subnet-0a1b2c3d"
        }
    ]
}

The CLI version is already a step up: you can paste it into a script, share it, and run it identically tomorrow.

Scripts and the CLI

Wrapping CLI commands in a shell script is the cheapest form of automation. It is repeatable and easy to read, but it has no memory of what already exists — re-running a “create” script twice gives you two of everything.

When to use this: small automation glue, cron jobs, or bootstrapping. When NOT to: managing a full environment’s worth of resources, where you need to track and update what already exists.

Infrastructure as Code

IaC means you describe your cloud — servers, networks, databases — in text files, and a tool makes reality match the files. The tool tracks what exists, so applying the same file twice is safe (this property is called idempotency).

The three main choices on AWS:

Tool	Language	Strengths
CloudFormation	YAML / JSON	Native AWS, no extra cost, deep service support
AWS CDK	TypeScript, Python, etc.	Real programming language; compiles to CloudFormation
Terraform	HCL	Multi-cloud, huge ecosystem, strong state management

A tiny CloudFormation template that creates one instance:

Resources:
  WebServer:
    Type: AWS::EC2::Instance
    Properties:
      ImageId: ami-0abcdef1234567890
      InstanceType: t3.micro
      SubnetId: subnet-0a1b2c3d

The Terraform equivalent:

resource "aws_instance" "web" {
  ami           = "ami-0abcdef1234567890"
  instance_type = "t3.micro"
  subnet_id     = "subnet-0a1b2c3d"
}

Gotcha: once a resource is managed by IaC, do not also edit it by hand in the Console. The IaC tool stores its own record of what it created; manual changes make reality diverge from that record. This is called drift, and it breaks future deploys when the tool tries to “correct” your manual fix.

Managed platforms

If you would rather not define networks and load balancers yourself, AWS has platforms that do the plumbing for you. You hand them your code, they provision and run it.

Elastic Beanstalk — give it a web app (Node, Java, Python), it creates the servers, load balancer, and scaling rules. You only pay for the underlying resources, not Beanstalk itself.
AWS App Runner — point it at a container image or source repo; it builds, deploys, and auto-scales a web service with zero servers to manage.

When to use these: small teams or solo developers who want a deployment without learning EC2, VPC, and load balancers first. When NOT to: when you need fine control over the underlying infrastructure, or have unusual networking needs the platform does not expose.

Deploying an existing Beanstalk app from the CLI:

aws elasticbeanstalk update-environment \
  --environment-name my-app-prod \
  --version-label v2026-06-15

Output:

{
    "EnvironmentName": "my-app-prod",
    "Status": "Updating",
    "Health": "Grey",
    "VersionLabel": "v2026-06-15"
}

CI/CD pipelines

CI/CD (Continuous Integration / Continuous Delivery) means a code push automatically builds, tests, and deploys your app — no human runs commands. AWS provides a native toolchain: source in CodeCommit (or GitHub), build in CodeBuild, deploy with CodeDeploy, all orchestrated by CodePipeline.

When to use this: any team shipping more than a few times a week, where manual deploys become a bottleneck and a source of mistakes. When NOT to: a throwaway prototype where the pipeline setup costs more time than it saves.

A pipeline typically watches your Git repository, runs your tests on every push, and — if they pass — deploys automatically. The IaC for the infrastructure and the pipeline definition both live in your repo, so the entire system is reproducible from code.

Cost note: CodePipeline charges about $1 per active pipeline per month, and CodeBuild bills per build minute (roughly $0.005/minute on a small general1.small instance). For most small teams this is a few dollars a month — far cheaper than an engineer’s time spent on manual deploys.

Best practices

Use the Console to learn and explore, but never as your only record of what is deployed.
Adopt IaC the moment you have a second environment — it pays for itself immediately.
Pick one IaC tool per project and stick to it: CloudFormation/CDK if you are all-in on AWS, Terraform if you span clouds.
Never make manual Console changes to IaC-managed resources; fix the code and re-apply instead to avoid drift.
Start managed (Beanstalk or App Runner) if your needs are standard, and graduate to custom IaC only when you outgrow it.
Add a CI/CD pipeline once deploys happen often enough that doing them by hand is error-prone.
Keep both your infrastructure code and pipeline definition in version control so the whole stack is reproducible.