Private corporate batches delivered onsite across Pune, 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 from the boundaries outward — account structure, policy evaluation and VPC reachability before any service catalogue — and labs run in ap-south-1 so latency, residency and cost behave the way they will for a Pune workload. The syllabus carries the edges this market hits: assuming a role into an organisational unit you do not control, tracing a denial through identity policy, resource policy, permission boundary and service control policy, extending a network over Direct Connect and VPN until asymmetric routing and split-horizon DNS are demonstrated rather than described, and attributing a month of spend by tag before anyone argues about commitment purchases.
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 architecture and operations for Pune's regulated captives and SaaS product teams — 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.
Onsite sessions run across Kharadi, Magarpatta, Baner, Balewadi, Hinjewadi, Yerwada and Viman Nagar; you provide the room, a screen and internet egress to AWS, we bring trainer, agenda, lab material, assessments and certificates. Hours are 09:30 to 17:30 IST, and because so many Pune teams owe an evening overlap to a US or EMEA counterpart we frequently split the same content into 08:00 to 13:00 IST half-days across more calendar days. Attendees provision their own accounts for labs — a personal free-tier account or a sandbox account from your landing zone — and we walk the group through budget alarms and teardown so nobody is surprised by a bill; where corporate policy forbids personal accounts we adapt the labs to a sandbox OU with a spend cap. All work is done in ap-south-1 by default so latency and residency behave the way they will in production. Invoicing is in INR with GST against your purchase order from the Indian entity.
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 Amazon's public cloud — several hundred services for compute, storage, data, messaging and identity, all created, permissioned, logged and billed through one API. For an engineering team in Pune the first fact worth internalising is not the size of that catalogue but its geography. The nearest region, ap-south-1, sits in Mumbai, close enough that a leased circuit from a Pune office reaches it in single-digit milliseconds, which is why so much local work is deliberately hybrid: an application tier in the region, a system of record that residency rules keep on your own premises, and a Direct Connect leg with a VPN standing behind it.
Three decisions then carry the rest of a design. Which account a workload belongs in, because the account is where quotas apply, billing lands and a mistake stops — and here that account often belongs to a customer, so the working skill is assuming a role into it, operating under service control policies written elsewhere and proving least privilege without ever seeing the management account. What routing and security groups sit around it, since subnets, route tables, NAT, interface endpoints and Transit Gateway attachments decide reachability, and hybrid routes are where reachability quietly stops behaving. And where the data physically rests, because KMS key policy, replication scope and region pinning are what an auditor actually asks about.
The rest composes on top: EC2 with launch templates and Auto Scaling, S3, EBS and EFS, RDS, Aurora and DynamoDB, Lambda with SQS, SNS and EventBridge, containers on ECS, Fargate and EKS, and CloudWatch, CloudTrail and Config as the record of what happened. Teams that operate AWS well express all of it in CloudFormation or Terraform and tag it so every rupee of the bill lands on a team that can explain it.
Two forces pull AWS demand in Pune in different directions at the same time. The regulated captives — banking, insurance, payments and their shared-services arms around Kharadi, Yerwada and Magarpatta — are long past deciding whether to use the cloud and deep into proving where data rests and who could have reached it. That is architecture and evidence work: region pinning enforced by policy rather than by convention, private connectivity back to systems nobody is allowed to retire, encryption whose key policy names a specific principal, and an audit trail that holds up when someone asks about a Tuesday six months ago.
The product and SaaS benches in Baner, Balewadi, Viman Nagar and Kalyani Nagar ask a different question. Their estate is already on AWS and the pressure is unit economics — Savings Plans against Spot for build fleets, Graviton, S3 lifecycle transitions, cross-zone transfer nobody budgeted for, and cost attributed per tenant rather than per account. Spend is reviewed here alongside latency, by engineers rather than by finance.
Underneath both sits a condition specific to a services city: a large share of Pune engineers operate inside somebody else's AWS Organizations. Local interviews reflect it. Explaining permission boundaries, external IDs and why a call was denied when the identity policy plainly allows it is worth more in this market than reciting instance families.
The boundary layer first, because everything after it inherits the answer. What an account actually isolates, how organisational units and service control policies bound it, and then the situation most engineers here work in — holding a role inside an estate whose management account belongs to a customer. Policy evaluation is taught by breaking access on purpose and reading which layer produced the denial.
Topics: The account as isolation, quota and billing boundary · Organizations, organisational units and service control policies · IAM users, groups, roles, instance profiles and service-linked roles · Identity, resource and trust policies, and why an explicit deny always wins · Cross-account role assumption, external IDs and confused-deputy protection · Permission boundaries and delegated administration · Federated single sign-on, permission sets and short-lived credentials · Debugging an AccessDenied with CloudTrail, Access Analyzer and the policy simulator
Reachability built by hand until it is obvious, then extended off the region. Subnet tiers, route tables, stateful security groups against stateless network ACLs, and egress you can defend. Then the hybrid half that local designs depend on: site-to-site VPN, Direct Connect with a standby path, route propagation through Transit Gateway, and DNS that has to resolve in both directions.
Topics: CIDR planning that will not collide with an existing on-premises range · Subnets, route tables, internet gateways and NAT · Security groups versus network ACLs, and where each belongs · Gateway and interface endpoints, and PrivateLink to a partner service · Site-to-site VPN, Direct Connect, virtual interfaces and failover behaviour · Transit Gateway attachments, route tables and propagation · Route 53 private hosted zones with inbound and outbound Resolver endpoints · Flow logs, Reachability Analyzer and diagnosing asymmetric paths
Choosing compute on evidence rather than habit. Instance families and purchase options, image construction, launch templates and the difference between an instance status check and a target-group health check, which is where most bad scaling behaviour begins. Then containers with task and pod-scoped identity, and functions where the work is genuinely event-shaped.
Topics: Instance families, Graviton, and on-demand, Spot, Reserved and Savings Plan pricing · Image pipelines, user data and instance metadata service v2 · Launch templates, Auto Scaling groups and scaling policy types · Load balancer target groups, health checks and connection draining · ECS task definitions, Fargate, awsvpc networking and task roles · EKS node groups, Fargate profiles and IAM roles for service accounts · Lambda concurrency, cold starts, VPC attachment and event sources · Systems Manager Session Manager and Patch Manager instead of open SSH
Where state lives and what it costs to keep it there. S3 semantics taught through the access-control interaction that causes most incidents, then storage classes and lifecycle as a cost lever rather than a checkbox, block and file storage for workloads that cannot be re-architected, and a backup design whose restore has actually been run.
Topics: S3 storage classes, lifecycle transitions and Intelligent-Tiering · Versioning, Object Lock, replication and what replication does not copy · Bucket policies, Block Public Access, access points and presigned URLs · EBS volume types, IOPS, throughput and snapshot strategy · EFS and FSx for Windows workloads that expect a shared file system · AWS Backup, backup vaults and cross-account copies · Request, retrieval and transfer charges as design inputs
The service choice that is hardest to reverse. Relational engines on RDS and Aurora judged on failover and maintenance behaviour rather than feature lists, DynamoDB modelled from access patterns instead of from an entity diagram, caching where it genuinely helps, and the migration and replication paths used when a system of record has to stay where it is.
Topics: RDS engine choice, parameter and option groups, maintenance windows · Multi-AZ failover, read replicas and what each actually protects against · Aurora storage model, cluster endpoints and failover ordering · DynamoDB partition key design, capacity modes, global secondary indexes and streams · ElastiCache and RDS Proxy for connection pressure · Database Migration Service and change data capture from an on-premises source · Encryption at rest and in transit, and point-in-time recovery drills
Making an account reproducible and reviewable. CloudFormation as the native path — template structure, intrinsic and condition functions, change sets, rollback behaviour and StackSets across accounts — then Terraform where the estate spans more than one provider, with remote state, locking and module structure. Adoption of hand-built resources gets its own time, because that is what most teams face.
Topics: Template structure, parameters, intrinsic functions and condition functions · Stacks, change sets, rollback triggers and cross-stack references · StackSets and drift detection across accounts and regions · Terraform providers, remote state in S3 with locking, and module layout · Importing resources that were created by hand · Pipelines that authenticate by OIDC federation instead of stored keys · Environment promotion and reviewing an infrastructure diff properly
Knowing what happened, proving it, and being paged only when it matters. Metrics and logs that answer questions, alarms designed for a rota that hands over in the evening, and the audit surfaces — CloudTrail and Config — that turn a suspicion into a timeline. Operational automation is included because runbooks that nobody can execute at 02:00 are not runbooks.
Topics: CloudWatch metrics, custom metrics and the embedded metric format · Log groups, subscription filters and Logs Insights queries worth keeping · Alarms, composite alarms and thresholds that survive a handover · Dashboards a colleague in another timezone can read unaided · CloudTrail for API history, and Config rules and conformance packs · EventBridge rules driving operational automation · Systems Manager documents and automation runbooks · Building an incident timeline from the record rather than from memory
The module that decides whether a design survives review. Key management as policy rather than as a checkbox, secrets that rotate, and residency treated as something you enforce and evidence rather than something you promise. Detection services are covered for what they actually produce and who is expected to act on it.
Topics: KMS keys, key policies, grants and envelope encryption · Multi-region keys, and the replication constraints they impose · Secrets Manager and Parameter Store, rotation and access scoping · Region pinning with policy conditions, and where it can be bypassed · GuardDuty, Security Hub, Inspector and Macie findings and ownership · Reviewing external exposure across accounts with Access Analyzer · Assembling residency and control evidence an auditor will accept
The bill as an engineering signal. Where charges actually come from, including the transfer and request lines that never appear in a design review, tagging that supports attribution rather than decoration, and the commitment, architecture and lifecycle changes that reduce spend without reducing resilience. It ends with a review cadence engineers will attend.
Topics: Reading a bill: usage types, transfer charges and cross-zone traffic · Cost allocation tags, tag policies and enforcing them at creation · Cost Explorer, budgets, anomaly detection and cost categories · Savings Plans versus Reserved Instances versus Spot, and blast radius of each · Graviton migration and rightsizing from measured utilisation · Storage lifecycle, log retention and idle resource sweeps · Per-team and per-tenant showback, and NAT versus endpoint economics
We rebuild the agenda around the tools you actually run.
Request a custom agendaAssume a role into an account governed by a service control policy you cannot read, trigger a denial, then determine from CloudTrail and the policy simulator which layer refused the call.
Attach a simulated on-premises network to a Transit Gateway over VPN, resolve DNS in both directions, then break a return route and diagnose the asymmetric path from flow logs.
Run a multi-AZ Auto Scaling group behind a load balancer, remove a zone from service and confirm capacity, health checks and the database failover behave as designed.
Restrict a workload to the Mumbai region with policy conditions, encrypt it with a customer-managed key, attempt a prohibited action, then assemble the evidence pack from CloudTrail and Config.
Import a hand-built network, compute and storage stack into Terraform, reconcile the drift, then destroy and recreate the whole thing from code.
Tag an estate for attribution, produce a per-team spend report, model commitments and Graviton, apply changes and measure the delta on the same workload.
Pune's AWS conversations are shaped by geography most other Indian cities do not share: the ap-south-1 region sits roughly 150 kilometres away in Mumbai, close enough that a dedicated circuit from a Pune office gives single-digit millisecond round trips. That makes hybrid architectures genuinely practical here — a database that has to stay on-premises for residency reasons with application tiers in the region, a Direct Connect leg with VPN failover, on-prem identity fronting cloud workloads — and those designs are what Pune buyers actually ask to be taught. Combined with the residency obligations carried by the banking, insurance and payments captives around Kharadi, Yerwada and Magarpatta, a batch here spends far more time on VPC and Transit Gateway design, PrivateLink, KMS key policy and evidence for an auditor than on launching an instance.
The second Pune audience is the product and SaaS bench in Baner, Balewadi, Viman Nagar and Kalyani Nagar, where the estate is already on AWS and the live question is unit economics: Savings Plans against Spot for build fleets, Graviton migration, S3 lifecycle and egress, and per-tenant cost attribution. A third pattern is specific to a services city — a large share of Pune engineers operate inside a customer's AWS Organizations, not their own, so cross-account role assumption, permission boundaries, service control policies and least privilege under a root someone else controls come up in local interviews far more often than they do in a product-only market.
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.
The trainer (Rajesh) provided very good sessions on SRE profession. Not only hands-on learning on the tools but also SRE mindset.
Very good training session. Well explained from the basics to the complex concepts. Also tried to cover practicals and demos within the 3 hour sessions. The learning content and videos are of a great deal of help.
Basics explanation was exemplary from Rajesh where he dealt with complicated topics to be simple. Great learning stuff personally for me.
Very detailed explanation and has lots of patience in attending the questionnaire. Thanks again for your wonderful sessions.
Good discussion, helped us to understand different tools in SRE.
| 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.