Ways to provision and reach AWS: the console, APIs, SDKs, the CLI and infrastructure as code, across deployment models

Why this matters

There is more than one way to create a server in AWS. You can click through a web page, type a command, write a program, or describe the server in a file and let AWS build it. All four produce the same server. What differs is how fast it is the first time, how reliably it can be done the hundredth time, and whether anyone can check what was done.

That choice has business consequences. A team that builds its test environment by hand every week will, sooner or later, build it slightly wrong and lose a day finding out why. A security team that cannot review infrastructure changes before they happen cannot approve them. A manager who understands the difference between a one-off task and a repeatable process can ask for the right one.

The second half of this lesson is about where workloads run at all: entirely in the cloud, entirely in a company's own data centre, or a mix of the two. Salespeople and architects use those terms every day, and the exam expects you to recognise each from a short description.

The lesson

Ways to provision and operate resources in AWS

To provision a resource is to create it and make it ready for use: launching an EC2 instance, creating a database, setting up a network. To operate it is to keep it running afterwards: patching, monitoring, changing settings. AWS gives you several routes for both.

• Manually, through the AWS Management Console.
• Programmatically, through the AWS CLI, the AWS SDKs or the APIs directly.
• As code, by describing resources in templates with AWS CloudFormation, AWS's infrastructure as code service.
• Through managed provisioning. AWS Elastic Beanstalk takes uploaded application code and handles capacity provisioning, load balancing, scaling and health monitoring for it, without the developer writing any templates. CloudFormation can create those same resources, but only from templates someone has written.
• From an approved catalogue. AWS Service Catalog lets a central IT team publish approved, standardised products, usually defined as a CloudFormation template, which staff launch themselves within set constraints. AWS Marketplace is a different thing: a catalogue of third-party software to buy, not a place to publish an organisation's own approved stacks.

For operating at scale, AWS Systems Manager gives a central view of managed EC2 instances and can patch operating systems and run commands across a whole fleet without anyone signing in to each server. Amazon Inspector is the usual distractor: it finds software vulnerabilities and missing patches, but it reports them rather than installing the fixes.

Various ways to access AWS services

Every action in AWS, whoever performs it, is a request to an API (application programming interface): a defined set of operations a service accepts, such as "start this instance" or "list these buckets". The access methods are different front ends to those same APIs.

• AWS Management Console. The browser-based graphical interface. You sign in and click. It suits occasional tasks and people who do not write scripts. Clicking through it by hand is not, in itself, a repeatable process.
• AWS Command Line Interface (AWS CLI). A unified command line tool for calling AWS services from a terminal. An administrator can type a command to list or stop EC2 instances, then save those commands in shell scripts and run them again.
• AWS SDKs (software development kits). Language-specific libraries, for Java, Python and other languages, that let an application's own code call AWS. A Java program that uploads files to Amazon S3 uses the AWS SDK for Java.

Because all three call the same APIs, a resource created with one is visible in the others, and every request is authorised by IAM. None of them bypasses IAM, and none keeps its own copy of your resources.

Programmatic access needs programmatic credentials. A developer running CLI commands as an IAM user configures an access key ID and a secret access key, which the CLI uses to sign its requests. A console password works only for signing in to the console, and root user credentials should never be used for everyday work. Lesson 10 explains why access keys need careful handling.

Types of cloud deployment models

A deployment model describes where an organisation's IT resources live. There are three.

• Cloud deployment, sometimes called cloud-native or all-in. Every part of the application runs in the cloud. A startup that runs everything in AWS and owns no servers is a cloud deployment.
• On-premises deployment, sometimes called a private cloud. All resources stay in the organisation's own data centre, managed with virtualisation and resource management tools. There is no use of a public cloud.
• Hybrid deployment. Some resources run in the organisation's own data centre and are connected to resources in the cloud, so applications can span both. A company keeping a legacy system on site while running new applications in AWS, with the two talking to each other, is hybrid.

Multi-AZ, which you will meet in lesson 13, is not a deployment model. It describes resilience within AWS, not where resources live.

Choosing between the console, programmatic access and infrastructure as code

Infrastructure as code (IaC) means describing your resources, such as networks, servers and databases, in text files, and letting a service build them from those files. In AWS that service is CloudFormation. A template is a text file that lists the resources you want; deploying it creates a stack, the set of resources the template describes.

IaC brings several benefits that the exam tests:

• Consistency. The same template builds each environment the same way, in any account, so copies do not drift apart.
• Version control and review. A template is a file, so it can be stored in version control and go through the same code review and approval as application code before it reaches production. Changes made by hand in the console, or with ad hoc CLI commands, take effect immediately with no review step.
• Clean removal. Deleting a stack removes the resources that stack created. Deleting each resource by hand is slower and risks missing some.
• Previewing changes. A CloudFormation change set summarises how a proposed update will affect a stack's running resources before anything is applied. CloudTrail cannot do this: it records API calls after they happen.

IaC does not make resources cheaper, does not remove the need for IAM permissions to deploy them, and does not stop them failing. Its value is repeatability and control.

So the decision runs roughly like this. A person who needs to look at something once, with a graphical interface, uses the console. An administrator who wants to script routine actions uses the CLI. An application that must call AWS from its own code uses an SDK. A team that must build the same infrastructure repeatedly, identically, and under review uses infrastructure as code. A requirement such as "identical copies in several accounts, under version control" points to CloudFormation templates, not to someone typing CLI commands by hand at each setup.

One-time operations or repeatable processes?

Many questions turn on a single question of frequency: will this be done once, or again and again?

A one-time operation is a task that will not be repeated, such as confirming one setting on one instance. The console is quickest. Building a template, a pipeline or an SDK program for a single check adds work with no benefit.

A repeatable process is a task done many times that must give the same result each time. Here automation pays off. Both deploying stacks from CloudFormation templates and running saved CLI commands in shell scripts are repeatable. Console wizards are not, because a person must click through them every time.

Consider a company that builds a test environment by hand every Monday and removes it every Friday, and has had failed tests because of setup mistakes. Assigning the same careful engineer to the job still relies on a person repeating clicks without error, which is the cause of the problem. The fix is to make it a repeatable process with infrastructure as code, so the environment is built the same way each week and removed cleanly.

Words in a scenario such as "every week", "in several accounts", "identical" or "without clicking through screens" signal a repeatable process. Words such as "once", "a single time" or "will never be repeated" signal the console.

Recognising cloud, hybrid and on-premises deployments in a scenario

The exam often describes a situation and asks which model it is, or which service supports it. A few services belong naturally to hybrid deployments:

• AWS Outposts brings AWS infrastructure, services, APIs and tools into a customer's own facility. A manufacturer that needs AWS compute and storage inside its factory for low-latency processing, using the same APIs as in an AWS Region, needs Outposts.
• AWS Direct Connect provides a dedicated, private network connection from a customer's premises to AWS that does not travel over the public internet. It links sites; it does not run compute inside them.
• AWS Site-to-Site VPN also connects a data centre to AWS, but through encrypted tunnels over the public internet. If a requirement rules out the public internet, Direct Connect is the answer. Lesson 17 covers both.

To identify the model, ask two questions. Does the organisation run anything in its own facilities? Does it run anything in AWS? Only AWS is a cloud deployment. Only its own facilities, with virtualisation and no public cloud, is on-premises. Both, connected together, is hybrid. Two environments kept fully apart and never integrated do not make a hybrid deployment.

What the exam is really asking

Look for two clues. The first is who or what is acting: a person in a browser points to the console, a terminal and scripts to the CLI, application code to an SDK, and identical environments under review to CloudFormation. The second is how often: once favours the console, and anything repeated favours automation. For deployment models, locate the resources: all in AWS, all on site, or both joined together.