DEV Community: Venkata Pavan Vishnu Rachapudi

From Selectors to Sentences: Why Nova Act and AgentCore Browser Are My New Go-To for UI Monitoring

Venkata Pavan Vishnu Rachapudi — Wed, 30 Sep 2026 17:50:57 +0000

I have used CloudWatch Synthetics canaries on real projects, and honestly, they were good enough.

Then AWS published synthetic monitoring with Amazon Nova Act, and it changed how I think about UI monitoring. The way we watch user journeys is shifting from selectors to sentences.

To keep this concrete, I will use my own site, vishnurachapudi.com, as the example. It has real journeys worth watching, like filtering posts and opening an article, and its HTML changes whenever I redesign it.

This is an architectural take, not a hands-on one. The hands-on comparison comes in part two.

How a canary would monitor my site

A CloudWatch Synthetics canary is a script running in a managed Lambda function on a schedule, written with Puppeteer, Playwright or Selenium. Each step finds an element by a CSS selector, then clicks, types and checks. Every run stores screenshots, a HAR file and logs in S3, and publishes success and duration metrics to CloudWatch.

For my "open a blog post" journey, the canary clicks a[href="#blog"], then the "Agentic AI" filter button, then the link to the post, and checks the heading.

A canary is cheap per run. The real cost sits elsewhere:

Maintenance. The next time I rename a class or move the filter tabs, the canary goes red even though the site works. Someone has to fix the script.
Artifacts on every run. Lambda time, a headless browser, and screenshots written to S3 every few minutes for every journey, most of which nobody opens.

So canaries are cheap to run and expensive to own.

The shift: from monitoring scripts to intent

With Amazon Nova Act, each step is an instruction in plain English. Nova Act looks at a screenshot of the page, decides where to click, and repeats until the instruction is done. It does not care whether the filter is a <button> or a <div>, only whether "Agentic AI" is visible on screen, the way a real visitor would.

The same four steps become a monitor anyone can read and review. You stop maintaining selector scripts and start describing what a visitor is trying to do.

I explored Nova Act on its own earlier this year (here is what broke and what it can do). What makes it production-ready is running it on AgentCore.

The building blocks

EventBridge Scheduler triggers the journey every 15 minutes. The same agent can also run from a CI/CD pipeline after each deploy, which turns a monitor into a release gate.
AgentCore Runtime hosts the agent with its own IAM role. This is where it becomes agentic: the agent has tools beyond the browser. It can publish metrics, send alerts, call an API, or check that a form submission actually arrived.
Amazon Nova Act turns each English instruction into browser actions.
AgentCore Browser runs every session in its own isolated environment, so every check runs in a private browser rather than on a shared machine. Session recordings go to an S3 bucket, so when a journey fails at 3 AM, I replay what the agent saw instead of guessing from a stack trace.
CloudWatch and SNS close the loop with a SuccessPercent metric, alarms, and an email or Slack alert.

One design note: in the AWS reference design, a failed journey arrives only as an SNS email. Have the agent publish its own SuccessPercent and Duration every run, plus a heartbeat alarm for runs that never report.

Beyond "is the page up?"

An uptime check tells you the server answers. UI monitoring tells you a visitor can actually do what they came for. With Nova Act on AgentCore, the same journeys give you three kinds of monitoring:

Journey monitoring: run the key journeys against production on a schedule.
Post-deploy checks: run them right after every deploy, before visitors notice a break.
Agentic checks: with runtime tools, the monitor can verify more than the screen, such as "the résumé button leads to a PDF that actually downloads".

The catch: your prompts are the new monitors

Natural language does not mean no engineering. Your prompts are now your monitors, and vague ones cause problems. An instruction like "find something interesting about AWS" gives the agent too much freedom. It can wander between sections, retry, or get stuck in a loop, and every extra step costs time and inference. AWS's own post notes adaptation succeeds around 90% of the time, so single-attempt checks can raise the occasional false alert.

What I would enforce from day one:

One intent per act() call. "Filter the posts by Agentic AI" beats "find the agentic posts and open the Nova one".
Explicit assertions. Use act_get() with a schema, such as a boolean, rather than trusting the agent "probably finished".
Bound the steps. Cap steps per instruction so a confused agent fails fast.
Keep secrets out of prompts. Type passwords through the browser page, not inside the instruction.
Choose how strict each prompt is. If a redesign hides the Writing link inside a menu, a canary goes red, while an agent may find it and pass, even though visitors now struggle. Decide which behaviour you want for each journey.

Trade-offs at a glance

	Synthetics canary	Nova Act + AgentCore Browser
Steps written as	Code with selectors	Natural language
Behaviour	Deterministic	Adapts to UI changes
Maintenance	High when the UI changes	Low
Run time	Seconds	Minutes
Best cadence	Down to every minute	Every 5-60 min, or per deploy
Latency tracking	Strong	Weak: model time included
Per-run cost	Low	Higher: model calls + browser time
Tools beyond the browser	Script only	Full agent tools
Evidence	Screenshots + HAR in S3	Session recordings in S3
Metrics	Built in	Publish from the agent

My take

Canaries are not going away. For one-minute heartbeat checks, API monitoring and latency SLOs, they are still the right tool.

But for UI monitoring, especially journeys that change often or cross third-party pages like SSO or payment, Nova Act on AgentCore Browser is where I would start today. You get natural-language journeys instead of selector scripts, monitors that survive a redesign, a private browser with recordings in S3, and a runtime with tools that makes monitoring truly agentic.

The engineering work does not disappear. It moves from maintaining selectors to writing clear, bounded, well-asserted instructions, and to publishing the metrics you need.

References: Implementing synthetic monitoring using Amazon Nova Act · aws-samples/sample-nova-act-synthetic-monitoring

How I Passed AWS Certified AI Business Strategist (AB1-C01 Beta)

Venkata Pavan Vishnu Rachapudi — Tue, 29 Sep 2026 13:42:25 +0000

I passed the AWS Certified AI Business Strategist (AB1-C01) beta on 29 Sep 2026, the day it launched, with a score of 743 / 1000. It's my 15th AWS certification. This guide covers everything I used and everything I'd revise if I took it again.

AB1-C01 exam at a glance


Exam code	AB1-C01 (beta)
Questions	85
Time	3 hours (about 2 minutes per question)
Passing score	700 on a 100–1000 scaled score
Scoring	Compensatory: you pass on total score, not per domain
Validity	3 years
Level	Business. No coding and no console tasks.

AB1-C01 exam domains

Domain	Weight	What it tests
1. AI Fundamentals and Literacy	24%	AI vs ML vs GenAI, prompts, RAG, fine-tuning, when not to use AI
2. AI Strategy and Business Value Creation	28%	Use cases, ROI, build vs buy vs partner, proving value
3. AI Governance and Responsible AI Leadership	24%	Responsible AI, risk, drift, bias, standards
4. Business Readiness Leadership	24%	Readiness, adoption stages, scaling, Bedrock and SageMaker at a high level

Study resources: what I actually used

I used Stephane Maarek's course and the Skill Builder practice set, and nothing else. The Skill Builder learning plan is optional.

Resource	Time	Verdict
Stephane Maarek's AB1-C01 course (Udemy)	About 3.5 hrs	My main resource. Watch it once, then rewatch the review section.
Stephane Maarek's slides	Revision	Reread them the day before, because this is where the vocabulary sticks.
Stephane Maarek's practice questions	Varies	I did about 30. Do more if you can.
Skill Builder official practice question set	20 questions	Use it to calibrate yourself.
Skill Builder AI Business Strategist learning plan	12–13 hrs	Optional for anyone. I skipped it.

AB1-C01 vocabulary cheat sheet

Most of this exam is vocabulary. Know each of these terms in one line.

Term	What it means
AI / ML / GenAI	AI is the broad field. ML is a subset that learns patterns from data instead of following rules. GenAI is a subset of ML that creates new content.
Algorithm	The method or recipe used to learn from data
Training	Running the algorithm on historical data
Model	The result of training: the learned patterns. You can't write one by hand.
Inference	Using the trained model on new data
Prediction	The output of inference, such as a score, a label or some text
Structured vs unstructured data	Rows and columns vs free text, images, audio and PDFs
Foundation model	A large pre-trained model you can use as-is or adapt
Token	A piece of a word. The unit a GenAI model counts for both capacity and cost.
Context window	The most tokens one exchange can hold, input and output together
Prompt engineering	Better output from better instructions, with no change to the model
RAG	Handing the model your documents at query time so answers use current facts
Fine-tuning	Retraining a copy of the model on your examples. It changes the weights and costs the most.
Hallucination	A confident answer that is wrong or made up
AI agent	A system that takes actions on its own, not just answers
Data drift	Live inputs no longer look like the training data
Model quality drift	Predictions get less accurate over time
Bias drift	Accuracy holds overall but gets worse for one group
Feature attribution drift	The inputs the model leans on have changed
Baseline	The before-state, measured before launch the same way you'll measure after
Transparency vs explainability	People know AI is involved, vs someone can give the reason for one specific outcome
Accuracy vs fairness	Accuracy is measured across everyone. Fairness is measured group by group.
Shadow AI	AI tools staff use without review or approval
Center of Excellence (CoE)	A central team that shares AI patterns, standards and advice. It should enable teams, not become a bottleneck.
ISO/IEC 42001	The certifiable AI management system standard, for governing AI across an organisation
ISO/IEC 23053	A framework standard that defines common vocabulary for ML-based AI systems
Amazon Bedrock	Managed access to foundation models through one API, with nothing to build or host
Amazon Bedrock Guardrails	Filters harmful content and masks sensitive data in prompts and answers
Amazon SageMaker AI	The platform for building, training and deploying your own models
SageMaker Clarify	Detects bias and explains predictions
SageMaker Model Monitor	Compares live data and predictions against a baseline and alerts on drift

AB1-C01 exam traps and decision rules

The ML chain, in order

Data → algorithm → training → model → inference → prediction. Know this order.
The algorithm is the recipe, and the model is the result. Inference is the action, and the prediction is its output.
There's no model without training, and no inference before a model exists.
Training cost is paid at launch and again each time you retrain. Inference cost is paid on every use, so it grows with usage.

Drift: when the model sees new data

A model can be right at launch and wrong six months later. Nothing crashes and no error is raised.
Watch four kinds of drift: data, model quality, bias and feature attribution.
Capture a baseline at training time. Compare live inputs and outputs to it on a schedule, then alert and retrain or fix the data source when a threshold is crossed.
Some problems look like drift but aren't: a capacity limit, a bad prompt, or normal day-to-day variation.

Tokens and the context window

Tokens decide what fits and what you pay.
Everything counts against the context window: the question, chat history, retrieved documents, examples and the answer.
A short question can reach the model as thousands of tokens.

Prompt, RAG or fine-tune

Always start with the prompt, because it's the cheapest.
If the model needs new knowledge, use RAG. Stale facts are a retrieval problem.
If it has the right facts but the wrong tone or format, fine-tune.

Which kind of AI, if any

An assistant gives an answer, a dashboard gives a view, a predictive model gives a score, and an agent takes an action.
Only an agent acts on its own. Choose one only when the task truly needs autonomous action.
Some things that sound like AI only need rules. Rules are cheaper and don't drift.

Build, buy or partner

Build when your advantage lies in your own data or logic.
Buy when you need speed and the capability doesn't set you apart.
Partner when you lack expertise you can't hire in time.
The answer depends on each use case, not on a company-wide policy.

Envision → Experiment → Launch → Scale

Envision: exploring opportunities, with nothing in production.
Experiment: controlled pilots, where success means learning.
Launch: proven pilots in production, with value measured.
Scale: AI across functions, with governance and continuous improvement.
Some AWS material calls stage two "Align." The exam uses "Experiment."
Readiness is set by your weakest dimension, not by an average.

Prove the value

Record a baseline before launch. Without one, an improvement is a claim, not evidence.
Attribution means showing the AI caused the change, not just that the number moved.
Every initiative ends in one of three decisions: scale, pause with a fix and a date, or terminate.
Money already spent is never a reason to continue.

Governance and risk

Risk class = severity of a wrong outcome × likelihood. Regulated uses never sit below high.
Reassess the risk when the use changes, for example when an internal tool starts facing customers.
Confidence-based routing lets the system decide when it's confident and sends the rest to a person.
ISO 27001 and SOC 2 are security certifications, not AI governance. A vendor's "Responsible AI" page is marketing, not proof.
When you find shadow AI, give people an approved path first. Punishment doesn't fix it.

AWS CAF, ROI and cost tools

AWS Cloud Adoption Framework (CAF): AWS guidance for assessing readiness across six perspectives: Business, People, Governance, Platform, Security and Operations. Its phases are Envision, Align, Launch and Scale.
ROI: (value gained − total cost) ÷ total cost. Count the running costs, such as inference, monitoring and people, not just the build.
AWS Pricing Calculator: estimates the cost of a proposed solution before you build it. Use it for the business case.
AWS Cost Explorer: shows what you are actually spending. Tag each AI initiative so its cost can be tracked on its own.
Savings Plans: a 1- or 3-year spend commitment in exchange for lower prices. They suit steady, predictable workloads, not early pilots.

More AB1-C01 key concepts, by domain

Domain 1: AI fundamentals

Four data quality checks: completeness (fields present), consistency (one entity, one record), currency (the data reflects today's process), and representativeness (every group the model serves is covered).
Bad data needs a data fix. Fix it at the source, then retrain. A smarter model, more data of the same quality, or more dashboards won't fix it.
The rule test: if the same input always gives the same correct output, write a rule instead of using AI.
"The answers are bad" has four causes, each with its own fix:

Complaint	Problem	Fix
Wrong tone, shape or format	Instructions	Prompt engineering
Fails only on long inputs	Capacity	Context window management
Stale or missing facts	Knowledge	RAG (grounding)
Right facts, wrong behaviour	Behaviour	Fine-tuning

"Give it more data" is never the fix by itself.
Signs of a capacity problem: it forgets earlier turns, answers badly only on long documents, or cuts answers off mid-sentence.
AWS service map:
- Amazon Bedrock: you choose a foundation model, you never train one.
- Amazon Quick: a ready-made AI business assistant on company data that respects each user's access rights.
- Amazon SageMaker AI: for building and training your own models.
- AWS Marketplace: third-party AI software, models, datasets and partners, billed through your AWS account. It's also a way to offer approved tools instead of shadow AI.

Domain 2: Strategy and business value

A use case has three parts: the AI capability, the mechanism (how the work changes), and the business outcome. If one is missing, it's a wish, not a use case.
Start from the outcome, not the technology. "Add a chatbot" is a technology looking for a problem.
Decide in this order: outcome, then feasibility, then budget. Reversing the order is the classic mistake.
Five things that can override build, buy or partner: budget, timeline, internal skills, strong vendor offers, and regulation.
Missing skills mean buy or partner. "Delay until we hire" and "terminate" are both distractors.
Rank a portfolio on four criteria: business value, feasibility, sustainability (can it be run and funded for its whole life), and strategic alignment.
Four portfolio traps:
- Sunk cost: money already spent is gone, so it's no reason to continue.
- The quiet drain: an initiative nobody reviews keeps eating budget.
- The platform switch: moving to a new platform changes the bill, not the outcome.
- Data not ready: that's a feasibility gap, so pause and fix the data.
KPIs are chosen before launch so the baseline can be recorded. Use tangible KPIs (convert to money) and intangible ones (satisfaction, productivity). Leaving out the intangibles understates value.
A good KPI measures the outcome and the quality of the process. It doesn't measure inputs like headcount or budget, or infrastructure like uptime or latency.
Lagging vs leading indicators: cost and revenue impact shows up months later. Adoption, quality trend and delivery milestones in months 1–3 predict it.
Four kinds of AI initiative:
- Scaling: more of the business
- Optimisation: a better decision in an existing process
- Process improvement: a redesigned process
- Transformation: new customers, revenue or market position. Only transformation creates value outside the company.
What isn't a durable advantage: being first, spending more, or building rather than buying. Your own data is what can make it durable.
Switching platforms is an iceberg. You see the new feature and the better price. You pay for data migration, rebuilt integrations, rewritten prompts and retrained people.
GenAI is billed per token for as long as it runs. The right spend is whatever the KPIs justify, not the lowest possible.

Domain 3: Governance and responsible AI

The eight dimensions of responsible AI: fairness, explainability, privacy and security, safety, transparency, veracity and robustness, controllability, and governance.
Governance starts at planning, when changes are still cheap.
When a human must be in the loop: the decision affects rights, health, safety, money or access to a service; it's hard to reverse; or it's regulated. AI can decide alone when the stakes are low, the action is easy to undo, and the model is confident.
Five safeguards sit between the model output and the final answer: a confidence threshold, hallucination detection, guardrails, written escalation criteria, and an audit trail.
Risk comes from the use, not the technology. One model can carry two risk classes for two different uses.
Obligations attach to the process. Replacing a person with a model keeps every obligation and adds some.
Bias can enter through the framing of the problem and through the data. Retraining on skewed data reproduces the skew. The fix is ongoing fairness monitoring by group, with a threshold and an owner.
Control harmful content at the boundary, on both inputs and outputs: filter, deny topics, mask data, refuse.
Three families of data security: encrypt data at rest and in transit, mask or remove fields the task doesn't need, and log access. No log means no proof for the auditor.
Least privilege: give each person and system only the access it needs.
Shared responsibility model: AWS handles security of the cloud, and you handle security in the cloud (your data, access, configuration, and what you send to a model). A managed service reduces your work, never your responsibility.
AWS Well-Architected lenses: the Responsible AI Lens and the Generative AI Lens.

Domain 4: Readiness and transformation

Readiness has five dimensions: leadership, data, culture, infrastructure and governance. Your readiness is your lowest bar. Name the exact gap ("no owner for the returns data"), not a vague score.
Four capability gaps to invest in: people, process, technology and governance.
Prioritise by dependency (people before process), align with the strategy, and move one stage at a time.
Four ways to build AI skills:
- A proof of concept, when you need evidence
- A hackathon, when you need ideas and energy
- A training programme, when many people share a known skill gap
- Responsible AI training, for anyone who builds, approves or relies on AI
Starting from zero, with fear in the workforce? Run a company-wide awareness programme first.
Roll out in waves and keep a way back. Run the manual process in parallel until each wave meets its criteria. The wrong answers are switching everyone at once, reacting to complaints, and waiting for a guarantee.
Short-term wins build credibility for the next wave.
AWS CAF is the answer for an organisation-wide readiness assessment.

AB1-C01 practice questions

These are my own practice questions, not real exam questions, written to test the concepts above.

1. A retailer wants a chatbot to answer from its return policy, which changes every week. What's the best approach?
A) Fine-tune the model every week B) Use RAG over the policy documents C) Train a new model D) Paste the policy into every prompt by hand

Answer
B. New or changing knowledge is a retrieval problem, so use RAG. Fine-tuning changes behaviour, not facts.

2. A loan model's overall accuracy is unchanged, but approvals for one age group have gotten worse since launch. What is this?
A) Data drift B) Bias drift C) A capacity limit D) A bad prompt

Answer
B. Accuracy holds overall but drops for one group, which is bias drift. SageMaker Clarify with Model Monitor can detect it.

3. A company needs GenAI text summarisation quickly. It doesn't set them apart from competitors, and they don't want to manage infrastructure. What fits best?
A) Build and train a custom model B) Use Amazon Bedrock C) Hire an ML research team D) Wait for the market to mature

Answer
B. It's buy, not build, because the capability isn't a differentiator. Bedrock gives managed access to foundation models.

4. A pilot claims a 20% drop in call handling time, but no one measured handling time before launch. What's the main problem?
A) The model is too small B) There is no baseline C) The pilot ran too long D) There was no fine-tuning

Answer
B. Without a baseline, the improvement is a claim, not evidence.

5. A pilot missed its targets. The sponsor wants to scale anyway because $500K has already been spent. What should happen?
A) Scale it B) Decide on evidence: pause with a fix and a date, or terminate C) Double the budget D) Extend the pilot indefinitely

Answer
B. Money already spent is never a reason to continue.

6. An internal HR summarisation tool is about to become customer-facing. What's the first thing to do?
A) Nothing, because it's already approved B) Reassess its risk classification C) Fine-tune it D) Turn off logging

Answer
B. A change in use changes the risk, so reassess the risk class.

7. Employees are pasting customer data into unapproved public AI tools. What's the best first response?
A) Discipline everyone involved B) Give them an approved, secure alternative and a clear policy C) Ignore it D) Block the internet

Answer
B. Shadow AI is fixed with an approved path. Punishment alone just pushes it underground.

8. You need to estimate the monthly cost of a proposed GenAI solution for a business case before building anything. Which tool?
A) AWS Cost Explorer B) AWS Pricing Calculator C) AWS Budgets D) SageMaker Clarify

Answer
B. The Pricing Calculator estimates cost before you build. Cost Explorer shows actual spend after.

9. An inference workload has run at steady, predictable usage for a year. How can you cut its cost?
A) Savings Plans B) Fine-tune it C) Use Cost Explorer only D) Move it to a pilot

Answer
A. Savings Plans trade a 1- or 3-year commitment for lower prices. They suit steady workloads, not early pilots.

10. A vendor offers its ISO 27001 certificate as proof of responsible AI governance. Is that enough?
A) Yes B) No. It's a security certification, so ask for AI governance evidence such as ISO/IEC 42001. C) Yes, if they also have SOC 2 D) Yes, if their website says "Responsible AI"

Answer
B. ISO 27001 and SOC 2 cover security, not AI governance.

11. In long chat sessions, the assistant starts "forgetting" what was said earlier. What's the likely cause?
A) Data drift B) The context window limit C) Bias drift D) Too much fine-tuning

Answer
B. Chat history uses up tokens in the context window. Once the window is full, earlier content drops out.

12. The model gets the facts right, but even with careful prompting its output never matches the brand's tone and format. What's next?
A) RAG B) Fine-tuning C) A bigger context window D) Rules-based logic

Answer
B. Right facts with the wrong tone or format is the case for fine-tuning.

Exam-day strategy: option elimination

Read the question for the business goal first: cost, speed, risk, or value.
Rule out the two options that clearly don't fit that goal.
Between the last two, pick the one that solves the business need with the least effort or risk.
Flag it and move on. At about 2 minutes per question, don't get stuck.
Save energy for the last hour. That's when every option starts to look right.

AB1-C01 FAQ

How hard is the AWS AI Business Strategist exam?
It's harder than it looks. There's no deep tech, but a lot of vocabulary, and many options that sound right. If you have an AI background, Domain 1 will be easy.

Do I need a technical background?
No. It's a business-level exam. Non-tech candidates should start with the ML chain and the vocabulary table above.

Is the Skill Builder learning plan required?
No. I passed with Stephane Maarek's course and the Skill Builder practice set only.

What's the best course for AB1-C01?
Stephane Maarek's course was the only course I used.

How long should I study?
A few focused days on the course, the slides and the practice questions. The Skill Builder learning plan is optional for anyone.

Who should take it?
Consultants, pre-sales, solution architects, product managers, and anyone who talks to business stakeholders about AI.

My AB1-C01 study plan

[ ] Watch Stephane Maarek's course (about 3.5 hrs)
[ ] Rewatch the review section and reread the slides
[ ] Do Stephane Maarek's practice questions
[ ] Take the 20-question Skill Builder practice set
[ ] Optional: the Skill Builder learning plan (12–13 hrs)
[ ] Eliminate options on exam day and keep a pace of about 2 minutes per question

Written by Vishnu Rachapudi, AWS Community Builder. More hands-on AWS guides at vishnurachapudi.com.

How Exporting AMIs to S3 Helped Me Recover Customer Resources During a DR Event

Venkata Pavan Vishnu Rachapudi — Tue, 17 Mar 2026 05:36:03 +0000

A few weeks ago, we were dealing with a situation that every cloud engineer eventually faces.

A customer environment needed to be recovered in another region, and we were under time pressure.

At that moment, one of the lesser-known AWS capabilities became incredibly useful.

Exporting AMIs directly to S3.

Using this approach, we were able to:

export the machine image
replicate it to another region
restore it as a new AMI
bring the customer workloads back online

Without needing to share KMS keys or redesign the environment.

That experience reminded me that sometimes the most useful AWS features are the ones people rarely talk about.

Let’s walk through how this works.

What is AMI Store and Restore?

AWS allows you to export an Amazon Machine Image (AMI) to an S3 bucket.

Instead of keeping the AMI only inside EC2 metadata, AWS converts it into a portable binary artifact.

This artifact can then be:

archived
replicated to another region
restored later as a new AMI

Think of it as creating a portable machine image backup.

Architecture Overview

Step 1 — Export the AMI to S3

aws ec2 create-store-image-task \
--image-id ami-xxxx \
--bucket demo-dr-us-east-1-backup \
--region us-east-1

AWS converts the AMI into a compressed .bin artifact.

Example response:

{
 "ObjectKey": "ami-xxxx.bin"
}

Step 2 — Monitor the Export Task

aws ec2 describe-store-image-tasks \
--region us-east-1

Possible states:

InProgress
Completed
Failed

Once completed, the artifact appears in S3.

Step 3 — Verify in S3

aws s3 ls s3://demo-dr-us-east-1-backup

Example output:

ami-0abc123.bin

Step 4 — Replicate to Another Region

Using S3 Cross Region Replication (CRR), the artifact can automatically move to another region.

Primary Region (USA)
        │
        ▼
S3 Bucket
        │
        │ CRR
        ▼
Backup Region (Mumbai)

This ensures the AMI artifact is safely stored in the DR region.

Step 5 — Restore the AMI

From the destination region:

aws ec2 create-restore-image-task \
--bucket demo-dr-ap-south-1-backup \
--object-key ami-xxxx.bin \
--name restored-ami \
--region ap-south-1

This creates a new AMI.

Check for the progess in the destination region AMI Console

Step 6 — Launch the Instance

aws ec2 run-instances \
--image-id ami-new \
--instance-type t3.medium

And the system is restored.

What Happens with KMS Encrypted AMIs?

During export:

AWS internally decrypts the snapshots
packages them into the artifact
restores them in the destination region with new encrypted snapshots

This means you don’t need to share KMS keys across regions, which is often restricted in enterprise environments.

When Should You Use This?

This approach is great for:

enterprise DR strategies
KMS encrypted instance migrations
long term infrastructure backups
cross account migrations
compliance driven archival

Disclaimer: Large AMI Exports May Take Time

When using create-store-image-task, the AMI is exported and stored in Amazon S3 as a binary .bin file.

If the AMI contains large EBS volumes, the resulting artifact can be tens or even hundreds of gigabytes.

In such cases, AWS uploads the image to S3 using multipart upload.

This means:

The export process can take significant time depending on the AMI size.
Multiple parts are uploaded in parallel to improve reliability.
The .bin file will only appear in S3 after the export task is completed.

Because of this, it's important to monitor the store task status before assuming the artifact is available.

You can check the task prsk progress using:

aws ec2 describe-store-image-tasks --region <region>

Final Thoughts

Most AWS engineers never touch store-image-task.

But it’s one of those hidden features that becomes incredibly useful when things go wrong.

In disaster recovery planning, the goal isn’t just backup.

The goal is portability and recovery independence.

Exporting AMIs to S3 gives you exactly that.

Secure Remote Access to AWS Resources from On-Premises

Venkata Pavan Vishnu Rachapudi — Tue, 17 Feb 2026 05:34:51 +0000

Modern AWS architectures avoid exposing networks and instead focus on intent-based access:

Application access
Administrative access
Controlled network access

This reference architecture demonstrates three secure access patterns from on-prem to AWS using:

AWS Client VPN
EC2 Instance Connect Endpoint
AWS Verified Access

Each pattern serves a distinct purpose and should be used together—not interchangeably.

Architecture Context

The VPC contains:

Private EC2 instances
Private RDS databases
Internal Application Load Balancer
No public subnets for compute
No inbound SSH or database ports

Remote users enter AWS only through explicit access services.

Flow 1: Application Access via AWS Verified Access

Use Case

Secure access to private web applications without VPN or public exposure.

Flow

Key Characteristics

Identity-based access
No network-level trust
No VPC-wide visibility
No public ALB required

Flow 2: Administrative EC2 Access via EC2 Instance Connect Endpoint

Use Case

Secure SSH access to private EC2 instances without bastion hosts or public IPs.

Flow

Key Characteristics

IAM-based authentication
Short-lived access
No inbound SSH rules
Fully auditable

Flow 3: Network-Level Access via AWS Client VPN

Use Case

Broad access to private AWS resources such as databases, internal APIs, or legacy tools.

Flow

Key Characteristics

Encrypted tunnel
Route-based access
Subnet-level reachability
Works well for legacy workflows

VPN vs Verified Access (When to Use What)

This is a common design decision, and the wrong choice often leads to overexposure.

Comparison Table

Aspect	AWS Client VPN	AWS Verified Access
Access Model	Network-level	Application-level
Trust Boundary	VPC/Subnet	Identity & policy
User Sees Network	Yes	No
VPN Client Required	Yes	No
Best For	DBs, legacy apps, tools	Web apps, dashboards
Lateral Movement Risk	Higher	Very low
Zero Trust Alignment	Partial	Strong

Simple Rule of Thumb

If users need a network → VPN
If users need an app → Verified Access

Why These Services Work Best Together

Requirement	Service
Internal web applications	AWS Verified Access
EC2 administration	EC2 Instance Connect Endpoint
Database / legacy access	AWS Client VPN

This layered approach ensures:

No over-privileged access
Clear separation of concerns
Reduced blast radius
Easier audits and compliance

Security Best Practices Highlighted

No public EC2 or RDS
No inbound SSH from on-prem
IAM-driven access
Explicit access entry points
Multi-AZ design

Final Thoughts

Secure remote access to AWS is not about choosing one tool.

It’s about:

Matching access method to intent
Avoiding unnecessary network exposure
Enforcing identity at the entry point

By combining:

AWS Verified Access
EC2 Instance Connect Endpoint
AWS Client VPN

you get a secure, scalable, and least-privilege remote access model from on-prem to AWS.

CloudWatch Is No Longer Just for Logs: Inside AWS’s Unified Operational Data Store

Venkata Pavan Vishnu Rachapudi — Tue, 17 Feb 2026 04:59:10 +0000

For a long time, CloudWatch Logs played a very limited role in our cloud operations.

Logs were something we:

Pushed into CloudWatch
Searched during incidents
Forgot about once the issue was resolved

That mental model no longer holds.

AWS has quietly re-architected CloudWatch into something much bigger — a unified operational data store. This change fundamentally alters how CloudOps, Platform, and SRE teams should think about logs on AWS.

This blog breaks down what changed, why AWS did this, and how it impacts real-world cloud operations.

The Big Idea: Logs Are Operational Data

The new CloudWatch Data Sources experience introduces a powerful shift:

Logs are no longer unstructured text — they are operational datasets.

AWS now treats logs the same way data platforms treat analytics data:

Collected centrally
Curated intentionally
Analyzed across multiple tools

This new model is built on three pillars:

Collect → Curate → Analyze

Let’s walk through each.

Collect: Centralized, Org-Level Log Ingestion

Earlier, collecting logs across accounts meant:

Subscription filters
Firehose streams
Custom Lambdas
Per-account maintenance

With the new model, CloudWatch supports organization-level enablement rules.

What this enables

Native ingestion from:
- VPC Flow Logs
- CloudTrail (Org or account scope)
- AWS service logs
Multi-account and multi-region coverage
Single control plane via AWS Organizations

Why this matters

For CloudOps teams managing large AWS estates, this removes a huge amount of undifferentiated work.

🔁 Collect Flow

Curate: Logs Engineering Becomes First-Class

This is the most important — and most overlooked — improvement.

CloudWatch now supports pipelines that allow you to transform and enrich logs during ingestion.

What you can do

Normalize log schemas
Add account, region, environment metadata
Remove noisy or unused fields
Prepare logs for faster queries

Why this is critical

Most log problems are not about volume — they’re about poor structure.

Fixing logs before they land:

Reduces query cost
Improves search performance
Enables consistent analysis across teams

AWS is effectively introducing Logs Engineering as a native CloudOps capability.

🔁 Curate Flow

Analyze: CloudWatch + S3 Tables (The Game Changer)

This is where CloudWatch stops being an ops-only service.

CloudWatch logs can now be materialized into S3 Tables, making them accessible to analytics and ML services.

Supported analysis tools

Amazon Athena
Amazon SageMaker
Amazon QuickSight

Why this is huge

Logs are no longer locked inside CloudWatch
One dataset can serve:
- CloudOps
- Security teams
- Data & analytics teams
No duplicate pipelines or exports

This bridges Cloud Operations and Data Analytics in a clean, AWS-native way.

🔁 Analyze Flow

Real CloudOps Use Cases

This isn’t theoretical — here’s where this actually helps:

Detect abnormal VPC traffic using Athena queries
Share the same logs across AppOps and SecOps
Reduce CloudWatch Logs Insights costs through early curation
Run ML models on historical operational data
Eliminate custom Firehose + Lambda pipelines

This is CloudOps becoming intentional and data-driven.

Example Flow: From VPC Flow Logs to Actionable Insights

You want to:

Collect VPC Flow Logs across all AWS accounts
Normalize and enrich the logs
Analyze traffic anomalies using Athena
Reuse the same data for Security and Ops teams

End-to-End Flow (High Level)

Step-by-Step Breakdown

Collect – Org-Level Log Ingestion

Enable VPC Flow Logs via CloudWatch enablement rules
Logs from all accounts and regions flow into CloudWatch automatically
No Firehose, no Lambda, no per-account setup

CloudOps win: centralized visibility

Curate – Normalize & Enrich Logs

CloudWatch Pipeline performs:

JSON normalization
Adds:

   account_id
   region
   environment

Removes unused fields (cost control)

CloudOps win: query-ready logs, lower cost

Persist – Materialize Logs into S3 Tables

Curated logs are written to S3 Tables
Acts as a long-term operational dataset
Same schema reused everywhere

CloudOps win: one dataset, many consumers

Analyze – Ops & Security Use the Same Data

CloudOps runs Athena queries:

Unusual traffic spikes
Cross-AZ traffic anomalies

SecOps runs:

Suspicious IP analysis
Lateral movement detection
QuickSight dashboards give leadership visibility

CloudOps win: no data duplication, no silos

Incident + RCA Flow

Before:

Logs lived in CloudWatch
Analytics lived elsewhere
Security built separate pipelines
Everyone duplicated effort

Now:

One ingestion
One curated dataset
Multiple use cases

This is CloudOps evolving from reactive troubleshooting to data-driven operations.

Final Thoughts

If you still see CloudWatch as “just a place for logs”, you’re missing the bigger picture.

CloudWatch is becoming:

An operational data platform
A shared foundation for CloudOps, SecOps, and Platform teams
A bridge between real-time monitoring and analytics

And this shift has only just begun.

If you’re building serious AWS platforms, now is the right time to rethink how you treat logs.

Running AEM Without Losing Your Mind: A Practical Local & AWS EC2 Setup Guide

Venkata Pavan Vishnu Rachapudi — Wed, 28 Jan 2026 15:35:14 +0000

I still remember the first time I tried setting up AEM locally — the JAR started, the logs kept scrolling, the fan noise increased, and for a good 10 minutes I wasn’t sure whether AEM was actually starting or silently failing.

If you’ve worked with AEM long enough, you know this feeling.

Adobe Experience Manager isn’t a tool you just install. It’s a platform — built on Java, OSGi, Sling, and a JCR-backed repository — and the learning curve usually starts the moment you try to run it on your machine.

In real projects, getting AEM running reliably (locally and on AWS) is more important than writing your first component. If your setup is unstable, everything else breaks — debugging, component development, deployments, and even confidence.

This guide is based on how I actually set up AEM in day-to-day work — starting locally, understanding what’s happening under the hood, and then moving the same setup to an AWS EC2 instance before thinking about production or AEM as a Cloud Service.

This blog walks you through:

Local AEM setup using Java JAR and Docker
Understanding run modes and debugging
Deploying AEM on AWS EC2
Core AEM consoles: CRXDE Lite, Package Manager, and OSGi System Console

What CRX Actually Is (And Why You’ll Keep Hearing About It)

One of the first things you’ll hear in AEM projects is “check it in CRX” or “look at the node structure”.

CRX stands for Content Repository eXtreme.

Think of CRX as the heart of AEM. Everything — pages, components, dialogs, permissions, configurations — ends up here in some form. Under the hood, modern AEM uses Apache Jackrabbit Oak, which is Adobe’s scalable implementation of the Java Content Repository (JCR) standard.

If you understand CRX at a basic level, debugging AEM becomes much easier. If you don’t, AEM often feels like a black box.

Running AEM Locally Using the Quickstart JAR

This is still the most straightforward way to run AEM — and honestly, the one I recommend when you’re learning or debugging something tricky.

Before You Start

Make sure you have:

Java 11 or 17 (depending on your AEM version)
At least 8 GB RAM on your machine
AEM SDK Quickstart JAR downloaded from Adobe

AEM is heavy. If your laptop struggles here, it will struggle everywhere.

Folder Setup (Keep It Simple)

I always keep author and publish separate. It avoids confusion later.

aem-author/
aem-publish/

Drop the same aem-sdk-quickstart.jar into both folders.

Starting the Author Instance

java -Xmx4g -jar aem-sdk-quickstart.jar -r author,local

The first startup is slow. Don’t panic. Grab coffee.

Once it’s done:

URL: http://localhost:4502
Login: admin / admin

Starting the Publish Instance

After the first run, AEM generates startup scripts under crx-quickstart/bin.

Edit the start script and change the port:

CQ_PORT=4503

Then run with:

java -Xmx4g -jar aem-sdk-quickstart.jar -r publish,local

This separation pays off later when you debug author vs publish issues.

Running AEM with Docker (When You Want Consistency)

Docker makes sense when:

Multiple developers need the same setup
You want to avoid “works on my machine” issues
You’re closer to cloud-style deployments

For pure learning, JAR is fine. For teams, Docker helps.

Basic Folder Layout

aem/
 ├── author/
 │   └── Dockerfile
 ├── publish/
 │   └── Dockerfile
 ├── aem-sdk-quickstart.jar
 └── license.properties

A Simple Author Dockerfile

Keep it readable. Avoid over-optimizing early.

FROM eclipse-temurin:11-jdk

# AEM directories
ENV AEM_HOME=/opt/aem
ENV AEM_RUNMODE=author

# Create AEM home
RUN mkdir -p ${AEM_HOME}
WORKDIR ${AEM_HOME}

# Copy AEM Quickstart and license
COPY aem-author-p4502.jar aem.jar
#COPY license.properties license.properties

# JVM tuning (safe for local testing)
ENV JAVA_OPTS="-Xms1024m -Xmx2048m -XX:+UseG1GC"

# Expose AEM + Debug ports
EXPOSE 4502 58242

# Persist important data
VOLUME [  "/opt/aem/crx-quickstart/repository",  "/opt/aem/crx-quickstart/logs", "/opt/aem/backup"]

# Start AEM Author
CMD java $JAVA_OPTS -jar aem.jar \
  -r ${AEM_RUNMODE} \
  -Dcrx.quickstart.server.port=4502 \
  -Dcrx.quickstart.nodename=author

Build and Run

docker build -t aem-author -f author/Dockerfile .
docker run -d -p 4502:4502 -p 5005:5005 aem-author

Repeat the same idea for Publish on port 4503.

Run Modes: Small Flags, Big Impact

Run modes decide how AEM behaves. Misconfigured run modes are a common reason for “it works locally but not elsewhere” problems.

Common Ones You’ll Actually Use

author – where editors work
publish – where content is served
local – your machine
dev – developer-only configs
nosamplecontent – clean setup

How I Usually Set Them

Java:

-Dsling.run.modes=author,local,dev

Docker:

-r author-local,docker

Avoid dots in Docker run modes — it causes subtle issues.

Verify What’s Active

http://localhost:4502/system/console/status-slingsettings

If run modes are wrong, stop and fix them early.

Debugging AEM (Yes, You Can Debug It Like Any Java App)

AEM debugging feels intimidating until you realize it’s just a Java process.

Enable Debug Port

-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:5005

Expose port 5005 if you’re using Docker.

Attach Your IDE

IntelliJ or VS Code
Host: localhost
Port: 5005

This is where AEM starts making sense — Sling Models, services, servlets, all debuggable.

Logs You’ll Check Daily

crx-quickstart/logs/error.log

If something breaks, this file almost always tells you why.

The Three AEM Consoles You’ll Live In

If you’re new to AEM, bookmark these URLs.

CRXDE Lite (`/crx/de`)

Used for:

Inspecting repository structure
Understanding how components are stored
Quick debugging

Rule of thumb: debug here, don’t build here.

Package Manager (`/crx/packmgr`)

This is how code and content move between environments.

Upload packages
Install builds
Deploy Maven outputs

In real projects, almost everything flows through Package Manager.

OSGi System Console (`/system/console`)

This is AEM’s engine room.

You’ll use it to:

Check bundles
Configure services
Troubleshoot weird issues

If AEM feels broken, this is the first place to look.

2. Package Manager (`/crx/packmgr`)

URL:

http://localhost:4502/crx/packmgr

Used for:

Uploading content and code packages
Installing component bundles
Deploying builds from Maven

Typical usage:

mvn clean install -PautoInstallPackage

3. OSGi System Console (`/system/console`)

URL:

http://localhost:4502/system/console

Critical for:

Managing OSGi bundles
Configuring services (/configMgr)
Viewing Sling mappings
Checking logs and components health

Common sub-paths:

/system/console/bundles
/system/console/configMgr
/system/console/components

Running AEM on AWS EC2

When you move AEM from your laptop to EC2, the goal isn’t to make things fancy — it’s to make them predictable.

This setup works without constant memory pressure:

Instance type: t3.medium
RAM: 8 GB
Storage: 30 GB gp3
AMI: Amazon Linux 2023

Anything smaller and AEM startup becomes painful.

Step 1: Create the EC2 Instance

Go to EC2 → Launch instance

Choose Amazon Linux AMI
Select instance type t3.medium
Configure storage → set root volume to 30 GB gp3
Attach an IAM role (explained below)

Configure Security Group:

4502 (Author) – restricted access
4503 (Publish) – restricted access
22 (SSH) – optional
80 / 443 – if needed

🔒 For real environments, never expose 4502/4503 publicly.

Step 2: Access EC2 Without SSH Pain (Recommended)

The cleanest approach is Session Manager.

Attach an IAM role with:

AmazonSSMManagedInstanceCore

This gives you:

Browser-based shell
No SSH keys
No port 22 open
For most use cases, this is enough.

Step 3: Getting AEM SDK onto EC2 (Two Ways)

This is where people usually get confused.

Option 1: SCP Using SSH Keys (Old but Works)

If you already created a key pair:

scp -i my-key.pem aem-sdk-quickstart.jar ec2-user@<EC2-PUBLIC-IP>:/home/ec2-user/

Downsides:

Requires managing SSH keys
Requires port 22 open
Doesn’t scale well

Option 2: Upload to S3 and Pull from EC2 (Best Practice)

This is the cleaner and more cloud-native approach.

Steps:

Upload AEM SDK JAR to a private S3 bucket
Attach an IAM role to EC2 with:
s3:GetObject permission on that bucket
From EC2 (via Session Manager):

aws s3 cp s3://my-aem-artifacts/aem-sdk-quickstart.jar /home/ec2-user/
Why this is better:

No SSH keys
No SCP
Fully auditable
Easy to automate later

This is the approach I recommend.

We can use same commands we used during our local step. For Docker kind of setup we need docker installed on the EC2 Instance

AEM Components Overview

AEM components live under:

/apps/<project>/components

Typical Component Structure

my-component/
 ├── .content.xml
 ├── _cq_dialog/
 │   └── .content.xml
 ├── my-component.html

Components are deployed as:

Maven-built OSGi bundles
Content packages via Package Manager

AEM Setup Pyramid

Below is how I personally visualize AEM setup and learning progression — from infrastructure to development and operations.

Practical AEM Flow (How I Recommend Working)

Final Words

If you understand:

How CRX (Content Repository eXtreme) works
Why Author ≠ Publish
How run modes control behavior
How /crx/de, /crx/packmgr, and /system/console fit together

👉 You’re already ahead of most beginners in AEM.

Master the fundamentals locally, automate everything with Maven, and only then think about scaling on AWS or Cloud Service.

Happy AEM engineering 🚀

Getting Started with AEM: On-Prem vs AEM Cloud (In Simple Terms)

Venkata Pavan Vishnu Rachapudi — Sat, 17 Jan 2026 12:16:56 +0000

If you’ve ever worked in large enterprises, you’ve probably heard people say:

“Our website runs on AEM.”

But what exactly is AEM?
And what’s the difference between AEM On-Prem and AEM as a Cloud Service?

Let’s break it down — no heavy jargon, just how things actually work.

So, What is AEM?

Adobe Experience Manager (AEM) is a platform that helps companies:

Build websites
Manage content
Create forms
Store and reuse digital assets
Deliver consistent experiences across channels

Think of AEM as:

A powerful content engine that sits between business users and developers.

Where Do Companies Use AEM?

AEM is usually chosen when:

Websites are large and complex
Multiple teams update content
Performance and security really matter
Content needs to be reused across brands or regions

You’ll commonly see AEM in:

Banking & Finance
Retail
Healthcare
Media companies
Government portals

AEM On-Prem vs AEM Cloud – Let’s Talk Reality

AEM On-Prem (Traditional Way)

With On-Prem, you own almost everything:

Servers
Scaling
Patching
Upgrades
Availability

It gives control, but also responsibility.

AEM Cloud (Modern Way)

With AEM as a Cloud Service:

Adobe manages infrastructure
Scaling happens automatically
Updates are continuous
CI/CD is built in

You focus on content and code, not servers.

High-Level Comparison (Quick View)

Core AEM Building Blocks (Common Everywhere)

No matter where AEM runs, the core ideas stay the same.

AEM Sites – Where Pages Are Built

AEM Sites is what marketing teams live in.

It allows:

Drag-and-drop components
Editable templates
Multi-language support
Multi-site management

In simple terms:

Developers build components.
Authors assemble pages.

AEM Forms – When Data Matters

AEM Forms is used when you need more than just content.

Typical examples:

Bank application forms
Insurance claims
Government submissions

It supports:

Adaptive forms
Validation
Workflows
Secure data handling

AEM Content & Assets – One Central Content Hub

AEM isn’t just pages.
It’s also about content reuse.

With AEM Assets (DAM):

Images, videos, PDFs live in one place
Metadata & tagging help discovery
Assets can be reused across sites

Apache Sling – How URLs Talk to Content

This is where AEM gets interesting.

Apache Sling maps URLs directly to content stored in AEM.

Instead of thinking:

URL → Controller → View

AEM thinks:

URL → Content → Script

Jackrabbit JCR – The Content Brain

Behind the scenes, AEM stores everything in a JCR (Java Content Repository).

What goes into JCR?

Pages
Components
Templates
Configurations
User permissions

It’s not a traditional database.

Think of it as:

A tree-structured content store optimized for content, not tables.

    Root --> Content --> Site --> Page --> Component

Apache Felix – Why AEM Is Modular

AEM runs on Apache Felix (OSGi).

This means:

Everything is a bundle
Services can be updated independently
No full server restart needed

Developers love this because:

You deploy features, not monoliths.

On-Prem vs Cloud – Operational View

So… Which One Should You Choose?

Choose AEM On-Prem if:
- You need full infra control
- You have legacy dependencies
- Compliance restricts cloud usage
Choose AEM Cloud if:
- You want faster releases
- You prefer less operational work
- You’re building modern digital experiences

Final Thoughts

AEM is not just a CMS.

It’s a content platform powered by:

Apache Sling
JCR
OSGi
Enterprise workflows

And while On-Prem still exists, AEM Cloud is clearly the future.

🩺 How I Troubleshoot an EC2 Instance in the Real World (Using Instance Diagnostics)

Venkata Pavan Vishnu Rachapudi — Mon, 12 Jan 2026 16:58:10 +0000

When an EC2 instance starts misbehaving, my first reaction is not to SSH into it or reboot it. Instead, I open the EC2 console and go straight to Instance Diagnostics.

Over time, I’ve realized that most EC2 issues can be understood — and often solved — just by carefully reading what AWS already shows on this page.

In this blog, I’ll explain how I use each section of Instance Diagnostics to troubleshoot EC2 issues in a practical, real-world way.

The First Question I Answer

Before touching anything, I ask myself one simple question:

Is this an AWS infrastructure issue, or is it something inside my instance?

Instance Diagnostics helps answer this in seconds.

Status Overview: Always the Starting Point

I always begin with the Status Overview at the top.

Instance State

This confirms whether the instance is running, stopped, or terminated.

If it is not running, there is usually nothing to troubleshoot.

System Status Check

This reflects the health of the underlying AWS infrastructure such as the physical host and networking.

If this check fails, the issue is on the AWS side. In most cases, stopping and starting the instance resolves it by moving the instance to a healthy host.

Instance Status Check

This check represents the health of the operating system and internal networking.

If this fails, the problem is inside the instance — typically related to OS boot issues, kernel problems, firewall rules, or resource exhaustion.

EBS Status Check

This confirms the health of the attached EBS volumes.

If this fails, disk or storage-level issues are likely, and data protection becomes the immediate priority.

CloudTrail Events: Tracking Configuration Changes

If an issue appears suddenly, the CloudTrail Events tab is where I go next.

I use it to confirm:

Whether the instance was stopped, started, or rebooted
If security groups or network settings were modified
Whether IAM roles or instance profiles were changed
If volumes were attached or detached

This helps quickly identify human or automation-driven changes.

SSM Command History: Understanding What Ran on the Instance

The SSM Command History tab shows all Systems Manager Run Commands executed on the instance.

This is especially useful for identifying:

Patch jobs
Maintenance scripts
Automated remediations
Configuration changes

If there are no recent commands, that information itself is useful because it confirms that no SSM-driven actions caused the issue.

Reachability Analyzer: When the Issue Is Network-Related

If the instance is running but not reachable, I open the Reachability Analyzer directly from Instance Diagnostics.

This is my go-to tool for diagnosing:

Security group issues
Network ACL misconfigurations
Route table problems
Internet gateway or NAT gateway connectivity
VPC-to-VPC or on-prem connectivity issues

Instead of guessing, Reachability Analyzer visually shows exactly where the network path is blocked.

Instance Events: Checking AWS-Initiated Actions

The Instance Events tab tells me if AWS has scheduled or performed any actions on the instance.

This includes:

Scheduled maintenance
Host retirement
Instance reboot notifications

If an issue aligns with one of these events, the root cause becomes immediately clear.

Instance Screenshot: When the OS Is Stuck

If I cannot connect to the instance at all, I check the Instance Screenshot.

This is especially helpful for:

Identifying boot failures
Detecting kernel panic messages
Seeing whether the OS is stuck during startup

Even a single screenshot can explain hours of troubleshooting.

System Log: Understanding Boot and Kernel Issues

The System Log provides low-level OS and kernel messages.

I rely on it when:

The instance fails to boot properly
Services fail during startup
Kernel or file system errors are suspected

This is one of the best tools for diagnosing OS-level failures without logging in.

[[0;32m  OK  [0m] Reached target [0;1;39mTimer Units[0m.
[[0;32m  OK  [0m] Started [0;1;39mUser Login Management[0m.
[[0;32m  OK  [0m] Started [0;1;39mUnattended Upgrades Shutdown[0m.
[[0;32m  OK  [0m] Started [0;1;39mHostname Service[0m.
         Starting [0;1;39mAuthorization Manager[0m...
[[0;32m  OK  [0m] Started [0;1;39mAuthorization Manager[0m.
[[0;32m  OK  [0m] Started [0;1;39mThe PHP 8.2 FastCGI Process Manager[0m.
[[0;32m  OK  [0m] Finished [0;1;39mEC2 Instance Connect Host Key Harvesting[0m.
         Starting [0;1;39mOpenBSD Secure Shell server[0m...
[[0;32m  OK  [0m] Started [0;1;39mOpenBSD Secure Shell server[0m.
[[0;32m  OK  [0m] Started [0;1;39mDispatcher daemon for systemd-networkd[0m.
[[0;1;31mFAILED[0m] Failed to start [0;1;39mPostfix Ma… Transport Agent (instance -)[0m.
See 'systemctl status postfix@-.service' for details.
[[0;32m  OK  [0m] Started [0;1;39mLSB: AWS CodeDeploy Host Agent[0m.
[[0;32m  OK  [0m] Started [0;1;39mVarnish HTTP accelerator log daemon[0m.
[[0;32m  OK  [0m] Started [0;1;39mSnap Daemon[0m.
         Starting [0;1;39mTime & Date Service[0m...
[   13.865473] cloud-init[1136]: Cloud-init v. 25.1.4-0ubuntu0~22.04.1 running 'modules:config' at Fri, 05 Dec 2025 01:25:29 +0000. Up 13.71 seconds.

Ubuntu 22.04.3 LTS ip-***** ttyS0

ip-****** login: [   15.070290] cloud-init[1152]: Cloud-init v. 25.1.4-0ubuntu0~22.04.1 running 'modules:final' at Fri, 05 Dec 2025 01:25:30 +0000. Up 14.98 seconds.
2025/12/05 01:25:30Z: Amazon SSM Agent v3.3.2299.0 is running
2025/12/05 01:25:30Z: OsProductName: Ubuntu
2025/12/05 01:25:30Z: OsVersion: 22.04
[   15.189197] cloud-init[1152]: Cloud-init v. 25.1.4-0ubuntu0~22.04.1 finished at Fri, 05 Dec 2025 01:25:30 +0000. Datasource DataSourceEc2Local.  Up 15.16 seconds
2025/12/15 21:35:50Z: Amazon SSM Agent v3.3.3050.0 is running
2025/12/15 21:35:50Z: OsProductName: Ubuntu
2025/12/15 21:35:50Z: OsVersion: 22.04
[1091674.876805] Out of memory: Killed process 465 (java) total-vm:11360104kB, anon-rss:1200164kB, file-rss:3072kB, shmem-rss:0kB, UID:1004 pgtables:2760kB oom_score_adj:0
[1091770.835233] Out of memory: Killed process 349683 (php) total-vm:563380kB, anon-rss:430132kB, file-rss:4096kB, shmem-rss:0kB, UID:0 pgtables:1068kB oom_score_adj:0
[1092018.639252] Out of memory: Killed process 347300 (php-fpm8.2) total-vm:531624kB, anon-rss:193648kB, file-rss:3456kB, shmem-rss:106240kB, UID:33 pgtables:888kB oom_score_adj:0

Session Manager: Secure Access Without SSH

If Systems Manager is enabled, I prefer using Session Manager to access the instance.

This allows me to:

Inspect CPU, memory, and disk usage
Restart services safely
Avoid opening SSH ports or managing key pairs

From both a security and operational standpoint, this is my preferred access method.

What Experience Has Taught Me

Troubleshooting EC2 instances is not about reacting quickly — it is about observing carefully.

Instance Diagnostics already provides:

Health signals
Change history
Network analysis
OS-level visibility

When used correctly, these tools eliminate guesswork and reduce downtime.

Final Thoughts

My approach to EC2 troubleshooting is simple:

Start with Instance Diagnostics.

Understand the signals.

Act only after the root cause is clear.

In most cases, the answer is already visible — we just need to slow down and read it.

☁️ What If I Move to the Cloud? Part 1 – What Is This Cloud, Really?

Venkata Pavan Vishnu Rachapudi — Sat, 10 Jan 2026 15:28:00 +0000

Hello friends! 🙏 Welcome to the first post in my series: “What If I Move to the Cloud?”

So, your manager comes and says: “We need to move everything to the cloud this year.” And you’re sitting there like Bahubali, sword in hand ⚔️, thinking: “But… where is this cloud? Who am I fighting?” 😅

Don’t worry yaar, I’ll explain. Let’s make it simple, funny, and a little cinematic. 🎬

🌥️ So… What Exactly Is the Cloud?

First of all, cloud is not some floating thing above the sky ☁️. It’s not going to rain servers on your head. 😄

The cloud is basically computing resources that live somewhere else, which you can use on demand. Someone else manages them, you just use them. Like your friend who always brings vada pav to your party—you enjoy, he does the work! 🍔

Think of it like this:

Before cloud: You have your own little shop 🏠—servers, storage, network. You handle everything yourself: buying hardware, installing, patching, keeping it running 24/7.
After cloud: You rent a shop 🏢 that is fully managed. You bring your ingredients (apps, data), cook, serve, enjoy. The landlord (cloud provider) handles electricity, plumbing, security, cleaning—even AC! ❄️

💡 Before vs After Cloud (Infographic)

Some generic examples:

Scenario	Before Cloud	After Cloud
Email	Host your own email server 🖥️, patch it, handle spam & downtime	Use Gmail or Outlook 365 📧, scale storage automatically
Website	Deploy on office server 💻, upgrade RAM manually, crash on traffic spikes	Deploy on cloud 🌐, auto-scale during peaks like IPL or movie release day 🚀
Storage	USB drives, NAS, tapes for backups 💾, manage RAID & power	Upload to S3 or Drive ☁️, access anywhere, versioning
Data Analysis	Run Excel on desktop 📊, slow, memory-limited	Use Databricks / Snowflake 🧮, big datasets, fast queries

🍫 Cloud is Like Chocolate (With Flavors!)

Now, friends, cloud is chocolate 🍫

All clouds do the same basic thing: compute, storage, networking, scaling
But they have different flavors:
- AWS → Milk chocolate 🥛
- Azure → Dark chocolate 🌑
- GCP → Hazelnut chocolate 🌰

Different taste, same sweet satisfaction.

Example: Load balancing

AWS → Elastic Load Balancer
Azure → Azure Load Balancer
GCP → Cloud Load Balancing

Different setup, same idea: scale servers automatically when traffic spikes.

🤩 Why Move to the Cloud?

Cloud is sweet, let me tell you why:

💰 Pay-As-You-Go

Only pay for what you use. Like buying paav bhaji only for hunger instead of hoarding 10 packets 🥘.

Example: Netflix 💻 doesn’t run huge servers 24/7. During off-peak, servers chill. During IPL or weekend binge-time, servers go full Bahubali mode ⚔️. Only pay for what you consume.

📈 Scale on Demand

Traffic spikes happen. Lunch rush at Swiggy 🍔, dinner rush at Zomato 🍕, or PK suddenly going viral in 200 countries 🌎.

Cloud scales automatically—more compute when you need it, less when traffic calms.

⚡ Faster Experimentation

Cloud is like PK exploring Earth 🤯. Try new things, test, fail, retry—no hardware worries.

Example: Adobe Creative Cloud ✨ launches new AI features quickly, tests globally, rolls back if something breaks.

🛠️ Less Operational Headache

No babysitting servers, no patching, no power cuts. Focus on apps, features, customer delight.

Example: Netflix doesn’t hire people to watch servers like Baahubali guarding the fortress. They focus on streaming and original content.

🌍 Global Reach

Serve users anywhere, anytime. Zomato delivers in Delhi, Dubai, and maybe Dwaraka too 😉. Adobe serves creatives worldwide without latency nightmares.

⚠️ The Dark Side of Cloud 🍫⚠️

Not everything is sweet chocolate. Some bites are bitter:

💸 Cost surprises: Startups run hundreds of VMs for testing, bill shocks later
📜 Data rules: Some data can’t leave the country, compliance matters
⚙️ Legacy headaches: Old monolith apps may crash or lag if lifted blindly
⛓️ Vendor lock-in: Too cozy with one cloud makes future switching painful

🌐 Hybrid Cloud – Sweet & Bitter Balance

Because of these challenges, hybrid cloud emerged:

Sensitive workloads stay on-prem 🏢
Scalable, bursty workloads move to cloud ☁️

Example: Banks keep core transactions on-prem 💳 but fraud detection AI runs in cloud ☁️.

Hybrid cloud = milk chocolate with a dark chocolate filling 🍫—sweet, but keeps bitter controlled.

✅ Key Takeaways:

Cloud = Pay for what you use, scale automatically, experiment fast, focus on apps, reach globally
But beware: cost surprises, data rules, legacy apps, vendor lock-in
Hybrid cloud = compromise solution, balance sweet & bitter

Next in the series: Total Cost of Ownership (TCO)—how to calculate if cloud saves money or just creates bills 💸

How I Became an AWS Community Builder (Security) – My Real Journey + Application Guide

Venkata Pavan Vishnu Rachapudi — Thu, 25 Dec 2025 18:08:16 +0000

Hey folks! 👋

If you've ever wanted to level up your AWS game, meet amazing people, and get $500 AWS credits + free cert vouchers, then the AWS Community Builders program is calling your name.

I joined last year in Security and these 11 months have been 🔥. Here's my real story + exact steps to apply.

What Even is AWS Community Builders? 🤔

It's for passionate AWS users who share knowledge – bloggers, speakers, creators like us.

You get:

Mentorship from AWS pros
Exclusive resources
Global networking
Real perks (more on that later)

Choose where you've actually contributed!

My Pre-Community Builder Grind 💪

I wrote simple, practical blogs (not complex architectures):

✅ GuardDuty + Inspector with EC2/ECR
✅ Secure EC2 access (NO port 22!)
- EC2 Instance Connect Prefix Lists
- Bastion Hosts
- Systems Manager (w/ session logs)
✅ Nginx/Tomcat on EC2 (Console/SDK/CLI/CF IAAC)

Pro tip: Beginners love these. Show 4 deployment ways + security basics = instant value.

Also crushed AWS Amplify in 30 Days Hackathon by AWS User Group India 🏆

Community Builder Life Changed Everything 🚀

Spoke at 3 events

Met legends (can't name-drop, but WOW)
Deep dived Security + AI
Got real feedback that leveled me up

The people? Pure gold. That's the real magic.

The Perks (Swag Lovers Rejoice! 🎁)

💰 $500 AWS Credits – POCs galore!
📜 100% Free Cert Voucher
📦 Swag (random blog rewards – I'm obsessed)

🎓 *Exclusive QA Cloud Acadmey Education Platform Access *

How to Actually Get In (Step-by-Step) 📋

1. Build Your Portfolio (8-10 quality pieces)

✅ Original blogs (your category)
✅ Attend Events of AWS User Groups and Contribute to it

✅ Talks/videos/social
✅ NO plagiarism – be real

2. Application Process

📅 Opens mid-January (global)
🔗 Join waitlist NOW: https://pulse.aws/application/BM2AKLSX?p=0
📎 Submit links + your passion story

3. My Tips (That Actually Work)

✅ Start NOW – consistency wins
✅ Pick YOUR niche (not trends)
✅ Engage – attend events, comment, collab
✅ Not selected? Reapply! (2nd/3rd time common)
✅ You don't need "expert" – just eager to learn/help

Resources to Crush It Today 🌐

The Real Goal 🎯

Contribute to AWS ecosystem. Builder or not, keep sharing. That's what grows you + helps others .

Mid-January apps opening soon – start your portfolio TODAY!

You in? Drop a 🔥 if you're applying!

Connect with me, share your AWS journey, let's grow together 🚀

From Panelist & Mentor to Speaker to AWS Certified – A Defining Week in My AWS Journey

Venkata Pavan Vishnu Rachapudi — Thu, 25 Dec 2025 06:45:22 +0000

Some weeks don’t just fill up your calendar — they change your direction.

For me, December 18th to 23rd was exactly that kind of week: three different roles, one common thread — helping people really understand how cloud and AI fit together in the real world.

🎯 One week, three hats

In six days, I got to wear three hats:

Panelist & mentor at an AWS Student Community Day in Hyderabad.
Speaker at AWS Community Day Kochi (AI/ML Edition).
Newly certified AWS Generative AI Developer – Professional.

Individually, each one is special.

Together, they felt like a mini “sprint” in my AWS journey — community, practice, and validation all reinforcing each other.

🎓 Dec 18 – Panelist & mentor at AWS Student Community Day (MLRIT, Hyderabad)

The week kicked off at MLRIT in Hyderabad with AWS Student Community Day, where I joined as a panelist and mentor.
Walking into a hall full of students always reminds me of my own early days — lots of curiosity, a bit of anxiety, and a ton of questions that don’t always get asked out loud.

Real talk on careers, not buzzwords

On the panel, we kept the conversation honest and practical:

What does a realistic cloud + AI career path look like for students today?
How do you move from “I passed a cert” to “I can actually solve problems”?
What do hiring teams expect from freshers beyond a list of technologies?

Instead of throwing jargon, we shared stories — projects that broke, lessons from production, and how community involvement can shortcut years of trial-and-error.

Hands-on: building instead of just listening

After the panel, I switched into mentor mode for a hands-on lab.
The goal was simple: ship something end-to-end, not just click around a console.

We worked through:

Evolution of Coding and Kiro Features
Vibe coding with Kiro.dev to quickly get from idea to working UI.
Deploying with AWS App Runner so students could see their app live, not just on localhost.
Thinking about scalability, availability, and security as part of the design, not as an afterthought.

By the end, the best feedback wasn’t “nice session” — it was “this finally makes sense now.”

That shift from “cloud feels abstract” to “oh, I can actually build this” is exactly why these workshops matter.

🎤 Dec 20 – Speaker at AWS Community Day Kochi (AI/ML Edition)

Two days later, the vibe changed completely: from campus energy to community conference energy at AWS Community Day Kochi.
This time I was on stage, talking about something that’s very close to what I work on day to day: Agentic AI and how enterprises are starting to adopt it.

From prompts to Agentic AI

The session was built around three ideas:

Where Amazon QuickSuite and AWS Transformfit in
- Amazon QuickSuite as a day-to-day AI companion for research, chat, automation, and flows — almost like a teammate that understands your systems.
- AWS Transform as the heavy-duty engine for modernization: from VMware and mainframes to .NET migration, powered by Agentic AI.
Real patterns, not just slides

We walked through patterns like automating content workflows, migration of boto2 SDK to Boto3 SDK using Transform instead of “cool demo only.”

What stood out to me was the Q&A afterwards — people weren’t asking “What is Agentic AI?” anymore; they were asking “How do I plug this into my environment?”

That’s when you know the conversation has moved from hype to actual adoption.

📘 Dec 23 – AWS Certified Generative AI Developer – Professional

The week wrapped up on a personal high: earning the Beta AWS Certified Generative AI Developer – Professional certification.

This exam goes well beyond “call an API and get a response.”

It tests whether you can design secure, scalable GenAI systems that live comfortably inside real-world AWS architectures.

Some of the deeper areas it touches:

Amazon Bedrock architecture and security — not just “what is it,” but how should you use it.
Designing agent-based, multi-step workflows that coordinate tools, APIs, and services.
Using Lambda, API Gateway, and Step Functions to glue GenAI components into full pipelines.

While answering questions, there were multiple moments of “wait, I literally spoke about this on stage two days ago.” and "heard about from fellow speaker "
That overlap between community work and exam content made the certification feel less like a separate goal and more like a checkpoint on the same path.

🔁 What this week taught me

Looking back, going from panelist & mentor → speaker → certified professional in a single week was intense, but it reinforced a few beliefs that guide how I want to continue showing up in the AWS community.

Teaching sharpens understanding

Every time you explain something, you find edge cases and blind spots you hadn’t noticed before. Students and community members ask the questions documentation doesn’t.
Community is a multiplier

Panels, meetups, and community days compress learning. You don’t just learn from talks — you learn from hallway conversations, random questions, and even “we tried this and it failed” stories.
Certifications hit different with real context

When you’ve built, broken, and fixed real systems, an exam doesn’t feel like memorization. It feels like someone asking, “Okay, show me how you’d do this in the real world.”

Most of all, this week reminded me that giving back and growing personally are not separate tracks.

The more you mentor, speak, and share, the deeper your own understanding becomes.

🙏 Thank you — and what’s next

None of this happened in isolation.

Huge thanks to:

AWS Student Community & AWS Cloud Clubs at MLRIT for creating a space where students can experiment, break things, and learn by doing.
The AWS Community Day Kochi organizers and volunteers for building a stage where practitioners can talk about what’s actually happening with AI/ML on AWS.
SUDO Consultants for backing community work and giving me the room to build, experiment, and share.
Every student and attendee who showed up, asked tough questions, and shared honest feedback — you made the week memorable.

From here, the plan is simple: keep building, keep teaching, and keep pushing deeper into Agentic AI and cloud automation.

If you’re on a similar path — maybe just getting started with AWS, or trying to move from “I know the services” to “I can design systems” — consider this an open invite: join a community, share what you learn, and let your journey be shaped by contribution as much as personal milestones.

AWS App Runner vs ECS Express Mode: Git, ECR, Scaling, and Security Explained

Venkata Pavan Vishnu Rachapudi — Wed, 24 Dec 2025 15:13:28 +0000

Introduction

AWS provides modern ways to run containerized applications without managing servers. Two popular options are AWS App Runner and Amazon ECS Express Mode. Both simplify container deployments, but they target different levels of control and use cases.

This blog compares these services and provides guidance on which to use for different workloads, based on AWS documentation.

Service Overview

AWS App Runner

App Runner is a fully managed service for running web apps and APIs:

Git Integration: Connect GitHub, GitLab, or Bitbucket directly to deploy applications.
Container Registry Support: Deploy pre-built container images from Amazon ECR (public or private) or Docker Hub.
Auto-scaling: Concurrency-based scaling; configure min/max instances and max requests per instance.
Security: Built-in HTTPS, AWS-managed TLS certificates, and WAF support.
Logging & Monitoring: CloudWatch logs and metrics out-of-the-box.
Public/Private Access: Default public endpoint; can connect to VPC for private resources.
Use Case: Stateless web apps, public APIs, rapid deployment with minimal operational overhead.

Amazon ECS Express Mode

ECS Express Mode is a simplified ECS deployment option:

ECS Power: Runs on ECS + Fargate without manual cluster management.
Networking & Security: Full VPC, IAM roles, subnets, security groups.
Scaling: CPU, memory, or custom metric-based auto scaling.
Workloads: Supports sidecars, background jobs, and complex internal services.
CI/CD: Requires building container images and pushing to ECR or another registry.
Use Case: Enterprise workloads, private/internal services, and production applications needing full control.

Feature Comparison Table

Feature	App Runner	ECS Express Mode
Git Integration	✅ Yes	❌ No
Container Registry	✅ ECR	✅ ECR
Auto Scaling	✅ Concurrency-based	✅ CPU/memory/custom metrics
WAF Support	✅ Yes	✅ via ALB
HTTPS	✅ Built-in	✅ ALB + ACM
Public Endpoint	✅ Yes	✅ Yes
Private Networking	⚠️ Limited (VPC connector)	✅ Full
Logging & Metrics	✅ CloudWatch	✅ CloudWatch
Background Workers / Sidecars	❌	✅ Yes

Go-To Scenarios

App Runner:
- Fast prototyping
- Public-facing web apps or APIs
- Minimal infra management
- Deploy from Git or ECR
ECS Express Mode:
- Enterprise workloads
- Private/internal services
- Metric-driven auto scaling
- Complex container architectures
- Deploy from container registry only

Expert Tip: Start with App Runner for MVPs or demos. Move to ECS Express for production workloads requiring security, VPC, and custom scaling.

Conclusion

AWS App Runner provides application-level, concurrency-based auto scaling with built-in Git/ECR integration, WAF, HTTPS, and logging, ideal for quick deployments.

ECS Express Mode provides infrastructure-level control, advanced networking, and flexible scaling, making it suitable for enterprise-grade workloads.

Decision: Use App Runner for speed and simplicity, ECS Express Mode for control and production readiness.