DEV Community: TechEazy Consulting

What an AWS Lambda function is, and what its execution role decides

TechEazy Consulting — Tue, 20 Oct 2026 02:26:51 +0000

An interviewer leans back and asks, "So what is a Lambda function, really?" You know the slogan: code without servers. Then the follow-up comes: "Your function returns a 502 when it writes to the database. Why?" The slogan does not answer that. This article claims that a fresher can answer both questions with two ideas. First, a Lambda function is a small contract between your code and a runtime that starts, reuses and discards environments for you. Second, the execution role decides everything that code may touch. Most first failures happen because the role and the code disagree, and the article works through the questions in the order an interviewer tends to ask them.

A Lambda function is code plus configuration, run only on demand

The question: "What is a Lambda function, in your own words?"

A Lambda function is your code plus a few settings that AWS runs only when it is invoked, meaning called. The settings are the runtime, the handler, the memory, the timeout and the role. You never see or patch a machine. AWS creates an environment to run the code in, scales it out when requests arrive together, and throws it away when things go quiet.

Think of it as a food stall that only lights its stove when an order arrives. You write the recipe and pin a few instructions to the wall: which cuisine to cook (the runtime), which recipe card to start from (the handler), and how long a dish may take before it is abandoned (the timeout). The stall owner lights the stove, opens a second stove for a second order, and lets them go cold. You pay per order cooked, not for the stall standing there.

A strong answer names what this changes. Without a server to keep running, "is the server up?" stops being the hard question. The hard questions become who may call this code, what may this code touch and what happened on that one request.

Start-up code runs once per environment; the handler runs once per request

The handler is a contract that is called once per request

The question: "What does Lambda actually call, and what does it pass in?"

Lambda calls one function in your code, the handler, once for each request. In Python, a file named lambda_function.py that defines lambda_handler(event, context) has the handler lambda_function.lambda_handler. The event is a document describing what triggered the call. For a web request it holds the method, path, headers and body. The context describes the invocation itself, such as its request ID and its log group name.

Whatever the handler returns becomes the response. If you return a dictionary with statusCode, headers and body, Lambda turns it into the HTTP response. If you return plain JSON with no status code, Lambda assumes status 200 and content type application/json.

Interviewers like the next detail because it shows you understand the lifecycle. Code outside the handler, such as imports and creating an SDK client, runs once when an environment starts. Later invocations in that same environment reuse it. That is why the Lambda documentation advises creating SDK clients outside the handler: you pay the start-up cost once per environment, not once per request.

Think of it as the cook laying out knives before service rather than fetching them for every dish.

Two defaults are worth knowing, and so is how to choose a runtime. A runtime is named by an identifier such as python3.14, and each identifier has a published deprecation date. When the runtimes page was checked on 2026-10-02, python3.14 was the newest generally available Python runtime. python3.15 was listed as a public preview, which the page says is not for production.

The settings a function carries, with their defaults and what each one governs

The execution role is the only thing deciding what your code may touch

The question: "Where does your function get permission to write to the database?"

When Lambda runs your code, the code acts as the execution role. A role is an identity in IAM, the AWS permissions service, and it has two halves:

a trust policy saying who may take it on, which for an execution role is the Lambda service, lambda.amazonaws.com;
permission policies saying what it may do once it has been taken on.

Think of it as a staff badge. The badge opens the store room and the noticeboard and no other door. The cook did not choose the badge. Whoever hired them did, and the badge is checked at every door.

The answer that impresses is this one: there are no keys in the code. The Python SDK finds temporary credentials for the role in the function's environment by itself. The Lambda documentation says you do not need to provide credentials to set up a client. If a candidate pastes an access key into a function, it shows they have not understood the role.

The trust policy lets Lambda take on the role; permission policies decide which doors it opens

The default role explains the classic 502

The question: "You created a function with every default, and saving a record returns 502. What happened?"

This is the failure a first attempt usually hits. You write a handler that saves a note to a DynamoDB table, which is a managed key-value database. You create the function in the console and accept the defaults. A request returns a bare 502. A status in the 5XX range is what a function URL, the function's public web address, returns when the function itself fails. The response gives no reason.

The function's log has the reason:

[ERROR] ClientError: An error occurred (AccessDeniedException) when calling the PutItem operation:
User: arn:aws:sts::111122223333:assumed-role/hoc-notes-api-role-x1y2/hoc-notes-api is not
authorized to perform: dynamodb:PutItem on resource: arn:aws:dynamodb:ap-south-1:111122223333:table/hoc-notes

The code was fine. The console's default option creates a new role with the managed policy AWSLambdaBasicExecutionRole. That policy grants exactly three actions: logs:CreateLogGroup, logs:CreateLogStream and logs:PutLogEvents. So the function could log its own error, but it could not save the note.

The role may write logs but not the table, so the caller sees only 502 while the log names the cause

Read the error as a sentence. The subject is the role, the verb is the action, and the object is the table. Every permission problem inside a function reads that way, so the fix is always the same: add exactly that action, on exactly that resource, to the role. In the console, that means choosing Use another role under Permissions and picking a role built for read and write on the one table, with basic logging added.

An interviewer may push: "Why not just attach an administrator policy?" It would make the error go away. It would also mean that a bug in this one function could change anything in the account. In our view, saying that unprompted is one of the clearest signs a fresher has thought about permissions rather than just made them work.

Who may call the function is a separate decision

The question: "So the role controls who can call it?"

No, and this is the trap. The execution role decides what the function may call. A different policy decides who may invoke the function: the resource-based policy, which is attached to the function itself.

The two failures look alike but happen on opposite sides of the function. A 403 from the function URL, with no START line in the log, means the request was refused before your code ran. In that case the resource-based policy is the place to look. An AccessDeniedException inside the log means the code ran and the role was refused. Being able to tell these apart in one sentence is worth more in an interview than any definition.

Two permission failures, on opposite sides of the function

A small notes function shows each idea in a few lines

The question: "Walk me through a function you wrote."

A useful one to describe is a notes API: a single Python handler that lists notes on GET and adds a note on POST. Each line choice answers one of the ideas above.

The client is created at module level. table = boto3.resource("dynamodb").Table(TABLE_NAME) sits outside the handler, so each environment pays for it once.
The table name comes from an environment variable, TABLE_NAME, with a fallback. The configuration stays out of the code.
The method is read from the event, at event["requestContext"]["http"]["method"]. A function URL delivers requests in the same payload format version 2.0 shape that Amazon API Gateway uses.
The body is decoded when isBase64Encoded is true. That flag means Lambda encoded a binary request body as text.
Bad input returns 400, not an exception. Empty text, invalid JSON or text over 500 characters each get a clear error. An exception reaches the caller only as the opaque 5XX described earlier.
json.dumps(..., default=str) handles DynamoDB numbers. The SDK returns them as Python Decimal values, which json.dumps refuses on its own.
OPTIONS returns 204 because browsers send it before some cross-origin calls.

Each kind of request gets a deliberate status code instead of an unhandled failure

There is one honest weakness to mention before the interviewer finds it. The GET handler uses table.scan(), which reads every item, up to 1 MB per call, and signals when more remains. That is fine for a small table. For a large one it is the wrong tool, and you would design a key you can query by instead. Naming the limit of your own code reads as experience, not weakness.

The log is the only witness to a single request

The question: "How would you find out what happened on one failed request?"

A function has no screen, so its log is the only record of what one request did. Lambda sends output to CloudWatch Logs, the AWS logging service, as long as the role allows the three logs: actions. By default the log group is /aws/lambda/<function-name>, and each environment writes its own stream inside it.

Every invocation writes START, END and REPORT lines, each carrying the request ID. The REPORT line gives Duration, Billed Duration, Memory Size and Max Memory Used. It also shows Init Duration, but only when a new environment had to start. Anything the code prints appears between START and END.

Think of it as the stall's order book: one entry per order, written whether the dish came out right or not.

What to practise before the interview

Practise these until you can say each one aloud without notes:

Explain the handler contract, including what runs once per environment and what runs once per request.
Name the two halves of an execution role and what AWSLambdaBasicExecutionRole allows.
Read an AccessDeniedException as subject, verb and object, then state the exact fix.
Separate a 403 with no START line from an AccessDenied inside the log.
Defend one design choice in your own function, and name one of its limits.

Key takeaways

A Lambda function is code plus configuration that runs on demand. The handler is called once per request, and code outside it runs once per environment.
The execution role decides what the code may touch. Its trust policy names lambda.amazonaws.com, and the code holds no keys.
The default role can only write logs. That is why a first database write often fails with a bare 5XX.
Fix permission errors with exactly the missing action on exactly that resource, never with broad access.
Who may call the function is decided by a separate resource-based policy, and the log tells you which side refused.

This article does not settle how to authenticate callers properly, how to configure CORS (the headers that let a browser page read the function's responses), or what any of this costs at scale. Each of those is a decision in its own right.

Creating your first key-value table from the command line, and measuring what each read costs

TechEazy Consulting — Mon, 19 Oct 2026 07:05:37 +0000

You have a small notes app and nowhere permanent to keep the notes. Records stored on a server's own disk vanish when that server is replaced, so you want a managed table that outlives any one machine. You open a terminal and immediately hit two questions: what should the first command be, and how do you know whether a read is cheap or expensive?

This lab answers both using Amazon DynamoDB, a managed table service you reach entirely through an API. The claim is simple. The partition key you choose when you create the table decides two things: which item every write touches, and how much work every read does. Reading by key goes straight to one item. A Scan reads every item, and you can watch the difference in the response itself. You will create a table, fill it, read it three ways, compare the cost of each, and then delete it.

The setup is small: one identity, one Region, one billing mode

You need an account, an everyday administrator identity that is not the root user, and the AWS command-line interface (CLI), version 2, signed in as that identity. This lab uses the Asia Pacific (Mumbai) Region, ap-south-1. If your CLI is not yet set to that Region, run:

aws configure set region ap-south-1

To confirm who you are signed in as, run aws sts get-caller-identity. The Account field in the output is your 12-digit account ID. The CLI documentation notes that this command needs no permissions, so it works whatever identity you use.

Now the money. The table uses on-demand capacity, a mode in which you pay per read and write request and plan no capacity in advance. The service documentation calls it the default and recommended mode. It also states that if you are "driving zero traffic to your table, then with on-demand, you are not charged for any throughput." Storage is billed separately.

As of 2026-10-02, the pricing page listed 25 GB of storage per Region in the Free Tier. It also listed 25 free read and 25 free write capacity units, but those apply to the provisioned mode, not to on-demand requests. The few dozen requests in this lab are billed per request.

On-demand bills each request and stored data; an idle table has no throughput charge

The partition key is the first decision, because it is the item's identity

A table is a collection of items, much like rows. Each item is a group of attributes, much like fields. Every item must have a primary key that no other item shares. In the simplest case that key is one attribute, the partition key. DynamoDB feeds the partition key's value into an internal hash function, and the result decides where the item is stored.

Think of it as a wall of numbered lockers. The table is the wall, and the partition key is the number on each door. To fetch something, you name the number and walk straight to that locker.

This lab's table is hoc-notes, with partition key noteId, a string, and no sort key. Create it:

aws dynamodb create-table \
    --table-name hoc-notes \
    --attribute-definitions AttributeName=noteId,AttributeType=S \
    --key-schema AttributeName=noteId,KeyType=HASH \
    --billing-mode PAY_PER_REQUEST \
    --tags Key=project,Value=hands-on-cloud

Three parts of that command do the teaching:

--attribute-definitions lists only the key. You never declare title or body. Apart from the key, the table is schemaless, which means each item can carry different attributes.
KeyType=HASH marks noteId as the partition key. The older name for the partition key is "hash attribute", after the hash function. A sort key would be RANGE. A key attribute must be a string, a number or binary.
PAY_PER_REQUEST selects on-demand capacity.

Why choose noteId and not title? Because the app fetches a note by its id, from a link or an API path, and because the key must be unique. Titles repeat. As the next sections show, two notes that share a key do not coexist.

What you should see: the command returns at once with "TableStatus": "CREATING". Check it until it changes:

aws dynamodb describe-table --table-name hoc-notes --query "Table.TableStatus"

When it prints "ACTIVE", the table is ready for writes.

The partition key's value goes through a hash function that decides where each item is stored

Items are written in typed JSON, and a reused key replaces silently

The CLI writes items in typed JSON: every value is wrapped in its type. A string is {"S": "Buy milk"}. The number 2 is {"N": "2"}.

That number sits inside quotes. It looks wrong the first time, but it is correct. The N says the value is a number, and the value itself travels as a string. Writing {"N": 2} is the mistake to watch for.

Add a few notes:

aws dynamodb put-item --table-name hoc-notes \
    --item '{"noteId": {"S": "n-001"}, "title": {"S": "Buy milk"}, "body": {"S": "Two litres"}}'

aws dynamodb put-item --table-name hoc-notes \
    --item '{"noteId": {"S": "n-002"}, "title": {"S": "Read chapter 3"}, "priority": {"N": "2"}}'

Add two or three more, each with its own id. Notice that n-002 has a priority attribute and n-001 does not. That is schemaless storage at work.

Think of it as your phone's contacts list. Some contacts have a birthday, some have an email address, and only the ID is required.

Now try the failure on purpose. Write n-001 again with different contents:

aws dynamodb put-item --table-name hoc-notes \
    --item '{"noteId": {"S": "n-001"}, "title": {"S": "Call home"}}'

What you should see: nothing. There is no error and no warning.

Read the item back and it says Call home, and it has no body at all. The documentation describes a put precisely: it "creates a new item, or replaces an existing item with a new item." Two writes with the same key are two versions of one item. The second replaces the first entirely, attributes and all. In the locker picture, you did not add a second locker. You emptied the existing one and refilled it.

Two puts with the same key leave one item: the second replaces the first entirely

GetItem reads one item, because it walks straight to the key

The notes app has two different jobs. Opening a link to one note means the app knows the key. Showing the home page means it must list every note and knows no key. Each job calls for a different read, so measure both.

GetItem takes the full primary key and returns that one item, or nothing. Ask it to report what it consumed:

aws dynamodb get-item --table-name hoc-notes \
    --key '{"noteId": {"S": "n-002"}}' \
    --return-consumed-capacity TOTAL

What you should see: the item, plus a ConsumedCapacity block that shows the read capacity this one request used. Write that figure down, because it is your baseline.

Reads are eventually consistent by default. Add --consistent-read and you get a strongly consistent read instead. It reflects every write that completed before it, and it costs twice as much. Run the command once with the flag and compare the two ConsumedCapacity figures.

Scan reads every item, and a filter does not make it cheaper

For the home page there is no key to walk to. You open every locker on the wall, one after another. That is a Scan:

aws dynamodb scan --table-name hoc-notes --return-consumed-capacity TOTAL

What you should see: all your notes, a ConsumedCapacity block, and two counts. ScannedCount is the number of items read. Count is the number of items returned. On an unfiltered Scan the two are equal.

Now ask for just one note through a filter. A filter expression narrows the results that come back:

aws dynamodb scan --table-name hoc-notes \
    --filter-expression "title = :t" \
    --expression-attribute-values '{":t": {"S": "Call home"}}' \
    --return-consumed-capacity TOTAL

What you should see: Count drops to 1, but ScannedCount still equals the full number of notes. The documentation spells out why: "a Scan consumes the same amount of read capacity, regardless of whether a filter expression is present." The filter is applied after the read. It shrinks the answer, not the work. It is like opening every locker and keeping only the red bags.

Scans also run in pages. A Scan reads up to 1 MB per request, and the CLI keeps requesting pages until it has read the whole table.

A large ScannedCount beside a small Count is the signature of an inefficient read. With five notes the waste is invisible. With a million notes, a Scan that finds one title reads a million items, while GetItem by key still reads one. On-demand capacity bills you for what is read, so this is a cost problem as well as a speed problem.

GetItem reads only the named item; a filtered Scan reads every item and returns fewer

In my view, the working rule follows directly. Choose Scan when you truly need every item and the table is small, such as listing a practice app's notes. Choose GetItem whenever you can name the key.

Query matches GetItem here, and earns its place with a sort key

There is a third read. Query returns the items that share one partition key value. Its key condition must test the partition key for equality, with the value passed through a placeholder that starts with a colon:

aws dynamodb query --table-name hoc-notes \
    --key-condition-expression "noteId = :id" \
    --expression-attribute-values '{":id": {"S": "n-002"}}' \
    --return-consumed-capacity TOTAL

What you should see: one item. In a table with only a partition key, no two items can share that value, so Query returns at most one item, the same one GetItem returns.

Query earns its place when a table also has a sort key, an optional second key attribute. Items that share a partition key are stored together, ordered by the sort key. Picture a music table keyed by artist and song title. Querying one artist is like pulling out the drawer with that artist's name: every song comes out in title order, and no other drawer is touched.

The three reads differ in what you must know and how much they read

Cleaning up leaves nothing to bill

An idle on-demand table incurs no throughput charge, but its stored data is still billed. When you have finished experimenting, delete the table:

aws dynamodb delete-table --table-name hoc-notes

What you should see: a description of the table with its status changing to DELETING. After that, describe-table reports that the table cannot be found. The project = hands-on-cloud tag you added at creation makes it easy to check that nothing from this lab is left behind.

Key takeaways

Create the table with only its key declared. Everything else is schemaless and can differ from item to item.
Choose the partition key from how the data is fetched and what makes it unique, such as an id and never a title. A put with an existing key silently replaces the whole item.
Write values in typed JSON, and quote numbers: {"N": "2"}.
Add --return-consumed-capacity TOTAL to any read to see what it cost. Compare ScannedCount with Count on every Scan.
GetItem reads one item. A Scan reads all of them, and a filter expression does not reduce what it reads.
On on-demand capacity you pay for requests and stored data. Strongly consistent reads cost twice as much as the default.

This lab measured reads on a handful of items. It does not settle how to design keys for richer access patterns, how to prevent overwrites with a condition on the put, or how to limit an application's permissions to this one table. Each of those deserves its own treatment.

Signing the AWS CLI in without access keys, then proving a policy in the simulator

TechEazy Consulting — Fri, 16 Oct 2026 09:40:25 +0000

You have just installed the AWS CLI, and the setup guide asks you to paste in an access key ID and secret. That leaves a long-lived secret sitting in a file on your laptop. Next you need a permissions policy, and you have no way to know whether it does what you meant until something breaks.

This lab shows that neither step needs that risk. The aws login command exchanges an ordinary console sign-in for temporary credentials that the CLI manages for you. The IAM policy simulator then tells you whether a policy would allow or deny an action, without sending a real request to any service. Together they let you work from the terminal with no stored keys, and check a policy before it can do any harm. The simulator is a rehearsal, not a guarantee, and this lab is explicit about where it stops.

The goal, and the three tasks that reach it

The lab has three tasks, in this order:

Sign the CLI in without an access key, and confirm who it is acting as.
Write a policy and prove its behaviour in the simulator.
Find where the session is stored, look at it, and delete it.

The order matters. Every simulator command in task 2 is itself an AWS CLI call, so it needs the credentials from task 1. Task 3 tidies away what task 1 created.

Sign in first, simulate with that session, then delete it

Version 2.32.0 is the floor for signing in without keys

The aws login command needs AWS CLI version 2.32.0 or later. This lab is written against version 2.38.1, the current release, which is well past that floor. Confirm what you have installed with the global --version option:

$ aws --version

You also need an identity that can sign in to the AWS Management Console. That can be the root user, an IAM user, or a federated identity from your identity provider. If your organisation uses IAM Identity Center, a separate configuration path applies instead.

The identity also needs permission to use this sign-in method. Attach the SignInLocalDevelopmentAccess managed policy to the IAM user, role or group. Root users need no extra permissions.

On a shared account, signing in as root to complete a lab is a poor habit. A sensible default is an IAM user or a federated identity that carries the managed policy above.

aws login turns a console sign-in into temporary credentials

Run the command in your terminal:

$ aws login

To sign in to a named profile, or to create one, add --profile:

$ aws login --profile my-dev-profile

If the profile is new, or no Region is set, the CLI asks for an AWS Region and offers us-east-1 as the default. You can change the Region later with aws configure set region NEW_REGION.

The CLI then tries to open your default browser on the sign-in page. You can pick one of your active console sessions or sign in afresh. In the browser, choose the credentials to use, then return to the terminal.

Suppose the profile already holds a different session. For example, it was set up as a read-only user and you have now signed in as an admin user. The CLI asks whether to overwrite the existing session, and it waits for a y or n. A final message confirms the completed profile configuration.

The browser proves who you are; the CLI keeps temporary credentials

The command still works on a machine with no browser, such as a remote server. Use aws login --remote and the CLI prints a URL to open on another device. After you sign in there, you copy the authorization code back into the CLI prompt.

You can also control which of the two flows is allowed. The two flows have separate resource ARNs that you can use in IAM policies:

Same-device and cross-device sign-in each have their own ARN to allow or deny

get-caller-identity proves who the CLI now is

Before you trust the session, ask AWS who you are:

$ aws sts get-caller-identity
$ aws sts get-caller-identity --profile my-dev-profile

The first command uses the default profile. The second uses a named one. You should see the identity you chose in the browser.

The credentials then look after themselves. The CLI and SDKs refresh the cached credentials every 15 minutes as needed. The whole session lasts up to the IAM principal's set session duration, to a maximum of 12 hours, after which you run aws login again.

Think of it as a day pass that renews itself at the turnstile, rather than a key you cut and carry forever.

The simulator answers "allowed or denied" without touching anything

The IAM policy simulator evaluates a request against the policies you give it. It never sends that request to any AWS service. For every action and resource you test, it returns one of two outcomes: allowed or denied. When the outcome is an allow or an explicit deny, it also names the policy statement that produced it.

The simulator has two modes:

Principal mode tests the policies already attached to an existing user, role or group.
Custom mode tests policies that you write or paste in. Nothing is saved to your account.

Custom mode is the one to use when checking a draft before you attach it. On the command line, custom mode is aws iam simulate-custom-policy. Policies already attached to an identity use simulate-principal-policy instead.

The simulator weighs policies and inputs, then returns a decision and no service response

A custom policy is proved with one command and a context value

Here is the draft policy. It allows every DynamoDB action, but only after a set date and time. The command below simulates the dynamodb:CreateBackup action and supplies a value for the aws:CurrentTime key that the condition checks:

aws iam simulate-custom-policy \
  --policy-input-list '{"Version":"2012-10-17","Statement":{"Effect":"Allow","Action":"dynamodb:*","Resource":"*","Condition":{"DateGreaterThan":{"aws:CurrentTime":"2018-08-16T12:00:00Z"}}}}' \
  --action-names dynamodb:CreateBackup \
  --context-entries "ContextKeyName='aws:CurrentTime',ContextKeyValues='2019-04-25T11:00:00Z',ContextKeyType=date"

The supplied date is later than the condition's date. The result therefore shows "EvalDecision": "allowed", and its MatchedStatements entry points to PolicyInputList.1, the first policy you passed in.

A passing test proves little on its own. Now prove that the condition actually bites by changing the context value to 2014-04-25T11:00:00Z, a date before the one the policy requires. The decision becomes implicitDeny, and MatchedStatements is empty.

Two allowed actions on their own would not show that the condition works. A passing case alongside a failing one does. In practice, a sensible habit is to write one test that should pass and one that should fail for every condition you care about.

A few rules for the inputs:

Action names must include the service prefix, such as iam:CreateUser, and wildcards are not allowed.
If you leave out --resource-arns, the resource defaults to *, meaning all resources.
The resources you name do not need to exist in your account.

Reading the result: the decision, the statement, the missing keys

Each result carries an EvalDecision with one of three values. When several statements apply, one explicit deny overrides any number of allows, and only the deny statement appears in the result.

Two ways to be denied, and only one of them names a statement

Also watch MissingContextValues. It lists the context keys your policies need but that you did not supply. If a supplied value does not satisfy a condition, the action is denied.

The simulator fills in some keys by itself. These are the principal keys, such as aws:PrincipalAccount and aws:UserName, and organisation keys such as aws:PrincipalOrgID. You supply every other key yourself. To find out which keys a draft policy needs before you run it, the CLI reference points to GetContextKeysForCustomPolicy.

Several resources now come back as one aggregate answer

In version 2.38.1, the simulator returns a single evaluation result per action, however many resource ARNs you pass. Older behaviour returned one result per resource, each carrying the same overall decision.

The top-level EvalDecision is now the most restrictive decision across all resources. If any resource produces explicitDeny, the top-level decision is explicitDeny. To see the decision for each resource, read ResourceSpecificResults.

This affects how you read the output. The top-level EvalResourceName is now an ARN template for the resource type, not one of your ARNs. Any script that parsed per-resource answers from the top level needs to read ResourceSpecificResults instead.

Some features have limits worth knowing:

You can include only one resource-based policy per simulation.
The simulator never fetches a resource's policy for you, so you must pass it in.
Simulating resource-based policies is not supported for IAM roles.
Service control policies can be passed in order, from the organisation root down to the account. Their matched statements are not shown in the results, for security reasons.

Cleaning up: where the session lives, how to look at it, how to delete it

Where it is stored. Signing in with the default profile writes a login_session line to the config file. That line holds your identity's ARN, next to the Region. The temporary credentials, and the details needed to refresh them, are cached in ~/.aws/login/cache on Linux and macOS, or %USERPROFILE%\.aws\login\cache on Windows. The AWS_LOGIN_CACHE_DIRECTORY environment variable moves that cache to another location.

Look at it. Open the config file and find the login_session entry for your profile. List the cache directory too; its file names are based on the resolved profile.

Delete it. You can let the credentials expire, or remove them now:

$ aws logout
$ aws logout --profile my-dev-profile
$ aws logout --all

With no profile on the command line or in AWS_PROFILE, aws logout signs out the default profile. The --all option signs out every profile that uses login credentials.

The policy work needs no cleanup. Custom-mode policies are never saved to your account, and editing a policy inside the simulator leaves the real one unchanged.

A login session is written to two places and removed by one command

Key takeaways

aws login needs CLI version 2.32.0 or later. It swaps a console sign-in for temporary credentials that refresh themselves for up to 12 hours, so no long-lived key is stored on disk.
Confirm the session with aws sts get-caller-identity before you rely on it.
Prove a draft policy in custom mode with simulate-custom-policy. Pair a case that should pass with one that should fail, and supply every context key the conditions check.
In version 2.38.1, read per-resource decisions from ResourceSpecificResults; the top-level decision is an aggregate of all resources.
Clean up with aws logout. Simulated policies leave nothing behind in your account.

The limit is the one the simulator states about itself: its results can differ from your live environment. It does not evaluate resource control policies. It can also diverge on VPC endpoint policies, role chaining, or resources that have several resource-based policies. A simulated "allowed" is strong evidence, not proof. This lab does not cover the final check: confirming the attached policy's behaviour against your live account.

How to find the closed port that stops an EC2 web page loading, and lock down SSH

TechEazy Consulting — Fri, 16 Oct 2026 03:24:08 +0000

You launched an Amazon EC2 instance, installed a web server, and typed its public address into a browser. The tab spins and then times out. Nothing on the server looks broken, and the cause is outside the server. In almost every first attempt, the block is the instance's security group, the virtual firewall that sits in front of it. This article argues that two changes fix the problem and make the instance safer. First, open only ports 80 and 443 to the world. Second, close SSH to everyone except you, and use EC2 Instance Connect so you stop handing out keys. The steps below cover where to look, what each rule should say, what you should see afterwards, and what to remove when you finish.

The page times out because no inbound rule admits web traffic

A security group acts as a virtual firewall for your EC2 instances and controls incoming and outgoing traffic. Inbound rules control the traffic coming in to your instance, and outbound rules control the traffic going out. The only traffic that reaches the instance is the traffic the security group rules allow.

Think of it as a guest list at a door. Nobody gets in unless the list names them. A browser asking for your page is a guest the list does not yet name. The web server process may be running perfectly, but the request is turned away before it reaches the server.

This also explains why the failure usually shows up as a timeout rather than an error page. In practice, a request the firewall drops never gets a reply, so the browser waits until it gives up. If you see a slow timeout instead of an immediate refusal, a missing rule is the first thing to check.

A browser request reaches the web server only if a security group rule allows it

Step 1 — Read every security group on the instance, not just one

Goal: find out which rules actually apply to your instance.

You can associate an instance with several security groups, and you can associate one security group with several instances. When Amazon EC2 decides whether to let traffic reach an instance, it evaluates all the rules from all the security groups associated with that instance. If you did not specify a security group at launch, Amazon EC2 used the default security group for the VPC (your private network inside the cloud).

That gives you a short investigation:

Open the instance's details in the EC2 console and list every security group attached to it.
For each group, open the Inbound rules.
Look for a rule with protocol TCP, port 80 or 443, and a source that includes the address you are browsing from.

What you should see: if no group has such a rule, you have found the closed door. A common surprise is an instance running on the default group. In practice that group often has no rule for web traffic from the internet, because nobody added one.

Every attached group counts, so check each group's inbound rules for ports 80 and 443

Step 2 — Add the web server rules and watch the page load

Goal: let anyone on the internet reach your page, and nothing else.

An instance set up as a web server needs security group rules that allow inbound HTTP and HTTPS access. The documented rules allow TCP port 80 (HTTP) and TCP port 443 (HTTPS) from 0.0.0.0/0, which means any IPv4 address. If your VPC is enabled for IPv6, you can add matching rules for port 80 and port 443 from ::/0, meaning any IPv6 address. TCP has protocol number 6. You may see that number in rule listings.

Add these rules to one of the groups attached to the instance. Do not add them to an unrelated group.

Four inbound rules open HTTP and HTTPS to any IPv4 or IPv6 address

You do not need to restart anything. You can change a security group's rules at any time, and new or modified rules are applied automatically to every instance associated with the group.

You also do not need a matching outbound rule for the replies. Security groups are stateful: responses to allowed inbound traffic may flow out regardless of the outbound rules. The reverse also holds. If your instance sends a request, the response may flow back in regardless of the inbound rules.

Statefulness lets the reply leave without an outbound rule once the request is allowed in

What you should see: reload the browser tab and the page should appear. If it still times out, a sensible next check is whether the web server is listening on the port you opened. A rule for 443 does nothing if the server only serves on 80.

Step 3 — Narrow SSH to your own address

Goal: keep your administrative access and close it to everyone else.

To connect to a Linux instance, the security group must have an inbound rule allowing SSH, which is TCP port 22. Windows instances use RDP on port 3389 instead. The documented source for that rule is not "anywhere". It is the public IPv4 address of your computer, or a range of addresses in your local network. If your VPC is enabled for IPv6 and your instance has an IPv6 address, you can enter an IPv6 address or range instead. Ranges are written in CIDR notation: an address followed by a slash and a prefix length, such as /32 for exactly one IPv4 address.

The difference between the web rules and the SSH rule is the point of this step. Your page is meant for everyone. Your shell is meant for you. A sensible default is to treat any port 22 rule with source 0.0.0.0/0 as a mistake to correct, even when it was added "just to get in".

In the group's inbound rules, find the SSH rule on port 22.
Change its source from 0.0.0.0/0 to your computer's public address with /32, or to your local network's range.
Save. The change applies automatically to every instance associated with the group.

What you should see: SSH from your own machine still works, and SSH from any other network no longer reaches the instance. Keep in mind that your public address can change when you move between networks. In practice, if you suddenly cannot connect from a new location, the source in this rule is the first thing to update.

Web ports face the whole internet while SSH faces only your own address

Step 4 — Stop sharing keys by connecting through EC2 Instance Connect

Goal: control who may SSH in through permissions rather than by passing private key files around.

Narrowing the source address limits where SSH can come from. It does not decide who holds the key. EC2 Instance Connect addresses that second question. It provides a secure way to connect to Linux instances over SSH. It uses identity and access management policies and principals to control SSH access, which removes the need to share and manage SSH keys. Every connection request made with EC2 Instance Connect is logged, so you can audit connection requests.

Here is how a connection works. The EC2 Instance Connect API pushes an SSH public key to the instance metadata, where the key remains for 60 seconds. An access policy attached to your user is what authorises you to push that key. On the instance, the SSH daemon uses two settings, AuthorizedKeysCommand and AuthorizedKeysCommandUser, which are configured when EC2 Instance Connect is installed, to look up the public key in the instance metadata and authenticate you.

Think of it as a visitor badge printed at reception: it is issued to a named person, it works only briefly, and the desk keeps a record. A long-lived key file is more like a house key that can be copied and lent without anyone knowing.

Instance Connect pushes a short-lived key that the SSH daemon looks up to authenticate you

You can connect with EC2 Instance Connect from the Amazon EC2 console or from the SSH client of your choice. It costs nothing extra. As of 2026-10-14, it is available in all AWS Regions except the European Sovereign Cloud (Germany), and it is not supported in Local Zones.

One point is easy to miss. Instance Connect still connects over SSH, so the port 22 rule from Step 3 still matters. Instance Connect decides who is allowed, and the security group decides from which address. In practice you want both controls in place.

What you should see: a shell session opens without you having copied a private key onto your machine. Each attempt is recorded in the audit log.

Step 5 — Clean up what you opened

Goal: leave nothing exposed that you no longer need.

Security is a shared responsibility. Security groups are one tool, and you have to configure them to meet your own needs. That responsibility includes removing things as well as adding them. Rules can be modified at any time, you can change an instance's security groups after launch, and you can delete a security group.

A sensible teardown order:

Remove any temporary rule you added while debugging, especially an SSH rule open to 0.0.0.0/0.
If you are finished with the instance, remove it before deleting groups, so no group is still associated with something running.
Delete any security group you created only for this exercise.

Security groups carry no additional charge. Cost is therefore no reason to delete them. The reason is exposure: a forgotten wide-open group can later be attached to a new instance by mistake.

Teardown removes risky rules first, then the instance, then the groups made for the exercise

When the security group is not the whole story

Security groups are not the only possible filter. If your requirements go beyond what security groups provide, you can run your own firewall on the instance as well. If you or a setup script has done that, a correct security group can still sit in front of a host firewall that blocks port 80. Also, if the instance sits behind a load balancer, the load balancer's own security group must allow communication with the instances. In that design, the browser's traffic meets the load balancer's rules first.

Key takeaways

A page that times out on a fresh instance is most often a missing inbound rule. Check every security group attached to the instance, because all of their rules are evaluated together.
Web traffic needs inbound TCP 80 and 443 from 0.0.0.0/0, plus ::/0 when the VPC uses IPv6. Rule changes apply at once, and statefulness lets replies out without an outbound rule.
SSH on port 22 should come from your own public address or local range, never from everywhere.
EC2 Instance Connect replaces shared keys with policy-controlled, short-lived keys and logged connection requests, but it still needs the port 22 rule.
Clean up deliberately: remove temporary open rules first, then delete groups made only for the exercise.

This article does not settle everything a stuck page can involve. It does not cover a web server that is not listening, a firewall on the instance itself, or what happens to the instance's public address when you stop and start it, which the source pages used here do not describe. It also explains each change in terms of the rules to set, not the exact command-line syntax, which those pages do not give.

🔐 Use the AWS CLI Without Access Keys, and Prove a Policy Before You Attach It (Hands-on)

TechEazy Consulting — Sun, 11 Oct 2026 05:13:28 +0000

🎤 The interview question

"How do you use the AWS CLI without an access key, and how do you know a policy works before you attach it?"

The strong answer is two things you have actually run: sign the CLI in with aws login, and prove the policy in the IAM policy simulator first. 20 minutes. 👇

👉 Flow: Sign in without a key → Write the policy → Prove it in the simulator → Store it, look, delete

🧰 Before you start

💻 AWS CLI v2, version 2.32.0 or later (aws login needs it). Check with aws --version.
👤 Signed in to the console as your everyday admin IAM user (not root). It needs the SignInLocalDevelopmentAccess managed policy or broader, e.g. AdministratorAccess.
🔑 Permissions used: iam:SimulateCustomPolicy, iam:CreatePolicy, iam:GetPolicyVersion, iam:DeletePolicy.
🌍 Region: ap-south-1, or your usual one.
💵 Cost: $0. IAM and STS are free, and the simulator sends no real request to any service. No Free plan credits used.

🔐 Step 1: Sign the CLI in without a key

Why: an access key works until someone deletes it; one pushed to GitHub is a stolen account. aws login reuses your console sign-in and gives the CLI temporary credentials (refreshed every 15 minutes, 12 hours max).

aws --version
aws login

At AWS Region [us-east-1]: type ap-south-1. In the browser, pick your user, then return.

✅ Expected: aws-cli/2.32.0 or newer, then Updated profile default to use arn:aws:....

Now ask "who am I?" (it needs no permissions, so run it first whenever something is denied):

aws sts get-caller-identity
aws configure list

✅ Expected: an Arn ending in your user name, and login in the TYPE column.

⚠️ If aws login is rejected as an unknown command → your CLI is older than 2.32.0. Update: curl -fsSL https://awscli.amazonaws.com/v2/install.sh | bash. If you see an old user or ExpiredToken → an access key in ~/.aws/credentials wins. Delete it and log in again.

📝 Step 2: Write a read-only policy

Why: interviewers listen for "least privilege": list one bucket, read its objects, nothing else. The bucket needn't exist yet.

BUCKET=hoc-site-ar-4821
mkdir -p ~/hoc-unit2 && cd ~/hoc-unit2
cat > hoc-read-policy.json << EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {"Sid": "ListTheBucket", "Effect": "Allow", "Action": "s3:ListBucket", "Resource": "arn:aws:s3:::${BUCKET}"},
    {"Sid": "ReadItsObjects", "Effect": "Allow", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::${BUCKET}/*"}
  ]
}
EOF

👀 Note the two ARNs: ListBucket acts on the bucket, GetObject on the objects (/*).

🧪 Step 3: Prove it in the simulator

Why: the simulator answers "would this be allowed?" without touching anything or saving the policy. A helper makes each test one line:

sim() { aws iam simulate-custom-policy --policy-input-list "$(cat "$1")" \
  --action-names "$2" --resource-arns "$3" \
  --query 'EvaluationResults[0].EvalDecision' --output text; }

sim hoc-read-policy.json s3:ListBucket arn:aws:s3:::$BUCKET
sim hoc-read-policy.json s3:GetObject  arn:aws:s3:::$BUCKET/index.html
sim hoc-read-policy.json s3:PutObject  arn:aws:s3:::$BUCKET/index.html

✅ Expected: allowed, allowed, implicitDeny (the only other answer is explicitDeny).

📚 Why implicitDeny? The full chapter explains how AWS decides, with an eight-request test list for this policy.

🧨 Break it on purpose

Put ListBucket on the object ARN, a classic beginner bug:

sed "s#\"arn:aws:s3:::${BUCKET}\"}#\"arn:aws:s3:::${BUCKET}/*\"}#" hoc-read-policy.json > broken.json
sim broken.json s3:ListBucket arn:aws:s3:::$BUCKET

✅ Expected: implicitDeny. Wrong resource ARN, so listing fails, and you caught it before a real user did.

📦 Step 4: Store it, look at it, delete it

Why: the clean-up habit. Created, never attached, deleted.

POLICY_ARN=$(aws iam create-policy --policy-name hoc-read-site-bucket \
  --policy-document "$(cat hoc-read-policy.json)" \
  --tags Key=project,Value=hands-on-cloud \
  --query Policy.Arn --output text)
echo "$POLICY_ARN"
aws iam get-policy-version --policy-arn "$POLICY_ARN" --version-id v1 \
  --query 'PolicyVersion.Document.Statement[].Sid'

✅ Expected: arn:aws:iam::<your account ID>:policy/hoc-read-site-bucket, then ["ListTheBucket", "ReadItsObjects"].

🧹 Cleanup

aws iam delete-policy --policy-arn "$POLICY_ARN"
rm -f ~/hoc-unit2/broken.json
aws logout

✅ delete-policy prints nothing. After aws logout, get-caller-identity fails: no credentials left. 🎉

💬 Say it in the interview

"I never create access keys for my own CLI: aws login gives it temporary credentials that expire on their own. Before a policy goes anywhere, I run the requests that must be allowed and must be denied through the IAM policy simulator, and fix it until they match."

🎯 What you can now say

✅ "My CLI signs in with aws login, not a key"
✅ "First command when denied: aws sts get-caller-identity"
✅ "ListBucket needs the bucket ARN, GetObject the object ARN"
✅ "I prove a policy in the simulator before I attach it"

📚 Go deeper

This is the hands-on cut of Session 2 of our free Hands-on Cloud for Freshers course: the three rules AWS decides by, and the model answer.

👉 Read the full chapter on TechEazy Consulting

🚀 Real projects and a real internship certificate get you hired. Start at TechEazy Consulting.

🛡️ New AWS Account? Stop Surprise Bills in 10 Minutes (Hands-on)

TechEazy Consulting — Sun, 11 Oct 2026 04:28:20 +0000

🎤 The interview question

"You just opened a new AWS account. How do you make sure a mistake can't quietly cost you money?"

Freshers get asked this a lot. A good answer is three things you have actually done: know your plan, set an alert, and keep everything in one Region with one tag. Let's do all three in about 10 minutes. 👇

👉 Flow: Check plan → Budget alert → Free Tier usage → One Region + one tag

🧾 Step 1: Know which plan you're on

Since July 2025, a new AWS account picks a Free plan or a Paid plan.

💵 Both get USD $100 in credits at sign-up, and up to $100 more for completing activities
⏳ The Free plan ends after 6 months or when credits run out, whichever is first
🔒 When it ends, the account closes. You have 90 days to upgrade before your data is deleted

Check yours: AWS Console → Billing and Cost Management → Home (credit balance and plan are shown there).

✅ Interview line: "I know which plan I'm on and when it ends."

🔔 Step 2: Create a budget that emails you

Set your account ID once:

ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)

Create a $1 monthly budget that emails you at 80%:

aws budgets create-budget \
  --account-id "$ACCOUNT_ID" \
  --budget '{"BudgetName":"freshers-1-usd","BudgetLimit":{"Amount":"1","Unit":"USD"},"TimeUnit":"MONTHLY","BudgetType":"COST"}' \
  --notifications-with-subscribers '[{"Notification":{"NotificationType":"ACTUAL","ComparisonOperator":"GREATER_THAN","Threshold":80,"ThresholdType":"PERCENTAGE"},"Subscribers":[{"SubscriptionType":"EMAIL","Address":"you@example.com"}]}]'

Confirm it exists:

aws budgets describe-budgets --account-id "$ACCOUNT_ID" --query 'Budgets[].BudgetName'

✅ Expected: ["freshers-1-usd"]

📊 Step 3: See your Free Tier usage

aws freetier get-free-tier-usage --region us-east-1

Each item shows the service, the limit and how much you've used. 👀 Run it after every lab.

💡 Also turn on Billing preferences → Receive AWS Free Tier alerts in the console. That's your second way to hear about spending.

🌍 Step 4: One Region, one tag

Pick one Region and stick to it, so nothing hides in a Region you never open:

aws configure set region ap-south-1

Tag everything you create in a lab:

aws ec2 create-tags --resources <instance-id> --tags Key=project,Value=freshers-lab

Find everything with that tag before you log off:

aws resourcegroupstaggingapi get-resources \
  --tag-filters Key=project,Values=freshers-lab \
  --query 'ResourceTagMappingList[].ResourceARN'

✅ An empty list [] = nothing left running. 🎉

🧨 Break it on purpose

Set the budget to $0.01, launch a t2.micro for an hour, and watch for the email. Then stop the instance. Now you know your alert works.

🎯 What you can now say in the interview

✅ "I know my plan and when it ends"
✅ "A budget emails me before I spend real money"
✅ "I check Free Tier usage after every lab"
✅ "I work in one Region and tag everything, so cleanup takes one command"

📚 Go deeper

This is the hands-on cut of Session 1 of our free Hands-on Cloud for Freshers course: the full chapter explains why each step matters and what interviewers listen for.

👉 Read the full chapter on TechEazy Consulting

🚀 Real projects and a real internship certificate get you hired. Start at TechEazy Consulting.

How to explain protecting the AWS root user and everyday admin access in an interview

TechEazy Consulting — Sun, 11 Oct 2026 03:18:47 +0000

The interviewer leans back and asks: "You've just created a new AWS account. What's the first thing you do about security?" Many freshers answer "enable MFA" and stop there. That answer is correct, but it is incomplete. A complete answer has two halves. First, lock the root user: give it a strong password and multi-factor authentication, create no access keys for it, and control who can recover it. Second, put it away: do everyday work through a separate administrative identity that uses temporary credentials. The rest of this article works through the questions you are likely to hear, answers each from current AWS IAM guidance (as of 2026-10-08), and ends with what to practise before you sit down.

The root user is the identity with complete access, so it is not for daily work

"What is the AWS account root user?"

When you first create an AWS account, it comes with a default set of credentials that have complete access to all AWS resources in the account, and this identity is called the AWS account root user. AWS strongly recommends that you don't use the root user unless you have a task that actually requires root user credentials. Instead, you create an administrative user for everyday tasks.

Think of it as the master key to a building. You don't carry it on your keyring for opening your office each morning. You lock it in a safe and use a key cut for the doors you need.

A good interview answer names both halves of the idea. The root user is powerful, so you protect it. It is also rarely needed, so you stop using it. Interviewers often listen for whether you mention the second half.

Lock the root user, then route everyday work through an administrative identity

Locking the root user means a strong password, MFA, and no access keys

"How would you secure the root user's credentials?"

Start with the password. AWS recommends a password that is strong and unique, and a password manager with strong generation can help. AWS also enforces minimum rules. The password must be 8 to 128 characters long and include at least three of these types: uppercase letters, lowercase letters, numbers and symbols. It also must not match the account name or email address.

Next, add multi-factor authentication (MFA), meaning a second proof of identity on top of the email address and password. All account types (standalone, management and member accounts) require MFA to be configured for their root user. If MFA is not already enabled, it must be registered within a grace period that begins at the first sign-in attempt to the console. You can register up to eight MFA devices of any mix of supported types, and AWS strongly recommends registering more than one for resilience.

Supported types include FIDO-certified hardware security keys, hardware tokens that show a six-digit time-based one-time password (TOTP), and virtual authenticator apps on a phone. Setting up a virtual device is done while signed in as the root user. You scan a QR code, then enter two consecutive codes from the app. That setup step also explains why spare devices matter. If you lose the only phone holding the virtual device and have no other device or recovery path, you cannot sign in, and you have to contact customer service to remove MFA from the account.

Then comes the point many freshers miss: don't create access keys for the root user. Access keys let you run commands in the command line interface or call the API from a software development kit (SDK). Root access keys would carry full access to every service and resource, including billing information. Root-only tasks are rare, so AWS recommends doing them by signing in to the console. If programmatic access is genuinely needed, the aws login command with root credentials provides temporary, automatically rotated credentials instead of long-term keys.

Each root user control and the risk it closes

Putting it away means everyday work runs through temporary credentials

"If not the root user, then what do you use day to day?"

You create an administrative user, and from it you create other identities for the people who need access. AWS strongly recommends that users authenticate with temporary credentials. The right tool depends on how the accounts are set up.

For a single, standalone account, AWS points to IAM roles. A role has no standard long-term credential such as a password or access key. When you assume a role, you receive temporary security credentials for that session. For several accounts managed together through AWS Organizations, AWS points to IAM Identity Center workforce users. These let you manage users and their permissions centrally across accounts, either in Identity Center itself or through an external identity provider.

"So what's wrong with IAM users?"

IAM users have long-term credentials such as passwords and access keys. Current guidance is that human users should use federation (signing in through an identity provider) to get temporary credentials. IAM users should be kept for specific cases that federated users cannot handle. Two such cases are emergency access and workloads that cannot use IAM roles.

If you do create an IAM user, the guidance still applies. Create only the credentials the user needs, so a console-only user gets no access keys. Manage permissions through groups rather than attaching them one user at a time. You can also set a permissions boundary, which caps the maximum permissions a user can have without granting any.

Roles and Identity Center hand out temporary credentials; IAM users carry long-term ones

A useful rule for interviews, offered here as judgment rather than as AWS wording: choose a role or a federated identity by default, and choose an IAM user only when you can name the specific reason a temporary credential won't work.

No single person should hold every key to the root user

"Who should have access to the root user's credentials?"

Only people with a strict business need. Don't share the root password, MFA, access keys or signing certificates with anyone else. AWS goes further and suggests multi-person approval. One group of administrators holds the password, another group holds the MFA, and one member from each group must come together to sign in as root.

Think of it as a bank vault that needs two keyholders to open. Neither can open it alone, so a single compromised or careless person is not enough.

Storage needs the same care. Don't store the root password in a tool that runs on AWS services inside the same account that password protects. If you lose the password, you also lose access to the tool holding it. Access to the password or to wherever it is stored should be logged and monitored.

"What email address should the root user have?"

Use a business-managed email address that forwards messages to a group of people. That way, if AWS needs to reach the owner, a reply doesn't wait on one person who is away, ill or has left. That address should not be used for anything else.

Recovery channels need the same protection as the password

"How would someone recover root access, and how do you protect that path?"

This is a strong follow-up, because recovery is a back door. You need access to the root email inbox to reset a lost password. If one MFA device fails, you can sign in with another device registered to the root user. If you have lost every MFA device, recovery requires both the email address and the phone number used to register the account, and both must be current and reachable.

The email inbox and the phone number are both verification channels for recovering the root password. For that reason, no one person should control both. AWS recommends two groups: one with access to the primary email address and another with access to the primary phone number.

Splitting recovery channels between two groups means no one person can recover root alone

With many accounts, member root credentials can be removed altogether

"How does this change when a company runs many AWS accounts?"

With AWS Organizations, every account has its own root user to secure. The account that creates the organization is the management account, and its root user must have MFA registered. The other accounts are member accounts.

For member accounts there are two strategies. The first is to centralize root access. You remove the member account's root password, access keys and signing certificates, and deactivate and delete its MFA, so the member account can no longer sign in as root or recover its root password. The second is to keep those root credentials and secure them with MFA. AWS recommends removing root credentials from member accounts. Where member root credentials stay enabled, a service control policy (an organization-wide permission guardrail) can deny all root actions except certain root-only ones.

Compliance tools can give a misleading signal here. MFA-related checks report "noncompliant" when root credentials have been removed, because there is no MFA left to find. After removal, those member accounts are evaluated as "not applicable". Mentioning this nuance tends to show real understanding rather than memorised rules.

Root sign-in should raise an alert that someone knows how to answer

"How would you know if someone used the root user?"

AWS recommends monitoring, alerting and reporting on root user sign-in and usage, including alerts that announce a root sign-in. The account's logging service records root sign-ins and privileged root sessions as separate events. Event rules can detect root credential use and notify a security administrator. Configuration and posture-checking services can flag a root user without MFA or with access keys.

An alert is only useful if someone acts on it. AWS says to have procedures so that whoever receives a root alert knows how to confirm the access was expected. They should also know how to escalate if they suspect an incident.

A root sign-in becomes an alert, then a check against expected work, then escalation if unexpected

What to practise before the interview

Answers stick when you have done the steps yourself. In a practice account, the following exercises are a sensible preparation:

Set a strong root password, then register two MFA devices, so you can explain why a single device is a risk.
Check that the root user has no access keys, and be ready to say why there should be none.
Create an administrative identity and sign in through it for everything else. In a standalone account, try assuming a role and notice that the session credentials are temporary.
Say aloud, in one breath, who holds the root password, who holds its MFA, who holds the recovery email and who holds the recovery phone.
Sketch the alert path for a root sign-in, ending with what the person who receives the alert should do.

Key takeaways

The root user has complete access to every resource in the account, so you lock it with a strong password and MFA on more than one device, and you never create root access keys.
After locking it, you put it away: everyday work goes through an administrative identity, and people sign in with temporary credentials from roles or IAM Identity Center rather than long-term IAM user credentials.
No single person should hold both the root password and its MFA, or both recovery channels (the email inbox and the phone number).
In an organization, removing member accounts' root credentials is the recommended approach, and root sign-ins everywhere should trigger alerts backed by a response procedure.

This article settles what to say about root-user protection and the shape of everyday administrative access. It does not cover how to design the permission policies that the everyday administrator and other users receive, and it does not list the specific tasks that still require root credentials. Those are the natural next questions an interviewer may ask.

How AI Agents Use Tools, Memory, and MCP to Get Work Done

TechEazy Consulting — Wed, 07 Oct 2026 01:59:29 +0000

A customer asks where a shipment is, whether it will arrive late, and what should happen if it does. A language model alone can produce a polished reply, but it cannot know the current location, inspect live conditions, or change a booking. An AI agent can do those things because it works in a loop: it chooses an action, asks a runtime to execute it, observes the result, and decides what comes next. Tools provide the actions, memory carries useful context, the Model Context Protocol standardises connections to external systems, and orchestration keeps the whole process moving toward a clear stopping point.

The agent loop turns an answer into a process

A single model call takes an input and produces an output. Even if that output is accurate and detailed, the model has no opportunity to act, inspect what happened, and revise its decision.

An agent adds that opportunity. Given a goal, it decides whether it has enough information to answer or needs an action first. After an action returns a result, the agent treats that result as new context. It can then call another tool, change direction, or finish.

Consider an agent handling a shipment question. It may first request the tracking record. If the record reports a disruption, the agent may inspect a schedule and current operating conditions before forming an answer. Each observation affects the next decision.

An agent repeats decisions and actions until it has enough evidence to answer.

Think of it as a doctor ordering a laboratory test. The doctor decides which test is needed, but the laboratory performs it. The result returns to the doctor, who interprets it and decides whether more investigation is necessary. The useful capability comes from the entire loop, not from either participant acting alone.

This distinction gives engineers a practical test: can an external result come back and change what the system does? If not, the application is using a model, but it is not operating as an agent.

Tools let the agent act without making the model the executor

A tool is an external function, API, or data source made available to the agent. It might retrieve a record, search a document store, calculate a value, update a ticket, or submit a booking.

The model does not execute the tool. It identifies the appropriate tool and produces the arguments for a requested call. The surrounding runtime validates and executes that request, then places the result into the model’s context. The model interprets the result and chooses the next step.

That division of responsibility matters. Saying that “the model queried the database” hides the component that actually controls credentials, network access, input validation, timeouts, and returned data. Those responsibilities belong to the runtime and its integrations.

For example, suppose an agent needs the stock level for a part. The model may request get_stock with a part identifier. The runtime calls the inventory system and returns the current quantity. Only then does the model construct its answer. Without the tool, it could generate a plausible quantity; with the tool, it can reason from the retrieved one.

The model requests an action; the runtime executes it and returns the result.

Tools are especially valuable when facts can change after a model was trained. Account state, inventory, schedules, policies, and reservations all require access to current systems. Tools also turn advice into action: instead of describing how to make a booking, an agent can request the booking and inspect its confirmation.

Access should still be bounded. A tool-enabled agent can only request actions exposed by its runtime, and the runtime remains responsible for deciding what is permitted. The agent loop provides flexibility; it does not remove the need for controlled execution.

MCP standardises the connection to external systems

Connecting one application to one tool can be straightforward. Connecting many AI applications to many databases, file stores, internal APIs, and other systems creates a larger integration problem. If every application needs a custom connector for every system, the work grows with every new pair.

The Model Context Protocol, or MCP, is an open protocol that standardises how an AI application connects models to external tools and data sources. Instead of teaching every application the private interface of every external system, each side implements a shared interface.

For an illustrative example, three applications connected independently to four systems require twelve bespoke integrations. With a common protocol, the three applications and four systems each implement their side of the interface, producing seven implementations. Adding another system then requires one new implementation rather than one connector for every application.

A shared protocol replaces many application-to-system connectors with one interface.

Think of MCP as a common electrical socket. Appliance makers build for the socket rather than negotiating a different connection with every building. The socket does not generate electricity or perform the appliance’s job; it only defines how the connection works.

Likewise, MCP does not replace tools. The database still answers queries, and the booking API still creates bookings. MCP standardises how those capabilities are presented and used. Tools can also work without MCP, particularly when a system has only a small number of stable integrations.

The endpoints provide the simplest boundary test: MCP connects an agent to an external system. It does not define how several agents communicate with one another. Agent-to-agent exchange requires communication patterns such as direct messages, shared state, broadcasts, or queues.

MCP is also neither a model nor a hosted service. It is a protocol that compatible applications and systems can speak. Treating it as a product obscures the integration problem it actually solves.

Memory carries selected context, not the entire past

A model is stateless between calls. If an agent needs earlier information, the application must supply that information again. Memory management is the deliberate choice of what to carry forward, how long to keep it, and what to discard.

Working memory contains material needed for the current task: recent turns, the active goal, intermediate decisions, and the latest tool result. Once the task ends, that state usually loses its value.

Persistent memory holds facts that must survive across separate sessions. Examples include a customer’s communication preference or a durable outcome from an earlier case. This information is stored outside the model and retrieved when it becomes relevant.

Task-local context stays in working memory; durable facts enter persistent memory.

Think of working memory as a desk and persistent memory as a filing cabinet. The desk holds the papers required for the current job. The cabinet holds durable records, but you retrieve only the folder relevant to the work in front of you.

Keeping everything is not a safe default. Re-supplying an entire conversation makes every call carry material that may no longer matter. Useful evidence can become harder to find among old details, while unnecessary retention increases cost and risk.

A strong memory policy therefore includes forgetting. A tool result needed for the next decision belongs in working memory. A lasting preference may justify persistent storage. A one-use verification code should be discarded. A long conversation is often better represented by a selected summary than by a verbatim transcript.

The design question is not “How can the agent remember more?” It is “What must survive, and what must not?”

Orchestration coordinates tools, memory, and specialist agents

Workflow orchestration owns the progress of an agentic task. It sequences steps, routes work, handles failures and retries, and decides when the task is finished. Without that control, an agent may have useful tools and memory yet still repeat actions, stall after an error, or stop before reaching the goal.

A deterministic workflow has developer-defined steps and branches. It is predictable, testable, and auditable, making it suitable when the permitted path must remain stable. A model-driven workflow lets the model choose each next step. It can adapt to unexpected situations, but its path may vary between runs.

For example, a routine record lookup can follow a deterministic sequence: validate the identifier, call the record tool, format the response, and stop. An investigation involving incomplete evidence may benefit from model-driven choices about which source to inspect next. The appropriate design depends on whether variation is useful or a defect.

Some tasks also justify multiple agents. The key test is whether the task spans genuinely distinct specialisms, not whether it merely contains many steps.

Bounded work stays with one agent; distinct specialisms justify coordinated agents.

A supervisor pattern uses a lead agent to divide work among specialists and assemble their findings. A sequential pattern passes each agent’s output to the next stage. A parallel pattern lets independent specialists work separately before their results are merged. A hierarchical pattern adds layers of supervision for deeper decomposition.

These structures do not determine how information travels. A supervisor can contact specialists directly or coordinate through shared state. Agents may broadcast an update to several peers or use a message queue when producers and consumers must remain decoupled. The system pattern is the org chart; the communication pattern is how the memos move.

Multiple agents add model calls, latency, failure modes, and debugging surface. A shipment lookup that only needs a tracking tool should remain with one agent. A disruption analysis requiring separate pricing, customs, and capacity expertise may justify a supervisor and specialists. Good orchestration can route those two cases down different paths instead of forcing every request through the larger system.

Key takeaways

An agent is defined by its loop: decide, act, observe, and decide again.
The model requests tool calls; the surrounding runtime executes them.
Tools give agents access to current information and real actions.
MCP standardises agent-to-system connections but does not replace tools.
MCP does not govern communication between agents.
Working memory serves the current task; persistent memory stores selected durable facts.
Orchestration controls sequencing, routing, failure handling, and completion.
One agent with good tools is the default; multiple agents need distinct specialisms to justify their cost.

These concepts explain how an agentic application gets work done, but they do not by themselves choose the right permissions, retention policy, tools, or workflow for a particular system. Those decisions depend on the task’s risks, required evidence, tolerance for variable behavior, and the consequences of an incorrect action.

Scaling Spring Boot with Auto Scaling Group (ASG) + Elastic Load Balancer (ELB)

TechEazy Consulting — Fri, 03 Oct 2025 06:24:09 +0000

Deploying a Spring Boot app on multiple EC2 instances with an Application Load Balancer (ALB) works great ✅
But what happens when traffic spikes? Or if one EC2 instance crashes?

👉 That’s where Auto Scaling Groups (ASG) step in.

By the end of this guide, you’ll know how to:

Create an AMI of your Spring Boot app
Build a Launch Template
Configure an Auto Scaling Group (ASG)
Integrate it with your Application Load Balancer (ALB)
Auto-scale your application 🚀

👉 Flow: Browser → ELB → ASG → EC2 Instances running Spring Boot

🔑 Pre-requisite

From the previous blog, you should already have:

✅ 2 EC2 instances with Spring Boot JAR deployed on port 8080

✅ Application Load Balancer (ALB) setup with a Target Group

📦 Step 1: Create an AMI (Golden Image)

We’ll use one existing EC2 as a base image (AMI).

Go to EC2 Dashboard → Instances
Select an EC2 instance where your Spring Boot app is running
From Actions → Image and Templates → Create Image
Name it: springboot-ami
Click Create AMI

⏳ Wait 8–10 minutes. This AMI will be the blueprint for new EC2s in the ASG.

📝 Step 2: Create a Launch Template

Launch Template = Recipe to spin up new EC2s.

Go to EC2 → Auto Scaling Groups → Create Auto Scaling Group
Under Launch Template, click Create new launch template
Fill details:

Name: springboot-template
AMI: Select My AMIs → springboot-ami
Instance type: t3.micro
Key Pair: Same as before
Security Group: Must allow 22 (SSH), 80 (HTTP), 8080 (Spring Boot)

Add User Data (to auto-start the app):

#!/bin/bash
cd /home/ubuntu
sudo nohup java -jar app.jar > app.log 2>&1 &

Click Create Launch Template ✅

⚙️ Step 3: Create Auto Scaling Group (ASG)

Back to Auto Scaling Group creation
Name: springboot-asg
Select the Launch Template you just created
Click Next

🌐 Step 4: Configure Network Settings

VPC → Default VPC
Subnets → Select available ones (where ALB exists)
Leave defaults → Next

🔗 Step 5: Integrate with Load Balancer

On Load Balancer settings:

Attach to existing Load Balancer
Select your Spring Boot Target Group (8080)
Enable ALB health checks for reliability

Click Next

📊 Step 6: Set Group Size & Scaling Policy

Define scaling behavior:

Desired capacity → 2 (start with 2 instances)
Minimum capacity → 1
Maximum capacity → 3

Add a scaling policy:

Policy type → Target tracking
Metric → ALB Request Count per Target
Target Group → springboot-tg
Target Value → 50 (scale out if >50 requests per instance)

✅ Step 7: Review & Create

Double-check everything
Click Create Auto Scaling Group

Your ASG is now active 🎉

🔍 Step 8: Verify Setup

Go to EC2 → Instances → You’ll see new instances launched by ASG
Open ELB → Target Group → Targets → Should show healthy instances
Try terminating one instance manually → ASG will auto-recreate it!

🧪 Step 9: Load Test Your Setup

To simulate traffic for 5 mins:

ab -n 1000 -c 50 http://<ALB_DNS_NAME>/api/adapt/welcome

(Using ApacheBench or any load testing tool)

🎯 ASG will launch new EC2s automatically if traffic increases.

🎯 Final Result

You’ve successfully:

✅ Created an AMI for your Spring Boot app

✅ Configured a Launch Template

✅ Built an Auto Scaling Group (ASG)

✅ Integrated ASG with your Load Balancer

✅ Enabled self-healing + scaling 🚀

Now your app can handle failures and traffic surges without manual effort 💪

✅ Next Steps 🚀

Be interview-ready in the era of AI & Cloud — start your DevOps journey today!

💡 YouTube won’t get you a job. Real projects + real internship certificate will.

🔥 AI is reshaping jobs. Don’t watch it happen, be part of it with DevOps & Cloud skills.

🎯 ₹2000/month today = Dream job tomorrow. Secure your spot now.

⏳ Every month you wait, Cloud + AI jobs are being filled. Don’t miss out!

🌐 DevOps + AWS + AI = The skillset every recruiter is hunting for in 2025.

👉 Register now at TechEazy Consulting

Deploy a Spring Boot App on AWS EC2 with Load Balancer (Step-by-Step Guide)

TechEazy Consulting — Sat, 27 Sep 2025 05:10:41 +0000

🌍 Introduction

Deploying your application manually on AWS can be time-consuming and error-prone. You might face:

Traffic distributed unevenly across instances ❌
Manual setup of health checks and failover ❌
Lack of scalability and high availability ❌

👉 That’s where EC2 + ELB (Elastic Load Balancer) deployment shines.

By the end, you’ll understand how to deploy a Spring Boot app on multiple EC2 instances, set up an Application Load Balancer, and route traffic intelligently.

👉 Flow: Browser → ELB → EC2 Instances running Spring Boot

🔒 Step 1: Prepare Your Spring Boot App

Before we touch AWS, package your Spring Boot project into a runnable .jar file:

mvn clean package

You’ll get something like app.jar in the target/ directory.

✅ We assume the app runs on port 8080
✅ Requires Java and Maven installed locally
✅ Target is .jar deployment, not Docker

We used the adaptive-ai-qms Spring Boot app as an example. But you can replace it with any web application and port according to app.

⚡ Step 2: Launch EC2 Instances

Let’s spin up two EC2 instances for our Spring Boot app:

Go to AWS Console → EC2 → Launch Instance
OS: Ubuntu Server 24.04 LTS (Free Tier eligible)
Instance type: t2.micro
Key Pair: Create/choose one (for SSH access)
Configure Security Group:

SSH (22) → Your IP
HTTP (80) → Anywhere
Custom TCP (8080) → Anywhere (for Spring Boot)

🎯 Launch two EC2 instances with the same configuration.

📜 Step 3: Install Java & Deploy Spring Boot App

SSH into both instances:

ssh -i your-key.pem ubuntu@<EC2_PUBLIC_IP>

Install Java:

sudo apt update
sudo apt install openjdk-21-jdk -y

Upload your app using scp:

scp -i your-key.pem app.jar ubuntu@<EC2_PUBLIC_IP>:/home/ubuntu/

Run the app in the background:

sudo nohup java -jar app.jar > app.log 2>&1 &

Breakdown:

nohup: Keeps process running after logout
java -jar: Runs your Spring Boot app
> app.log 2>&1 &: Logs output and runs in background

✅ Now access your app via:

http://<EC2_PUBLIC_IP>:8080/api/adapt/welcome

Repeat for the second EC2 instance.

🌐 Step 4: Create an Elastic Load Balancer (ALB)

Now we’ll route traffic to both EC2 instances via a Load Balancer.

Go to EC2 → Load Balancers
Click Create Load Balancer → Application Load Balancer
Name: springboot-alb
Scheme: Internet-facing
VPC: Use default VPC
Select AZs: Pick where your EC2s are running
Security Group:

Create a new one: springboot-sg
Inbound Rules: Allow HTTP (80) and SSH (22)

Listener Setup

Protocol: HTTP
Port: 80

Create Target Group

Type: Instances
Name: springboot-tg
Protocol: HTTP
Port: 8080
Health check path: /actuator/health/readiness

✅ Register your two EC2 instances
✅ Attach this Target Group to the Load Balancer
✅ Click Create Load Balancer

Your ALB is now live and routing traffic.

🧪 Step 5: Test Your Setup

🎯 Go to Load Balancer → Description tab
📄 Copy the DNS name (e.g., springboot-alb-123456.ap-south-1.elb.amazonaws.com)

Visit:

http://<DNS_NAME>/api/adapt/welcome

Expected Output:

Welcome to Adaptation Controller - Techeazy

✅ Confirms ELB is routing to healthy EC2 instances
✅ Confirms Spring Boot app is working across both instances

🛠 You can now explore:

Manual deployment
Creating AMIs
Using Launch Templates with Auto Scaling

🎯 Conclusion

You’ve successfully:

✅ Deployed a Spring Boot app on EC2
✅ Set up a Load Balancer to route traffic
✅ Configured health checks to ensure uptime
✅ Created a production-ready architecture for web-scale apps

👉 Next, pair this setup with Auto Scaling Groups for true elasticity and high availability.

✅ Next Steps

🚀 Be interview-ready in the era of AI & Cloud — start your DevOps journey today!
💡 YouTube won’t get you a job. Real projects + real internship certificate will.
🔥 AI is reshaping jobs. Don’t watch it happen, be part of it with DevOps & Cloud skills.
⏳ Every month you wait, Cloud + AI jobs are being filled. Don’t miss out!
🌐 DevOps + AWS + AI = The skillset every recruiter is hunting for in 2025.

👉 Register now at TechEazy Consulting

AWS Auto Scaling Groups (ASG) – Beginner’s Guide

TechEazy Consulting — Fri, 12 Sep 2025 06:16:10 +0000

🌍 Introduction

When you run an application on AWS, manual server management can be painful:

Sudden traffic spikes → servers run out of capacity ❌
Low traffic hours → paying for unused servers ❌

👉 That’s where AWS Auto Scaling Groups (ASG) come in.

ASG automatically adjusts the number of EC2 instances to match demand. This ensures:

✅ Cost efficiency

✅ High availability

✅ Scalability

By the end, you’ll understand:
👉 Browser → ELB → Auto Scaling Group (dynamic scaling + health checks) → Healthy EC2 Instances

🔒 Step 1: Understand Auto Scaling Group

An Auto Scaling Group (ASG) is a collection of EC2 instances that:

Scale out (add instances) when demand increases
Scale in (remove instances) when demand drops
Replace unhealthy instances automatically

This gives you a self-healing, cost-optimized infrastructure.

⚡ Step 2: Learn Key ASG Terminologies

Here are the basic terms you’ll see when setting up ASG:

Term	Meaning
Launch Template/Config	Blueprint defining AMI, instance type, key pairs, security groups
Desired Capacity	Number of instances you want running normally
Minimum Capacity	Lowest number of instances allowed
Maximum Capacity	Highest number of instances allowed
Scaling Policy	Rules to scale in/out (CPU > 70%, requests/sec, schedule-based)
Health Check	Ensures only healthy instances remain in service
Termination Policy	Decides which instance to remove first when scaling in
Warm Pools	Pre-initialized instances for faster scaling
Elastic Load Balancer	Commonly paired with ASG to distribute traffic among instances

📜 Step 3: How ASG Works

User visits your app → request hits ELB
ELB forwards traffic to instances in an Auto Scaling Group
ASG monitors metrics (CPU, requests, custom metrics) via CloudWatch
When demand increases → ASG launches new instances
When demand decreases → ASG terminates extra instances
If an instance becomes unhealthy → ASG replaces it automatically

👉 Flow: Browser → ELB → Auto Scaling Group → Healthy EC2 Instances

🌐 Step 4: Benefits of ASG

✅ Scalability – Adjusts capacity based on traffic automatically

✅ High Availability – Distributes instances across multiple AZs

✅ Cost Efficiency – Pay only for the resources you actually need

✅ Self-Healing – Replaces unhealthy instances automatically

✅ Flexible Policies – Scale by schedule, metrics, or custom triggers

🧪 Step 5: Real-World Example

Imagine an E-commerce website:

You set min=2, desired=3, max=6 EC2 instances
Traffic spikes during a festival sale → ASG launches 3 more instances (total 6)
At midnight, traffic drops → ASG scales back to 3 instances
If one instance crashes → ASG replaces it automatically 🎉

This means your app stays responsive + cost-efficient at all times.

🎯 Conclusion

With ASG, you get:

✅ Right number of instances at the right time

✅ Lower costs during low demand

✅ High availability with automatic healing

✅ Seamless scaling with ELB integration

👉 For web apps – Combine ASG with ALB for best results

👉 For scheduled workloads – Use scheduled scaling

👉 For unpredictable workloads – Use dynamic scaling policies

This is the recommended AWS setup for building cost-efficient, highly available, production-grade applications 🚀

✅ Next Steps

🚀 Be interview-ready in the era of AI & Cloud — start your DevOps journey today!

💡 YouTube won’t get you a job. Real projects + real internship certificate will.

🔥 AI is reshaping jobs. Don’t watch it happen, be part of it with DevOps & Cloud skills.

🎯 ₹2000/month today = Dream job tomorrow. Secure your spot now.

⏳ Every month you wait, Cloud + AI jobs are being filled. Don’t miss out!

🌐 DevOps + AWS + AI = The skillset every recruiter is hunting for in 2025.

👉 Register now at TechEazy Consulting

Originally published at https://blog.techeazyconsulting.com on September 12, 2025.

AWS Elastic Load Balancer (ELB) – Beginner’s Guide

TechEazy Consulting — Mon, 08 Sep 2025 06:44:44 +0000

🌍 Introduction

When you run an application on AWS, having just one server (EC2 instance) is risky:

If that server fails → your app goes down ❌
If too many users visit → server may crash ❌

👉 That’s where Elastic Load Balancer (ELB) comes in.

AWS ELB automatically distributes traffic across multiple servers (EC2, containers, Lambda). This ensures:
✅ High availability
✅ Scalability
✅ Fault tolerance

By the end, you’ll understand:
👉 Browser → ELB (smart routing + health checks) → Healthy Servers (EC2, ECS, Lambda)

🔒 Step 1: Understand ELB Types

AWS provides different types of load balancers for different use cases:

1️⃣ Application Load Balancer (ALB)

Works at Layer 7 (Application Layer)
Best for HTTP/HTTPS traffic
Supports content-based routing (host, path, headers)
Example: /api/* → API servers, /images/* → image servers

2️⃣ Network Load Balancer (NLB)

Works at Layer 4 (Transport Layer)
Handles TCP/UDP/TLS traffic
Extremely fast + scalable (millions of requests/sec)
Provides static IPs
Example: gaming, IoT, high-performance apps

3️⃣ Gateway Load Balancer (GWLB)

Works at Layer 3 (Network Layer)
For 3rd-party appliances (firewalls, intrusion detection)

4️⃣ Classic Load Balancer (CLB)

Legacy version
Works at Layer 4 & 7 (limited features)
⚠️ AWS recommends using ALB or NLB instead

⚡ Step 2: Learn Key ELB Terminologies

Here are the basic terms you’ll see when setting up ELB:

Term	Meaning
Target	Resource receiving traffic (EC2, Lambda, IP)
Target Group	A pool of targets (with health checks)
Listener	Process that checks for connections (protocol + port)
Listener Rule	Routing conditions (e.g., `/api/*` → API group)
Health Check	ELB test to ensure only healthy servers get traffic
AZ (Availability Zone)	AWS data centers where servers run
Cross-Zone LB	Distribute traffic across all AZs
Sticky Sessions	Keep same user on the same server
Security Groups	Firewall for ELB
Idle Timeout	Time before idle connections close
SSL/TLS Cert	Enables HTTPS (via AWS ACM)

📜 Step 3: How ELB Works

User visits your app (e.g., myapp.com)
Request goes to ELB Listener (port 80 or 443)
ELB checks Listener Rules
ELB forwards request to the correct Target Group
Health Check ensures only healthy servers receive traffic
Response goes back → ELB → user

👉 Flow: Browser → ELB → Healthy Server → ELB → Browser

🌐 Step 4: Benefits of ELB

✅ Scalability – Auto-scales with traffic
✅ High Availability – Multi-AZ support
✅ Security – SSL/TLS, WAF integration
✅ Monitoring – CloudWatch metrics, access logs
✅ Cost Efficient – Pay-as-you-go pricing

🧪 Step 5: Real-World Example

Imagine an E-commerce website:

You run 3 EC2 instances in different AZs
Deploy an Application Load Balancer in front
A user goes to www.shop.com → ELB receives request
ELB checks which server is healthy + least busy
Routes request → Server responds → User gets page
If one server crashes → traffic reroutes to healthy ones 🎉

🎯 Conclusion

With ELB, you get:

✅ Better performance
✅ Zero downtime (if a server fails)
✅ Intelligent routing
✅ Secure connections

👉 For websites → ALB
👉 For high-performance TCP apps → NLB
👉 For firewalls/security → GWLB

This is the recommended AWS setup for building highly available, production-grade applications 🚀

✅ Next Steps

🚀 Be interview-ready in the era of AI & Cloud — start your DevOps journey today!

💡 YouTube won’t get you a job. Real projects + real internship certificate will.

🔥 AI is reshaping jobs. Don’t watch it happen, be part of it with DevOps & Cloud skills.

🎯 ₹2000/month today = Dream job tomorrow. Secure your spot now.

⏳ Every month you wait, Cloud + AI jobs are being filled. Don’t miss out!

🌐 DevOps + AWS + AI = The skillset every recruiter is hunting for in 2025.

DEV Community: TechEazy Consulting

What an AWS Lambda function is, and what its execution role decides

A Lambda function is code plus configuration, run only on demand

The handler is a contract that is called once per request

The execution role is the only thing deciding what your code may touch

The default role explains the classic 502

Who may call the function is a separate decision

A small notes function shows each idea in a few lines

The log is the only witness to a single request

What to practise before the interview

Key takeaways

Links

Creating your first key-value table from the command line, and measuring what each read costs

The setup is small: one identity, one Region, one billing mode

The partition key is the first decision, because it is the item's identity

Items are written in typed JSON, and a reused key replaces silently

GetItem reads one item, because it walks straight to the key

Scan reads every item, and a filter does not make it cheaper

Query matches GetItem here, and earns its place with a sort key

Cleaning up leaves nothing to bill

Key takeaways

Links

Signing the AWS CLI in without access keys, then proving a policy in the simulator

The goal, and the three tasks that reach it

Version 2.32.0 is the floor for signing in without keys

aws login turns a console sign-in into temporary credentials

get-caller-identity proves who the CLI now is

The simulator answers "allowed or denied" without touching anything

A custom policy is proved with one command and a context value

Reading the result: the decision, the statement, the missing keys

Several resources now come back as one aggregate answer

Cleaning up: where the session lives, how to look at it, how to delete it

Key takeaways

Links

How to find the closed port that stops an EC2 web page loading, and lock down SSH

The page times out because no inbound rule admits web traffic

Step 1 — Read every security group on the instance, not just one

Step 2 — Add the web server rules and watch the page load

Step 3 — Narrow SSH to your own address

Step 4 — Stop sharing keys by connecting through EC2 Instance Connect

Step 5 — Clean up what you opened

When the security group is not the whole story

Key takeaways

Links

🔐 Use the AWS CLI Without Access Keys, and Prove a Policy Before You Attach It (Hands-on)

🎤 The interview question

🧰 Before you start

🔐 Step 1: Sign the CLI in without a key

📝 Step 2: Write a read-only policy

🧪 Step 3: Prove it in the simulator

🧨 Break it on purpose

📦 Step 4: Store it, look at it, delete it

🧹 Cleanup

💬 Say it in the interview

🎯 What you can now say

📚 Go deeper

🛡️ New AWS Account? Stop Surprise Bills in 10 Minutes (Hands-on)

🎤 The interview question

🧾 Step 1: Know which plan you're on

🔔 Step 2: Create a budget that emails you

📊 Step 3: See your Free Tier usage

🌍 Step 4: One Region, one tag

🧨 Break it on purpose

🎯 What you can now say in the interview

📚 Go deeper

How to explain protecting the AWS root user and everyday admin access in an interview

The root user is the identity with complete access, so it is not for daily work

Locking the root user means a strong password, MFA, and no access keys

Putting it away means everyday work runs through temporary credentials

No single person should hold every key to the root user

Recovery channels need the same protection as the password

With many accounts, member root credentials can be removed altogether

Root sign-in should raise an alert that someone knows how to answer

What to practise before the interview

Key takeaways

Links

How AI Agents Use Tools, Memory, and MCP to Get Work Done

The agent loop turns an answer into a process

Tools let the agent act without making the model the executor

MCP standardises the connection to external systems