Private corporate batches delivered onsite across Bangalore, or live online in IST (UTC+5:30) — taught by a practitioner who runs AWS in production.
20 years across DevOps, SRE and Security · 10,000+ engineers trained · Trained teams at JPMorgan Chase, Verizon, Nokia and the World Bank
Principal DevOps Engineer & Architect
Rajesh teaches AWS as an operating model rather than a service tour: account structure and organisational units, service control policies and permission boundaries, VPC topology including endpoints and Transit Gateway, region and Availability Zone choices driven by resilience and residency, and cost engineering with tagging, Savings Plans, storage classes and rightsizing. Everything is built live in a real account through the console, the CLI and Terraform, including the failure paths — a denied API call traced back through policy evaluation, a subnet with no route out, and a bill that grew because nobody owned a tag.
Twenty years across DevOps, SRE and Security, in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe and others. He has trained engineers at JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus — more than 10,000 people personally. He teaches what he runs, not what he reads.
You are booked with a named engineer, and that is who turns up. Marketplaces and larger providers rotate whoever is free, so the person who sold you the agenda is rarely the person teaching it.
The same trainer is available for the next engagement, which matters when a team builds on what it learned last time.
Your batch is assigned a named trainer before it starts, and that is who teaches it. See the full faculty.
Engagements are matched on the tool, not the calendar. For AWS that means a trainer who has run it in production — AWS for Bangalore engineering teams — working inside inherited guardrails, non-production cost, cross-region operations and accelerated capacity — rather than whoever is free that week. You are told who is teaching before you commit, and that person is on the discovery call that shapes the agenda.
Where a batch is large enough to need a second trainer, the pairing is declared up front. The lead trainer stays accountable for the syllabus and the assessment either way.
Principal DevOps Engineer & Architect
Twenty years across DevOps, SRE and Security in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe, IBM/Emptoris, Ness, MindTree and Accenture. He has trained more than 10,000 engineers personally, at organisations including JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus. He teaches what he runs, not what he reads.
Teams of 8–30
Custom agenda, your timezone, onsite or online, NDA-friendly.
Request a quoteIndividual engineers
A private instructor and a curriculum built around your goal.
₹99,999Individuals who want peers
Scheduled batch, max 8 to 10 hours of live instruction.
₹34,999A private batch starts with a discovery call. We look at the stack you actually run — the CI system, the cloud, the constraints — and map the agenda onto it, so examples use your topology rather than a generic one.
Delivery is onsite at your own office or live online. Onsite AWS sessions in Bangalore most often land along the Outer Ring Road between Bellandur and Marathahalli, in Whitefield, at Manyata Tech Park or in Electronic City, and we run one site per day because a mid-day crossing of the city costs an hour of lab time. You provide the room, a screen and outbound internet; attendees use their own accounts, so we confirm in advance whether managed corporate laptops permit console and command-line access, because an inspecting proxy is the single most common cause of a slow first morning in this city. Where your production estate sits outside India we mirror that region in the labs so latency, quota behaviour and observability look like the real thing rather than like a demo; where an exercise needs accelerated capacity we raise the quota request days beforehand, since those limits are rarely granted on the morning. Sessions are scheduled in IST (UTC+5:30) and shaped around your release calendar and change-freeze windows, with a 09:30 start that leaves the evening handover to counterpart teams intact. Invoicing is in INR from our Indian entity with GST, against a purchase order where procurement requires one; attendee usage during labs stays on their own account and every exercise finishes with a teardown step.
Every attendee leaves with recordings, slides, lab repositories and a completion certificate. You receive an attendance and assessment report. Invoicing supports PO and GST.
Talk to us about a private AWS batchAWS is a cloud platform, but the useful way to learn it is as a system of accounts and boundaries rather than a catalogue of services. An AWS account is the hard isolation unit: it is where quotas apply, where billing lands, and where a mistake stops. Organizations groups accounts into organisational units, service control policies set the outer limit of what any principal inside them may do, and identity federation decides who arrives in the first place. Almost every serious design decision on AWS is really a decision about which account something belongs in.
Inside an account, three planes matter. Identity — roles, policies, trust relationships, permission boundaries and the difference between what a policy allows and what a session actually gets. Network — VPC subnets, route tables, security groups and network ACLs, NAT and internet gateways, VPC endpoints that keep traffic off the public internet, and the peering or Transit Gateway topology between accounts. And placement — regions and Availability Zones, which determine what survives a failure, and which are also the answer to data-residency questions that Indian financial and healthcare workloads have to satisfy.
The service catalogue then composes on top: EC2 with launch templates and Auto Scaling, S3 with lifecycle and storage classes, RDS, Aurora and DynamoDB, Lambda, SQS, SNS, EventBridge and Step Functions, ECS, Fargate and EKS, and CloudWatch, CloudTrail and Config for evidence of what happened. Teams that run AWS well express all of it as code in CloudFormation or Terraform, tag it so cost can be attributed, and treat the bill as a monitored signal rather than a monthly surprise.
Cloud skill has split into two markets, and they now pay differently. One is building on AWS — knowing which service to use, wiring an application together and getting it running. The other is operating AWS responsibly at organisational scale, and that is where the shortage is.
Three pressures created it. Security expectations rose: an over-permissive role or an open bucket is now a board-level incident rather than a ticket, and permission boundaries, cross-account roles and least-privilege design have become baseline expectations rather than advanced topics. Regulation caught up: workloads handling Indian payment, health or personal data have residency and audit requirements that force explicit region and account choices, so architecture is now partly a compliance exercise. And the money stopped being invisible: after several years of tighter funding and closer scrutiny of GCC budgets, engineering teams are measured on unit cost, which puts Savings Plans, Graviton, storage class transitions, rightsizing and idle-resource cleanup on engineers' backlogs instead of finance's.
The result is that AWS hiring has moved past certification vocabulary. What gets tested in interviews and reviews is whether you can explain blast radius, identity and cost for a design you actually built.
The structure everything else sits inside. Why the account is the real isolation boundary, how Organizations and organisational units group them, what service control policies can and cannot do, and how federated access replaces long-lived credentials.
Topics: The account as blast radius, quota and billing boundary · Organizations, organisational units and account vending · Service control policies and evaluation order · Identity federation, SSO and role assumption · Shared responsibility in practice · Working inside guardrails you did not write
Policy evaluation from first principles — identity policies, resource policies, permission boundaries, session policies and how a deny wins. Then the patterns teams need daily: cross-account roles, instance profiles, service-linked roles and short-lived credentials.
Topics: Policy evaluation logic and the order of decisions · Identity versus resource policies, and where trust lives · Cross-account role assumption and external IDs · Permission boundaries and delegated administration · Instance profiles, service roles and OIDC federation for CI · Access Analyzer, CloudTrail and finding what a role really used
What can reach what, and how traffic actually leaves. Subnet tiers across Availability Zones, route tables, security groups versus network ACLs, NAT and internet gateways, VPC endpoints, and connecting accounts with peering or Transit Gateway.
Topics: CIDR planning and subnet tiers across Availability Zones · Route tables, internet gateway and NAT gateway costs · Security groups, network ACLs and stateful versus stateless · Gateway and interface VPC endpoints, and PrivateLink · Peering, Transit Gateway and hybrid connectivity · Load balancers: ALB, NLB and target group behaviour
Choosing and running compute honestly. EC2 instance families, launch templates, Auto Scaling and Spot; containers on ECS with Fargate and on EKS; and Lambda for event-driven work — with the cold start, concurrency and timeout realities that decide whether it fits.
Topics: Instance families, Graviton and purchase options · Launch templates, Auto Scaling groups and health checks · Spot capacity and interruption handling · ECS, Fargate and task definitions · EKS and what AWS manages versus what you do · Lambda: concurrency, cold starts, timeouts and event sources
Matching a service to an access pattern instead of a habit. S3 storage classes and lifecycle, EBS volume types and snapshots, EFS; then RDS and Aurora versus DynamoDB, with backup, encryption, replicas and the residency questions Indian regulated workloads have to answer.
Topics: S3 storage classes, lifecycle rules and versioning · Bucket policies, block public access and encryption with KMS · EBS volume types, IOPS and snapshot strategy · RDS and Aurora: multi-AZ, read replicas, parameter groups and backup · DynamoDB: partition keys, capacity modes and access patterns · Cross-region replication, residency and what it costs
Knowing what happened and proving it. CloudWatch metrics, logs, alarms and dashboards; CloudTrail for API history; Config for resource state and drift; then designing for Availability Zone failure and a regional recovery objective you can actually meet.
Topics: CloudWatch metrics, custom metrics, logs and log insights · Alarms, composite alarms and useful thresholds · CloudTrail for API history and investigation · AWS Config rules, drift and compliance evidence · Backup, restore and recovery objectives · Multi-AZ resilience and what a second region really buys
Making the account reproducible. CloudFormation stacks, change sets and drift; Terraform with remote state and locking; then the pipeline that applies it, with identity from OIDC rather than stored keys, and environments promoted rather than hand-built.
Topics: CloudFormation templates, stacks, change sets and StackSets · Terraform providers, state, locking and workspaces · Choosing between CloudFormation, CDK and Terraform honestly · Pipelines with CodePipeline, GitHub Actions or Jenkins · OIDC federation so CI holds no static credentials · Environment promotion and reviewing an infrastructure diff
The module most courses skip and most teams now need. Where the bill comes from, tagging that supports attribution, Cost Explorer and budgets, Savings Plans and Reserved Instances, Graviton migration, storage transitions, and the standing habits that stop spend from drifting.
Topics: Reading a bill: usage types, data transfer and the surprises · Tagging strategy and cost allocation tags · Cost Explorer, budgets and anomaly detection · Savings Plans versus Reserved Instances · Graviton, rightsizing and instance family changes · Idle resources, orphaned volumes and unattached addresses · Building a monthly cost review engineers actually attend
We rebuild the agenda around the tools you actually run.
Request a custom agendaBreak access deliberately with a permission boundary and a service control policy, then walk the evaluation chain until you can explain the exact rule that denied the call.
Build a three-tier VPC across two Availability Zones, remove the NAT path, restore access to AWS services through VPC endpoints, and prove the private tier is unreachable.
Run one application on EC2 with Auto Scaling, on Fargate and as a Lambda function, then compare latency, failure behaviour, operational load and monthly cost.
Design S3 lifecycle transitions for a log workload with a retention obligation, enable versioning and encryption, and verify the object counts and cost after transition.
Provision network, compute, data and observability from Terraform with remote state, applied by a pipeline authenticating through OIDC with no stored keys.
Attribute a month of real spend by tag, identify reducible items, model Savings Plans and Graviton, apply changes and measure the delta against the same workload.
The most useful thing to know about AWS in Bangalore is how much of it is not production. Across the captive engineering sites that dominate the Outer Ring Road, Whitefield and Manyata Tech Park, the product being built serves customers on another continent and its live estate belongs to a parent organisation abroad; what the Bangalore team genuinely owns is development and test capacity, pre-production environments, continuous integration fleets and a growing data-science estate. The consequence is a spend profile almost nobody teaches to: the largest reducible lines are instances left running at 02:00, notebook servers nobody claimed, oversized test databases and build capacity that never scales to zero. Ephemeral environment provisioning, quota management, tagging that stands up to an internal recharge, and disciplined teardown are what get an engineer noticed here, far more than customer-traffic capacity planning.
That split also changes what an incident feels like. Engineers in Bangalore are routinely on call for an estate running in a North American or European region while sitting in IST, so federated console access from a locked-down corporate laptop, cross-region observability and a runbook that someone can follow at 03:00 local time matter more than region selection — the region was chosen years before they joined. The same organisation's India-facing product does usually run in ap-south-1 at Mumbai, with ap-south-2 at Hyderabad now available as a second in-country location, which leaves many Bangalore platform teams operating two structurally different estates with one set of habits.
The third concentration is machine learning and silicon. Bangalore holds India's largest population of ML engineers and chip design teams, and both meet the same constraint: accelerated instance families are quota-limited and expensive, so requesting capacity in advance, designing training jobs to survive interruption, and deciding whether a run belongs in Mumbai or in a region that actually has GPUs are live architecture questions rather than exam trivia. Local hiring follows the same two shapes — platform roles inside the captive sites test organisational-unit layout, identity federation and the ability to work correctly inside guardrails written in another country, while product companies in Koramangala, Indiranagar and HSR Layout test scale events, autoscaling under a national traffic spike, and cost per transaction.
Billed yearly at ₹9,996
Max 8 to 10 hours of live instruction
Full program, private instructor
8–30 engineers · custom agenda · onsite or online · PO and GST invoicing
Refunds. If we cancel or postpone a cohort, you get a full refund within 15 days. There is no money-back guarantee otherwise.
Terms. Course material remains licensed to the attendee. Read the terms.
Your data. We don't share it with third parties. Privacy policy.
Certificate of completion
Great learning experience from a very knowledgeable instructor with well-prepared course notes. The lab exercises on AWS instance work well to learn the hands-on side of the course.
Got good lab sessions which kept the new DevOps tool learnings to the point and it helped a lot in my career.
I took Terraform training with the tutor named Mithilesh. I requested to tailor the course curriculum for my needs. He did an excellent job of showing me how to write the Terraform script per the instructions provided.
My experience with the AIOps training was positive. The course covered important topics in a structured way, and Rajesh Kumar explained the concepts patiently. I found the practical aspects particularly helpful because they made the technical content easier to understand.
I was looking to improve my understanding of AIOps, and this training helped me achieve that goal. Rajesh Kumar explained the subject in a structured and practical manner. The sessions on different AIOps concepts were informative.
I recently did a SRE Session with Rajesh Kumar from DevOps School and the session was great. Right from 1st day till day 15, we had a very interactive session. Rajesh clarified our doubts and the tool demos were excellent without any hiccups. He simplified the concepts while sticking to the content with a fine balance between theory and practice. Am convinced he is one of the best trainers for SRE & DevOps concepts.
| What matters | YouTube + blogs | Generic online course | Freelance marketplace | DevOpsSchool |
|---|---|---|---|---|
| Named practitioner | No | Rarely | Varies per booking | Yes — same trainer each time |
| Production experience | Unknown | Unknown | Unverified | 20 years, named employers |
| Custom agenda | No | No | Sometimes | Built from your stack |
| Onsite delivery | No | No | Sometimes | Yes |
| Lab environment | None | Sandbox that expires | Varies | Your own cloud — skill goes with you |
| Assessment | None | Quiz | Rarely | Assignments + capstone per module |
| Per-attendee certificates | No | Sometimes | Rarely | Yes |
| Corporate invoicing | No | Limited | Varies | PO and GST |
| Post-training support | None | Forum, time-limited | None | Lifetime forum access |
Tell us the team, the stack and the timeline. You'll get a straight answer, not a sales sequence.
Talk to an advisorPrefer to call or email?
More ways to reach us on the contact page.