LOCKEDIN / FORWARD-DEPLOYED ENGINEERING 101
Understand it.
Then build it.
You can be an experienced engineer and still be new to agents. Start with what each thing is and how it helps a person do useful work. Explore 52 original introductions across software, agents, cloud, security and delivery. Start here without a model key; each topic connects to deeper instruction and practice.
- 101UnderstandPlain language, visual walkthrough, vocabulary
- 102Build with guidanceOriginal lessons, examples and knowledge checks
- 103Practise and explainRunnable labs, failure cases and handover
AWS101 / LEARNING STUDIOA cloud platform · accounts, servers and services
What is AWS?
Amazon Web Services (AWS) is a collection of computing services you use over a network. EC2 gives you virtual servers; S3 stores objects such as files; managed databases and AI services cover other jobs. AWS operates the physical infrastructure. Your team still designs the application and configures its resources, access and operating limits.
An FDE must deliver into the customer's intended environment. Understanding an AWS account, a caller and a Region prevents a working command from quietly creating the right thing in the wrong place.
UNDERSTAND THE SYSTEM
AWS: account, caller and Region are different
Map the environment around one virtual server before adding a model. Arrows label ownership, placement and access rather than a sequence of network calls.
Read the connections in plain English
- 01Caller / role → Training account
Confirm the current caller and account ID rather than trusting a profile's friendly name.
- 02Training account → EC2 instance
The account remains the owner when the local CLI switches profiles.
- 03Training account → S3 bucket
The bucket and instance belong to this account in our example. Other architectures can grant explicit cross-account access.
- 04EC2 instance → Region / AZ
The instance's subnet places it in an Availability Zone within a Region.
- 05EC2 instance → S3 bucket
The app's workload role needs the intended object-read permission and a working network path.
Check your understanding: Can you prove this is the training environment just by checking the Region?
No. The production account can use the same Region. Match the account ID and caller to the approved environment; verify location and permissions as separate checks.
CONNECT IT TO WHAT YOU KNOW
Start with something familiar.
Think of an account as an independently administered workshop. It owns equipment and has access rules. The Region tells you where selected equipment operates; a role tells you what a caller may do. None of those is the application itself.
The workshop walls are only an analogy. Cross-account access can be explicitly granted, and some AWS services have global scope. A familiar profile name or successful login does not establish the intended account or authorize every operation.
Words worth knowing
- AWS account
- The environment that owns AWS resources and provides an access and billing boundary.
- IAM role
- An identity with permissions that a person or workload can assume under a trust policy.
- Region / Availability Zone
- A Region is a geographic area; an Availability Zone is an isolated location within it. Services have different location scopes.
- EC2 instance
- A virtual server supplied by the Elastic Compute Cloud service.
- S3 bucket
- A container for objects in the Simple Storage Service, separate from the server's disk.
ONE EXAMPLE / FICTIONAL CASE
Follow the connections.
A fictional maintenance team wants a document assistant in a training account. Its EC2 server needs a small set of files in S3. Bedrock can be considered after you understand that environment.
UNDERSTAND THE SYSTEM
AWS: account, caller and Region are different
Map the environment around one virtual server before adding a model. Arrows label ownership, placement and access rather than a sequence of network calls.
See what moves and why.
Read the connections in plain English
- 01Caller / role → Training account
Confirm the current caller and account ID rather than trusting a profile's friendly name.
- 02Training account → EC2 instance
The account remains the owner when the local CLI switches profiles.
- 03Training account → S3 bucket
The bucket and instance belong to this account in our example. Other architectures can grant explicit cross-account access.
- 04EC2 instance → Region / AZ
The instance's subnet places it in an Availability Zone within a Region.
- 05EC2 instance → S3 bucket
The app's workload role needs the intended object-read permission and a working network path.
Check your understanding: Can you prove this is the training environment just by checking the Region?
No. The production account can use the same Region. Match the account ID and caller to the approved environment; verify location and permissions as separate checks.
FROM RECOGNITION TO REASONING
Explain an AWS deployment without starting with Bedrock.
- 01
Draw one training account with an EC2 instance and an S3 bucket. Label each service's job.
- 02
Add the server's Region and Availability Zone, and the role used by the application.
- 03
Imagine your CLI switches to a production account in the same Region. Explain why the Region alone cannot establish the right environment.
A service map and a pre-deployment check that distinguishes account, caller and location.
Compare your reasoning when you are ready
Two accounts can use the same Region. A matching Region cannot prove that a command targets the training account. Inspect the account ID and current caller as well as location. An existing training server remains in its original account when the local profile changes.
Keep notes in your own working copy. Moving through these cards does not record completion.
TURN THE IDEA INTO USEFUL WORK
You can now go deeper.
AWS is the platform; an account owns resources; EC2 runs a server; S3 stores objects; Bedrock supplies managed AI capabilities. Learn the environment before choosing the model service.
Academy lessons use your existing training access. Free guides stay open.