AWS Workload End-to-End Workflow

Land in the right account and Region first

Every later mistake is cheaper to avoid than to repair, and the cheapest of all is creating a resource in the wrong place. Before anything is built, confirm which account you are signed in to and which Region you are pointing at.

The AWS Management Console is a web application that provides centralized access to individual AWS service consoles. It is the single door in front of every service, rather than a service of its own.

Unified Navigation can search for services, show notifications, open CloudShell, and access account and billing information. From that one bar you can reach recently visited service consoles, add services to a Favorites list, open your console settings, and see AWS notifications.

Placement is a setting, not a guess. Unified settings can configure a default Region for the console, along with the language and other aspects of the experience.

Setting a default Region simply removes one recurring chance to get that second row wrong.

Console Home, the place you start from

The home page of the AWS Management Console is called AWS Console Home, and it is more than a menu. AWS Console Home provides access to individual service consoles and AWS applications.

It can be customized with widgets — Recently visited, AWS Health and others can be added, removed, and rearranged — so that the first screen shows what a particular team actually watches.

It is also an operations surface, not only a launcher. AWS Console Home can manage and monitor application cost, health, security posture, and performance. Those four questions are the ones that follow a workload for the rest of its life, so it helps that they live where the work begins.

Choose the surface that matches the work

Exploring a service by hand and reproducing an environment on demand are different jobs, and AWS supports more than one path on purpose.

The graphical console suits exploration and guided, one-off work: the forms name the options and the service console explains what it is asking for. When commands are the natural expression instead, AWS CloudShell can run AWS CLI commands directly from the console — a shell in the browser, using the credentials you are already signed in with, with nothing to install locally.

When work has to be repeatable rather than merely done, move to a described model. CloudFormation is available through its console, API, AWS CLI, AWS SDKs, and integrations, so the same modeling approach reaches an interactive user, a script, and a pipeline alike.

These surfaces are complements, not rivals: the same person often uses all three within an hour.

Model the workload as a template

A real workload is rarely a single resource. A scalable web application with a backend database may need an Auto Scaling group, an Elastic Load Balancing load balancer, and an Amazon RDS database instance — created separately, then configured to work together, which adds both complexity and delay before anything runs.

A CloudFormation template describes the AWS resources and properties that a workload requires. Writing the collection down turns "what we built that afternoon" into something a person can read and a service can act on.

The template also carries the relationships. CloudFormation handles dependencies between resources described in a template, so nobody has to work out by hand what has to exist before what.

That last row is the quiet benefit: the model becomes the record.

Provision it as a stack

The template is the model. The stack is that model deployed and managed as one unit.

Creating a CloudFormation stack provisions and configures the resources described by its template. For the web application above, that means the Auto Scaling group, the load balancer, and the database instance are provisioned for you, in a workable order, without individually creating and configuring each one.

A successfully created stack leaves its AWS resources running. There is no separate start step: once the stack has been created, the workload is up.

The value of the pairing is that a collection of resources becomes a single unit to manage. Questions such as "what belongs to this environment?" have a definite answer, and so, later, does "what should disappear with it?"

Repeat the model where it is needed

An application may need to exist in more than one Region — for example, so that users can keep working from another Region if one becomes unavailable. The difficulty is never the idea; it is reproducing every resource and its configuration, correctly, a second time.

A CloudFormation template can be reused to provision resources consistently in multiple Regions. Describe the resources once, then provision the same resources over and over, in a consistent and repeatable manner. Nothing is copied automatically between Regions: what is reused is the description, and each Region receives its own deliberate deployment.

Track every change, and remove cleanly

Infrastructure keeps moving after launch. A larger instance type here, a smaller maximum there — and, if a change goes wrong, a need to return to the previous settings. Repairing that from memory means recalling both what was altered and what it used to be.

Because a template describes exactly which resources are provisioned and with which settings, and template text can be version controlled to track infrastructure changes, differences between versions are the change history: what changed, who changed it, and when. Reversing a change means provisioning from an earlier version of the template.

Removal deserves the same discipline. Deleting a CloudFormation stack deletes the resources in that stack — the whole collection goes together, as easily as it arrived.

Note the boundaries of that sentence. It removes the resources of that stack, not everything in the account, and deleting the template file from a repository deletes nothing that is running.

The full loop, then, is: context, access, model, provision, observe, update, and deliberate removal.

Key takeaways

• Unified settings can configure the default Region used by the console, and Unified Navigation reaches services, notifications, CloudShell, and account and billing information.
• AWS Console Home provides access to individual service consoles and AWS applications, and can also manage and monitor application cost, health, security posture, and performance.
• Pick the surface for the job: the console to explore, CloudShell to run AWS CLI commands directly from the console, and CloudFormation — through its console, API, AWS CLI, SDKs, or integrations — when the work must be repeatable.
• A CloudFormation template is a model, while a stack is its managed deployment; creating the stack provisions and configures the described resources and leaves them running.
• CloudFormation supports consistent, repeatable provisioning and tracked change across Regions, and deleting a stack deletes the resources that belong to that stack.