Private corporate batches, live online cohorts and 1-on-1 mentoring in service models, shared responsibility, landing zones and cloud economics across AWS, Azure and Google Cloud — taught by a practitioner who runs it 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 cloud computing provider-neutral first and provider-specific second: the shared responsibility boundary, identity and account or project structure, virtual networking and private connectivity, the compute spectrum from virtual machines through containers to functions, and the durability, consistency and cost characteristics of each storage class — then maps every one of those onto AWS, Azure and Google Cloud so the same architecture is built three times and compared. Sessions cover the parts teams get wrong in production: blast radius, egress cost, IAM privilege creep, and disaster recovery that has actually been rehearsed.
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 Cloud Computing that means a trainer who has run it in production — service models, shared responsibility, landing zones and cloud economics across AWS, Azure and Google Cloud — 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 premises, live online, or hybrid, scheduled around your release calendar rather than ours. Batches run 8 to 30 engineers.
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 Cloud Computing batchCloud computing is the delivery of compute, storage, networking and higher-level services as an on-demand utility — provisioned through an API, billed by consumption, and released when no longer needed. The defining shift is not that the hardware belongs to someone else. It is that capacity becomes a runtime decision: a network, a database or a hundred machines are things you request in seconds rather than things you procure in quarters.
Three service models describe how much of the stack the provider operates. Infrastructure as a Service hands you virtual machines, block storage, virtual networks and load balancers, and leaves everything from the operating system upwards to you. Platform as a Service takes the runtime as well, so you deploy an application rather than a server. Managed data services and functions go further, until you supply code and an event source and operate nothing at all. Cutting the other way, the deployment models — public, private, hybrid and multi-cloud — describe where capacity physically sits and who holds the keys.
Everything genuinely difficult about cloud computing lives underneath those definitions. The shared responsibility model decides which failures are yours and which are the provider's. Identity, not the network edge, is the real perimeter. Regions and availability zones are the unit of blast radius, and the bill scales with carelessness as readily as with growth. AWS, Azure and Google Cloud differ in naming and in detail, but the primitives — accounts or projects, IAM, virtual networks, managed compute, object storage, managed databases, audit logging — map across all three. That mapping is what makes cloud skill portable, and it is what a fundamentals course has to teach rather than a single provider's menu.
Almost every organisation now runs something in a public cloud, and a large number run in more than one — through acquisition, through a data-residency requirement, or because one team picked a managed service the rest of the estate does not use. The result is that engineers are expected to reason across providers rather than memorise one console.
The hiring gap is rarely about a specific service. It is about the concepts that keep appearing under different names: how identity federates, why a subnet without a route to a NAT gateway breaks a private workload, what a multi-AZ deployment actually protects against, when a managed database is cheaper than an unmanaged one and when it is not, and how a landing zone stops account sprawl before it starts. Those are transferable and they are what separates someone who can operate a cloud from someone who can follow a tutorial.
There is also a cost dimension that has become sharply commercial. Cloud spend is now one of the largest lines in many IT budgets, and most of the waste is architectural rather than accidental — the wrong storage class, an instance family chosen once and never revisited, egress nobody modelled. Engineers who can explain the bill are unusually valuable.
Definitions that carry weight rather than marketing. The five essential characteristics, the service models and what each one takes off your plate, the deployment models, and an honest account of what the cloud does not solve — including the workloads that belong on hardware you own.
Topics: On-demand self-service, elasticity, pooling and measured service · IaaS, PaaS, SaaS and functions — what the provider operates in each · Public, private, hybrid and multi-cloud deployment models · Provider landscape: AWS, Azure, Google Cloud and the specialists · Capex to opex, and where that argument breaks down · Workloads that should not move to a public cloud
The security model everything else rests on. Which layer the provider secures for each service type, why identity replaced the network edge as the perimeter, and how account, subscription and project structure decides your blast radius before a single machine exists.
Topics: The shared responsibility boundary per service model · Accounts, subscriptions, projects and the organisation hierarchy · Users, groups, roles, policies and trust relationships · Federation and single sign-on from an existing directory · Least privilege in practice — permission boundaries and guardrail policies · Service identities, instance roles and workload identity · Audit logging and who did what
The area that causes the most production surprises. Virtual networks and subnets, routing and gateways, the difference between public and private reachability, DNS resolution across boundaries, load balancing tiers, and connecting back to on-premises.
Topics: Virtual networks, subnets and address planning · Route tables, internet and NAT gateways · Security groups and network ACLs — stateful versus stateless · Private endpoints and service-private connectivity · DNS: split-horizon, private zones and resolution across peerings · Peering, transit hubs and hub-and-spoke topologies · VPN and dedicated interconnect back to a data centre · Layer 4 and layer 7 load balancing
Virtual machines, managed containers and functions are not alternatives ranked by modernity — they are different operational bargains. Instance families and sizing, images and immutability, autoscaling, managed container platforms, and where serverless genuinely wins or genuinely hurts.
Topics: Instance families, sizing and right-sizing evidence · Machine images, golden images and immutable infrastructure · Autoscaling groups, health checks and scaling signals · Spot, preemptible and reserved capacity models · Managed container services and managed Kubernetes · Functions, event sources, cold starts and concurrency limits · Choosing between the three for a real workload
Object, block and file storage have different guarantees, and picking wrongly is expensive in both money and correctness. Durability versus availability, storage classes and lifecycle, managed relational and non-relational databases, caching, and the backup question everyone defers.
Topics: Object, block and file storage — access patterns and guarantees · Durability versus availability, and what eleven nines means · Storage classes, lifecycle rules and archival retrieval cost · Managed relational databases: sizing, replicas, failover, maintenance windows · Key-value, document and analytical stores · Caching layers and when they hide a design problem · Encryption at rest, key management and customer-managed keys · Backup, retention and restore testing
Designing for failure rather than hoping against it. Regions and availability zones as the unit of blast radius, stateless design, recovery objectives, disaster recovery patterns and their real cost, then the structured approach to moving an existing estate.
Topics: Regions, availability zones and correlated failure · Stateless services, session handling and health checking · RTO and RPO — deriving them from the business, not from the tooling · DR patterns: backup and restore, pilot light, warm standby, active-active · Well-architected review as a working method · Migration approaches: rehost, replatform, refactor, repurchase, retire, retain · Discovery, dependency mapping and cutover planning · Data migration and the bandwidth problem
What keeps a cloud estate from degrading after month three. Landing zones and organisational policy, tagging that actually holds, posture management, secrets, compliance evidence, and reading a bill well enough to change architecture rather than just complain about it.
Topics: Landing zones and account vending · Organisational policy and preventative guardrails · Tagging strategy, enforcement and cost allocation · Posture management and continuous compliance checks · Secrets management and credential rotation · Budgets, anomaly detection and showback or chargeback · Commitment discounts, rightsizing and storage class optimisation · Egress, cross-zone traffic and the costs nobody models
We rebuild the agenda around the tools you actually run.
Request a custom agendaBuild the same two-tier application on AWS, Azure and Google Cloud, then map the primitives side by side and record where the abstractions genuinely differ.
Design an account and role structure for three teams, then reduce an over-permissive policy to least privilege using access evidence rather than guesswork.
Build a three-tier network where the data tier reaches managed services over private endpoints only, then diagnose a deliberately broken DNS and routing path.
Take a running workload, destroy an availability zone's worth of it, and recover within a declared objective — then record the real number, not the intended one.
Take an untagged cost export, attribute it to teams and workloads, and identify the architectural decisions behind the three largest lines.
Stand up a landing zone with guardrails, then plan and execute the migration of one application including cutover, validation and rollback.
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.
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.
The Rundeck developer session was excellent and highly engaging. I appreciated how well the session was structured, with the theoretical concepts explained clearly and in simple terms. What stood out most to me was the demo — it was both informative and enjoyable. I especially liked how Rajesh walked us through not only the happy path but also the sad path, showcasing common issues and sharing practical troubleshooting tips.
Rajesh's experience and knowledge are exceptional and we learnt invaluable practical knowledge which we can apply in our production environment. Incredibly friendly and gave us a fantastic insight both in-depth and at a high level of the Rundeck product.
Rajesh is a very good trainer I have experienced in DevSecOps training. The number of contents in different topics he has posted on the DevOpsSchool public website are amazing and user friendly for beginners and experienced professionals.
| 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.