AWS SDK vs Console vs CLI vs IaC
AWS gives you four ways to do the same thing.
//
Busque em todas as páginas da documentação
AWS gives you four ways to do the same thing.
The Console, the CLI, the SDK, and Infrastructure as Code all sit on top of one shared set of service APIs. Picking the right one for a task is a core skill.
This page maps each surface to the jobs it does best, then shows how they fit together in a real workflow.
Every AWS action - create a bucket, read an item, send a message - is an HTTPS call to a service API.
The four surfaces differ only in who or what makes that call and how.
The Console is the web GUI at the AWS website. A human clicks through forms. It is discoverable and needs zero setup.
The CLI is the aws command in a terminal. It wraps the SDK so shells and scripts can drive AWS.
The SDK is a library you import into application code, as covered on the previous page. Your program makes calls at runtime.
IaC (Infrastructure as Code) tools - CloudFormation, the AWS CDK, Terraform, Pulumi - let you declare the resources you want in a file, then reconcile reality to match.
The key split is imperative vs declarative.
The Console, CLI, and SDK are imperative: you issue one action at a time and you own the sequencing. IaC is declarative: you describe the end state and the tool figures out the steps.
Because all four share one API, the same operation looks familiar across them.
Creating an S3 bucket is CreateBucket in the API. In the Console it is a form. In the CLI it is aws s3api create-bucket. In the SDK it is a create_bucket call. In IaC it is a resource declaration.
Here is the imperative SDK version, the one you would embed in a program.
# --- Python (boto3) ---
import boto3
s3 = boto3.client("s3", region_name="us-east-1")
s3.create_bucket(Bucket="my-app-uploads-1234")
print("bucket created")// --- TypeScript (AWS SDK v3) ---
import { S3Client, CreateBucketCommand } from "@aws-sdk/client-s3";
const s3 = new S3Client({ region: "us-east-1" });
await s3.send(new CreateBucketCommand({ Bucket: "my-app-uploads-1234" }));
console.log("bucket created");The equivalent CLI call is a one-liner: aws s3api create-bucket --bucket my-app-uploads-1234 --region us-east-1.
The difference is not the API. It is the context. The SDK call lives inside an app that reacts to events. The CLI call lives in a script. The Console click lives in a browser session that leaves no reusable artifact.
That last point matters. Imperative actions do the work but do not record intent. If you create ten resources by hand, nothing describes the environment you built, so rebuilding or cleaning it up is manual.
IaC solves that by making the file the source of truth.
The surfaces are not either-or. They compose along the life of a feature.
You explore in the Console. Clicking through a new service is the fastest way to learn its shape and see what parameters exist.
You provision with IaC. Once you know what you need, you declare it so the environment is versioned, reviewable, and reproducible across dev, staging, and prod.
You run logic with the SDK. Your deployed application uses the SDK to read and write data as users interact with it.
You automate glue with the CLI. CI pipelines, deploy scripts, and quick operational checks call the CLI because it needs no build step.
| Surface | Repeatable | Best Fit | Main Risk |
|---|---|---|---|
| Console | No | Exploring, debugging, one-off inspection | Silent, unrecorded changes cause drift |
| CLI | Partially (scripted) | Ops scripts, CI steps, quick checks | Ad hoc commands not saved anywhere |
| SDK | Yes (in code) | Application runtime logic | Using it to provision infra creates drift |
| IaC | Yes (versioned) | Provisioning and managing infrastructure | Slower loop, overkill for per-request actions |
The classic mistake is provisioning long-lived infrastructure from the Console or an SDK script.
It works the first time, but the resource now exists with no declared source. Later, someone changes it by hand, IaC does not know, and you get drift - a gap between what your templates say and what is actually deployed.
The rule of thumb: if a resource should outlive a single request, declare it in IaC. If an action is what the running app does in response to data, use the SDK.
The CLI and Console fill the fast, human, or scripting gaps around those two.
Yes. Console, CLI, SDK, and IaC all issue calls to the same AWS service APIs. They differ only in how the call is initiated and whether it leaves a reusable artifact.
Imperative (Console, CLI, SDK) means you perform one action at a time and control the order. Declarative (IaC) means you describe the desired end state and the tool computes the steps.
For exploring a new service, debugging, and inspecting resources. Avoid it as your way to create lasting infrastructure, since it records no intent.
For scripts, CI pipeline steps, and quick one-off checks where you want the SDK's power without writing and building a program.
For application runtime logic - the reads, writes, and messages your deployed program performs in response to live events and user actions.
For provisioning and managing infrastructure that should be versioned, reviewable, and reproducible across environments.
Drift is the gap between what your IaC templates declare and what is actually deployed, usually caused by manual Console or ad hoc script changes the templates never captured.
Yes. It maps to the same CreateBucket API in each. Which you choose depends on whether you want a recorded, repeatable artifact (IaC) or a quick action (Console, CLI, SDK).
Essentially yes. The AWS CLI is built on the same lower-level libraries as the SDK, exposing operations as terminal commands.
No. IaC provisions the environment, but your application still uses the SDK at runtime to work with data inside that environment.
The Console for learning and the CLI for scripting are fastest. IaC has the slowest loop because it plans and reconciles state, which is the price of reproducibility.
Because provisioning from imperative SDK calls leaves no declared source of truth, making environments hard to reproduce and prone to drift.
Stack versions: This page was written for boto3 1.43.x (Python 3.10+) and the AWS SDK for JavaScript v3 (Node.js 18+).
Revisado por Chris St. John·Última atualização: 23 de jul. de 2026