SRE Labs (Advanced Track) — Project Call: InfraRemediation Series Overview & HealthCorp AWS Cost Optimization

Structured educational resource covering sre labs (advanced track) — project call: infraremediation series overview & healthcorp aws cost optimization.

senior 45 min read 11 sections

#kubernetes#cloud-k8s#aws#gcp

Flagship Project Introductions + Live Architecture Migration Demo (Intel → AMD → ARM)

2. Table of Contents

Executive Summary
Table of Contents
Detailed Structured Notes
- 3.1 Purpose of the Project Call (vs. Shadowing, vs. Weekly Curriculum)
- 3.2 The Five Flagship Projects — Full Roster
- 3.3 HealthCorp Client Profile & Infrastructure Snapshot
- 3.4 HealthCorp Inventory & Cost Analysis
- 3.5 Cost Optimization Layering Strategy
- 3.6 Foundational Setup: Tagging & AWS Tooling to Enable First
- 3.7 EC2 Cost Optimization Techniques (Full Catalog)
- 3.8 Architecture Migration Deep Dive (Intel → AMD → ARM)
- 3.9 Live Demo: Standalone Instance Migration, Step by Step
- 3.10 Savings Plans — Key Concepts
- 3.11 Other Layers Previewed (Storage, Monitoring, Networking, Security, DB, ECR→Harbor)
- 3.12 Q&A Highlights — Baselining, Governance, IaC vs. ClickOps, FinOps Multi-Account Budgeting
- 3.13 Program Logistics Notes
Key Concepts Table
Architecture & Workflow Analysis
Commands & Configurations
Tools & Technologies
Real-World Production Usage
Interview Preparation (Beginner / Intermediate / Advanced)
Exam & Certification Notes
Cheat Sheet
Gaps & Assumptions

3. Detailed Structured Notes

3.1 Purpose of the Project Call (vs. Shadowing, vs. Weekly Curriculum)

A participant asked directly how this “project call” differs from the live FintechPlatform “shadowing” sessions, and the instructor’s clarification is worth preserving precisely:

Shadowing calls = live implementation happening in real time on an active client’s actual infrastructure (FintechPlatform). What you see is being decided and executed live.
Project calls = deep dives into past, completed client engagements (HealthCorp, SecureAsset, and others) — walking through the configuration, the decisions made, the problems encountered, and how they were solved, then replicating a minimal version of that environment in SRE Labs’s own playground for hands-on practice.
Weekly curriculum modules = the self-paced foundational material (Linux, networking, Kubernetes fundamentals, etc.) plus the Saturday war-room drills tied to that week’s topic.

The stated goal of the project call track specifically: convert each flagship project into a piece of interview-ready experience — each project explicitly answers three questions: (1) what was the real business problem, (2) what were the technical constraints, and (3) how was the solution designed, implemented, and delivered on time — including the production outages/failures encountered along the way and how they were resolved (explicitly generating “war-room thinking” even outside the dedicated war-room drills).

A meaningful, unresolved tension surfaced in the Q&A: several participants (notably a very experienced one) pushed back that jumping straight into large, real client architectures without first walking through basic reference architectures (a simple three-tier app, a basic CI/CD pipeline on each of AWS/GCP/Azure) left them without the foundational scaffolding to fully absorb the advanced material. The instructor acknowledged this as a valid structural concern and proposed continuing the discussion after the call rather than resolving it live — flagged as an open program-design item, not something resolved within this session.

3.2 The Five Flagship Projects — Full Roster

The six-week program’s projects map onto the four pillars of DevOps: cost, security, availability, and scalability. The full roster, as introduced in this session:

#	Project (Series Name: “InfraRemediation”)	Client	Domain	Focus
1	AWS Cost Optimization	HealthCorp	Healthcare (Texas, US)	Full-stack AWS cost engineering — compute, network, data, monitoring, other tools. This session’s main topic.
2	Security Audit	SecureAsset	Fintech (part of the Groww ecosystem, India)	Architectural security audit, layer-by-layer security hardening — happens the following week
3	Live Client Engagement	FintechPlatform	Blockchain/Web3 (Dubai)	The ongoing “shadowing” track — live GCP cost optimization → security hardening → HA/scalability (50% GCP/AWS migration), 1–2x/week. Carries a potential hiring opportunity for standout participants.
4	Massive-Scale Microservices Infrastructure	Undisclosed large India-based e-commerce MNC	E-commerce, India	Managing ~700 microservices at scale — CI/CD at scale (rollback, versioning, notifications), Terraform at scale, end-to-end observability (system health + user behavior + latency)
5	Automation + AI / Self-Healing Infrastructure	SRE Labs’s own internal tool (“AutoRemedy Engine”)	Internal product	Automating repetitive DevOps tasks (CI/CD pipeline creation, deployment, secrets management, observability integration) plus a self-healing infrastructure concept — if infrastructure breaks, it automatically raises a PR with a proposed fix for human approval. Scheduled for ~Feb 22.

Additional non-project content mentioned:

An MLOps / AI infrastructure session (tools like Kubeflow, MLflow) — planned as part of Sunday sessions.
A case study (not a live call) on how SRE Labs built its own cloud platform product — including real architectural decisions, daily-basis failures/issues, and how they scaled it. Presented with a callout that SRE Labs is actively hiring for this product team.

Scheduling note surfaced live: Participants pushed back on the microservices project (#4) being scheduled last (originally Feb 22); the instructor agreed to move it earlier (discussed moving to Feb 8 or the first week of Feb) based on cohort demand to explore it sooner rather than later.

3.3 HealthCorp Client Profile & Infrastructure Snapshot

Attribute	Detail
Client	HealthCorp
Industry	Healthcare
Location	Texas, US
Account structure	Single AWS account shared across production and non-production (dev, staging) — no account-level environment separation
Total monthly billing (pre-optimization)	~$98,000/month
Production-only billing	~$45,000/month of the $98K total
Achieved result (past engagement, historical)	~80% total cost reduction — cited as a major achievement that’s part of why this project was chosen as a flagship case study

Full service inventory (as covered):

Layer	Services
Compute (server)	EC2, EKS, Lightsail
Compute (serverless)	Lambda, ECS
Database	RDS, DynamoDB, DocumentDB, Redshift, ElastiCache
Storage	S3, EBS (+ snapshots)
Monitoring/Logging	CloudWatch (logs + metrics)
Networking	NAT Gateway, VPC Peering, ALB (Application Load Balancer), external/Elastic IPs, Global Accelerator
Security	Inspector, GuardDuty, WAF, IAM
Artifact/Registry	ECR (later migrated to Harbor, an open-source container registry, for cost savings)
Messaging	SQS, SNS
Cost management	Savings Plans

3.4 HealthCorp Inventory & Cost Analysis

Following the same inventory-first discipline established in the FintechPlatform engagement, the team built a full AWS resource inventory (a “master sheet”) covering every service category, broken down by environment (prod vs. non-prod, using tags).

EC2 inventory specifics:

~170 total EC2 instances.
The large majority were running on Intel architecture (identifiable by instance-family naming: no a or g suffix = Intel; a suffix = AMD; g suffix = ARM/Graviton).
116 instances were flagged as candidates for architecture optimization.
Instances were also categorized by utilization level: underutilized, properly utilized, overprovisioned — using a custom script that analyzed usage data against a compliance-driven baseline window.
Certain instances were explicitly excluded from scope by the client due to business criticality — documented in the inventory sheet so the boundaries of the engagement were clear.

Quantified savings opportunities identified:

Optimization	Savings Identified	Basis
Intel → AMD migration (single example instance)	$131/month	One instance migrated from Intel-family to `C5a.4xlarge`-equivalent AMD family (price dropped from $0.80/hr → $0.62/hr)
Intel → AMD migration (aggregate, 20 instances)	~$935/month	Achieved with no application performance compromise, based on automated cost-calculator scripting
Compatible-instance ARM (Graviton) migration list	~$1,500/month	A curated list of instances confirmed application-compatible with ARM, built using AWS’s Graviton compatibility scanning tooling
EBS — deleting idle/unused volumes	~$3,700/month	Based on inventory of assigned vs. actually-used volume capacity
EBS — GP2 → GP3 migration	Additional savings (not separately quantified in the call)	Standard, low-risk storage-class optimization
Total EC2-layer optimization scope (combined)	~$8,000/month	Includes right-sizing, non-working-hours downscaling, architecture migration, and related EC2-layer changes together

Tooling used to build the automated cost-comparison workflow: The team used the AWS Pricing Calculator, combined with a script built on top of the AWS SDK, to programmatically compute price differences between architecture families rather than doing manual price lookups — described as giving “a comprehensive list of the cost vector” for the full inventory at once.

3.5 Cost Optimization Layering Strategy

The team organized the full HealthCorp engagement into five layers, tackled either sequentially or prioritized by whichever layer is costing the most:

Compute layer — split further into:
- Server computing (EC2, EKS, Lightsail)
- Serverless computing (Lambda, ECS)
Network layer
Data/Storage layer
Monitoring layer
Other tools layer (miscellaneous AWS services not covered above)

This session focused almost entirely on layer 1 (compute → EC2 specifically), with the other layers previewed at a high level for future sessions.

3.6 Foundational Setup: Tagging & AWS Tooling to Enable First

Tagging — described as “the most important thing” in cost engineering, regardless of cloud provider:

Standard tag set recommended:

Name — the resource’s identifying name.
Owner — the team/individual responsible (e.g., “DevOps team”).
Env — environment (prod, dev, staging, playground, etc.).
LOB (Line of Business) — which business unit/product line owns this resource, for cost-attribution and audit purposes across organizations with multiple business lines.

Rule stated explicitly: every resource, whether created via ClickOps or Terraform, must be tagged — no exceptions, because tagging is the foundation that makes later cost-attribution, auditing, and automated scripting (e.g., stopping all “dev”-tagged instances at a scheduled time) possible at all.

AWS tools to enable before starting any cost optimization work (in the order recommended):

Cost Explorer — foundational visibility into where cost is coming from.
Compute Optimizer — optimization recommendations across compute resources (EC2, Lambda, and other compute).
Trusted Advisor — a broader tool (paid) covering multiple categories:
- Cost — right-sizing recommendations, idle instance identification, storage optimization.
- Security — e.g., MFA enablement checks, other security posture gaps.
- Performance — e.g., autoscaling and health-check recommendations.
- Service Limits — quota monitoring (how much of each service quota remains).
- Operational Excellence — AWS best-practices compliance checks.
Cost Anomaly Detection — automated alerting on unusual cost spikes tied to specific services/resources.

Cost note: Trusted Advisor’s full feature set is a paid AWS capability (as also discussed in the GCP-side sessions, where GCP’s equivalent, Active Assist, was noted as free) — worth remembering as a recurring cross-cloud comparison point.

3.7 EC2 Cost Optimization Techniques (Full Catalog)

The instructor ran this section as an interactive brainstorm with participants, then consolidated the full list of techniques the HealthCorp engagement actually implemented on the compute layer:

Reservations (Reserved Instances) — long-term commitment, tied to a specific instance type/family.
Savings Plans — commitment-based discount, but not tied to a specific instance type (more flexible than RIs) — see Section 3.10.
Right-sizing — analyzing actual utilization against provisioned capacity and adjusting instance size accordingly.
Architecture migration (Intel → AMD → ARM/Graviton) — the session’s main technical deep dive; see Section 3.8.
Spot instances — for non-critical, non-production workloads only; explicitly not recommended for production because Spot doesn’t guarantee availability (instances can be reclaimed by AWS on short notice).
Auto Scaling Group (ASG) refinement — understanding and tuning ASG behavior to avoid over-provisioning.
Eliminating stopped/unused instances.
Non-production scheduling — automated shutdown of dev/non-prod resources outside working hours (e.g., stop by 10 p.m. IST, start by 6 a.m. IST), implemented via a Lambda- or Jenkins-hosted script triggered by EventBridge, filtering resources by their env tag.
Availability Zone (AZ) migration/consolidation — reviewing whether instances spread across multiple AZs could be consolidated into a single AZ where appropriate, to reduce cross-AZ data transfer cost.
AMI/OS shifting — e.g., moving from Windows-based AMIs to Linux-based AMIs where the application platform allows it, since Windows licensing adds meaningful cost.
Public/Elastic IP cleanup — removing unused external IPs.
Vertical vs. horizontal scaling awareness — avoiding unnecessary vertical scaling where horizontal/autoscaling approaches would be more cost-efficient.

Explicitly out of scope for this specific engagement (a deliberate boundary): The instructor clarified that HealthCorp’s own internal DevOps team owned architectural design, application-nature decisions, and business logic changes — SRE Labs’s engagement scope was cost engineering only, respecting existing application performance, not redesigning the application or its architecture.

Lambda/EventBridge-based non-prod scheduling detail: Rather than paying ongoing Lambda invocation costs for scheduled shutdown scripts, the team noted an alternative of hosting such scripts on Jenkins (or another external-to-cloud platform) combined with EventBridge for scheduling triggers — framed as a cost-conscious alternative to a pure serverless approach for this specific automation need.

3.8 Architecture Migration Deep Dive (Intel → AMD → ARM)

This was the technical centerpiece of the session.

The three architecture tiers, by relative cost (most → least expensive):

Intel (x86) — most expensive.
AMD (x86) — mid-tier.
ARM / Graviton (AWS’s custom ARM-based processor family) — cheapest.

Compatibility assessment — the mandatory first step:

Migrating Intel → AMD is described as compatible for the vast majority of applications (both are x86-family processors), rarely causing issues.
Migrating to ARM/Graviton is architecturally different and requires actual compatibility verification — application dependencies, third-party libraries, and native code can have hard architecture dependencies that must be checked before migrating.
Tool used: AWS Porting Advisor for Graviton. This tool scans an application’s third-party dependencies (e.g., a Node.js app’s package.json-declared dependencies) and flags any that have architecture-specific dependencies incompatible with ARM — reporting specific file/line-level issues to fix. It can be run locally (installed in your IDE) or as a Docker image against the codebase.
The instructor’s stated best practice: developers assess application-level compatibility (they know the codebase), while DevOps engineers independently verify using tooling like the Porting Advisor — then proceed only once both perspectives align.

Safe migration path — Intel → AMD → ARM, not direct Intel → ARM:

Direct Intel → ARM migration is technically possible but carries a larger blast radius if something goes wrong.
The recommended, lower-risk path is a two-step migration: Intel → AMD first, then AMD → ARM — smaller blast radius at each step, easier to isolate and roll back if an issue surfaces.

Three instance-management categories, each requiring a different migration approach:

Standalone instances — not managed by an Auto Scaling Group or an EKS node group; a single, independently-managed EC2 instance.
Auto Scaling Group (ASG) instances — managed collectively by an ASG.
EKS node group instances — Kubernetes worker nodes managed as part of an EKS node group.

Critical, non-obvious nuance — migration difficulty ordering reverses depending on direction:

Direction	Easiest	Medium	Hardest
Intel → AMD	Standalone	ASG	EKS node group
AMD → ARM	EKS node group	ASG	Standalone

This session covered the standalone Intel → AMD case live (the simplest combination); ASG and EKS node group migrations were deferred to the following session due to time.

3.9 Live Demo: Standalone Instance Migration, Step by Step

Full procedure demonstrated live, in order:

Identify the current instance type and its equivalent in the target architecture family. Example used: T3.medium (Intel) → equivalent AMD instance is T3a.medium. The instructor noted this requires understanding AWS’s instance family naming conventions and cross-referencing AWS’s own documentation for equivalent families across architectures.
Take a backup (AMI) before touching anything. Navigate to the instance → Image and Templates → Create Image. Attach the associated volume(s). Use a clear, timestamped, descriptive name and description (e.g., “Intel instance backup — taken while migrating Intel instance to AMD — [date] [time]”). Tag the AMI with the same standard tag set (Name, Owner, Env, LOB).
Wait for the AMI to reach “active” status before proceeding. This is explicitly called out as a step that must never be skipped in a real production migration, even though it was fast-forwarded for the sake of the demo.
Stop the instance.
Change the instance type: Instance → Actions → Instance Settings → Change Instance Type → enter the target instance type (e.g., T3a.medium). The console will show the price delta immediately. CPU, memory, and storage configuration remain otherwise identical (unless you deliberately choose to also resize at this step, which the instructor explicitly avoided in this demo to isolate the architecture-only variable).
Start the instance.
Monitor application behavior for 48–72 hours post-migration (window may vary by application/business criticality) — watching for any performance regressions or issues before considering the migration final.
Validate actual cost savings in Cost Explorer: Filter by the specific instance ID, compare day-over-day cost before vs. after the migration, to confirm the change is actually reflected in billing (not just theoretically expected) — worth capturing as evidence to share with the team/client.
Delete the AMI backup after the monitoring window has passed (roughly 1–2 weeks was suggested) — explicitly to avoid accumulating unnecessary backup storage cost, which would undercut the point of a cost-optimization exercise.

Production-specific note from Q&A: At HealthCorp specifically, migrations of this kind were executed within a ~30-minute daily downtime window, agreed with the client — used both for the change itself and for immediate validation before closing out that day’s window.

3.10 Savings Plans — Key Concepts

Two AWS Savings Plan types: Compute Savings Plans (broadest flexibility, applies across EC2, Lambda, and Fargate) and EC2 Instance Savings Plans (narrower, EC2-specific).
Key distinction from Reserved Instances (RIs): RIs commit you to a specific instance type/family; Savings Plans commit you to a dollar-per-hour spend level, and that commitment can be applied flexibly across any instance type, as long as your usage covers the committed spend.
Savings Plans do not apply to Spot instances by default — only On-Demand usage is eligible for the discount.
Purchase parameters that affect discount depth: payment structure (no upfront / partial upfront / all upfront) and term length (1 year / 3 years) — a participant noted that 3-year, all-upfront commitments typically yield the deepest discount.
Explicit warning given: buying Savings Plans “blindly” off the AWS-recommended default in the console can cause real problems — there’s a specific calculation methodology (a dedicated AWS Savings Plan calculator) that should be used to right-size the commitment rather than accepting the default recommendation uncritically. The instructor referenced having built a ~30–40 page internal documentation guide specifically on this methodology (to be shared via the drive, not reproduced in this transcript).
If a purchased Savings Plan ends up under-utilized relative to actual usage, this becomes a real cost-inefficiency problem — flagged as a topic the instructor planned to cover in more depth in a dedicated section (not fully resolved within this session).

3.11 Other Layers Previewed (Storage, Monitoring, Networking, Security, DB, ECR→Harbor)

Covered briefly, with full deep-dives deferred to later sessions:

Storage: Removing unused EBS volumes, analyzing/cleaning up snapshots, EBS volume “shrinking” (not directly possible — achieved indirectly via detach/reattach + snapshot workflows), GP2 → GP3 migration, and S3 lifecycle policies (moving data from Standard storage class to Glacier or other cold-storage tiers over time).
Monitoring/Logging: CloudWatch log group analysis and categorization — directly analogous to the Cloud Logging optimization work already demonstrated live on the FintechPlatform GCP engagement (referenced explicitly as a parallel case, with that engagement’s ~$15,000 logging bill cited as a comparison point).
Networking: Described as comparatively straightforward, deferred to a future session.
Security: GuardDuty, Inspector, plus unspecified third-party security tools for analyzing security boundaries, breaches, and DoS exposure.
Database/Middleware: RDS and ElastiCache optimization, to be covered “in action” in a future session.
ECR → Harbor migration: A concrete, already-implemented change at HealthCorp — the client migrated from AWS ECR (Elastic Container Registry) to Harbor, an open-source container registry, specifically to reduce registry cost. Presented as a real, implemented decision rather than a hypothetical.

3.12 Q&A Highlights — Baselining, Governance, IaC vs. ClickOps, FinOps Multi-Account Budgeting

On cost-optimization baselining (a substantial, technically rich exchange):

A participant pushed hard on a genuinely important question: how do you distinguish a true “overprovisioned” resource from one that’s correctly provisioned for headroom against future traffic spikes or planned feature launches — especially if your baseline window (e.g., 90 days) predates a major change?
The instructor’s answer: baseline length should be business-driven, not fixed — some organizations need 365 days or more (or even multiple years) if traffic has strong seasonality; the process is inherently continuous, not a one-time exercise.
A more experienced participant added a practical middle-ground view: 3 months of data is often “enough” to make an initial rightsizing decision, provided you pair that decision with ongoing monitoring/alerting and treat it as an evolving process, adjusted differently for production vs. non-production resources — this was affirmed by the instructor as a good practical synthesis.
Another participant added: pairing any architecture/instance migration with performance testing before and after the change (with recorded baseline traces) gives you concrete evidence the change didn’t degrade the application — the instructor confirmed this aligns with the 48–72 hour (or up to a week, depending on business nature) post-migration monitoring window already discussed.

On manual changes vs. Infrastructure-as-Code in production (an important, real-world-grounded correction from a participant):

The instructor’s live demo used manual console steps (appropriate for teaching/demo purposes).
A participant with direct production experience pushed back firmly: at scale (they cited doing this for 40 servers in their own production environment), manual changes are explicitly the wrong approach — the reasons given were auditability and state-file consistency (if you change things manually outside Terraform, your Terraform state no longer reflects reality, and you lose your baseline configuration reference, which risks uptime).
Consensus reached: Terraform (or Pulumi) for general infrastructure provisioning, often layered with Ansible for server-level configuration, and/or Python scripting for custom orchestration logic (e.g., sequencing which instance stops/starts when, handling subnet/VNet changes, persistent volume attach/detach logic) — described accurately as “not a one-size-fits-all” decision, but dependent on the specific infrastructure and change complexity.
Notable, explicitly-acknowledged gap in HealthCorp’s own original engagement: the instructor admitted that, at HealthCorp specifically, changes were made via ClickOps only — no Terraform was used in that actual historical engagement, despite this being explicitly named as not the recommended standard. Terraform modules were promised to be uploaded to the drive separately as a best-practice reference, distinct from what was actually done at HealthCorp.

On multi-account FinOps governance (Landing Zone / Control Tower context):

A participant with real enterprise experience asked how budget restriction and cost governance work across a multi-account AWS Organization (e.g., Landing Zone / Control Tower setups with a dedicated FinOps account).
Another participant answered this thoroughly (worth preserving as a distinct, valuable practical explanation):
- AWS Budgets can be associated with a specific account/resource scope to trigger alerts when spend approaches or exceeds a threshold.
- Service Quotas provide a separate restriction mechanism (capping how much of a given resource type can be provisioned).
- The FinOps team’s role is primarily monitoring, controlling, and reporting — not deciding budget levels. The application/owner team is the actual decision-maker on what consumption level is valid for their workload, because they understand the business need.
- Correct IT lifecycle sequencing: when an application team requests new resources, the budget/capacity/forecast conversation should happen before provisioning — budget plans, along with associated alerts/monitoring, should already be in place at the time resources are provisioned, not retrofitted afterward.
- Deviation tolerance: a rough industry rule of thumb cited was that ±10–20% deviation from the originally forecasted budget is generally acceptable; deviations beyond that (e.g., ±50%, as used in the example) should trigger a formal re-evaluation of the original budgeting parameters, feeding into a revised budget for the next cycle.

4. Key Concepts Table

Concept	Explanation	Example	Why It Matters
Architecture migration ladder (Intel → AMD → ARM)	Migrating EC2 compute to progressively cheaper processor architectures	`T3.medium` (Intel) → `T3a.medium` (AMD) → eventually a Graviton (`g`-suffix) family	Often the single highest-leverage, lowest-application-risk cost lever on EC2
Migration blast radius	The scope of potential impact/damage if a change goes wrong	Direct Intel→ARM has a larger blast radius than the safer two-step Intel→AMD→ARM path	Staging risky changes in smaller increments limits how much can go wrong from any single step
Instance management category (standalone / ASG / EKS node group)	The three distinct ways an EC2 instance can be managed, each requiring a different migration procedure	A single manually-created instance (standalone) vs. one deployed inside an ASG vs. one that’s a Kubernetes worker node	Migration difficulty and procedure differ substantially by category — and the difficulty ordering even reverses depending on migration direction
AWS Porting Advisor for Graviton	A scanning tool that checks application dependencies for ARM-architecture compatibility	Scanning a Node.js app’s `package.json` dependencies for architecture-specific code	Prevents blindly migrating to ARM and breaking an application due to an undetected native/architecture-specific dependency
Savings Plan vs. Reserved Instance	Two different AWS commitment-discount mechanisms	Savings Plan = commit to $/hour spend, flexible across instance types; RI = commit to a specific instance type	Savings Plans offer more flexibility; RIs can be cheaper if usage is highly predictable and stable on one instance family
Tagging discipline (Name/Owner/Env/LOB)	A standard tag schema applied to every cloud resource	Tagging an EC2 instance with `Env=prod`, `LOB=payments`	Enables cost attribution, auditing, and automated scripts (like scheduled shutdowns) — described as the single most important prerequisite for cost engineering
Cost-optimization layering (compute → network → data → monitoring → other)	A structured order for tackling cost optimization across a whole cloud account	HealthCorp engagement organized into these five layers	Prevents cost optimization work from being ad hoc; ensures the highest-impact areas get addressed systematically
Baseline period for rightsizing	The historical time window used to judge whether a resource is over/underprovisioned	90 days vs. 365 days depending on business seasonality	A baseline that’s too short can misjudge a resource as “wasteful” when it’s actually provisioned for a legitimate, less-frequent traffic pattern
IaC vs. ClickOps for production changes	Making infrastructure changes via code (Terraform/Ansible/scripts) vs. manually through the console	Migrating 40 production servers via Terraform, not manual console clicks	Preserves auditability and state-file accuracy; manual changes silently break the correspondence between actual infrastructure and its IaC representation
FinOps team vs. application/owner team roles	In multi-account governance, FinOps monitors/reports on cost; the owning application team makes budget decisions	FinOps flags a 50% budget overshoot; the app team decides whether to revise the budget or the resource footprint	Clarifies accountability in enterprise multi-account cost governance — a common point of confusion
ECR → Harbor migration	Replacing AWS’s managed container registry with the open-source Harbor registry	Implemented at HealthCorp to reduce registry cost	A concrete example of substituting a managed AWS service with a self-hosted open-source alternative purely for cost reasons

5. Architecture & Workflow Analysis

5.1 Cost Optimization Layering (HealthCorp Engagement Structure)

HealthCorp AWS Account (~$98K/month, single account, prod+non-prod combined)
        |
        v
   Build Full Inventory (by service, by environment, via tagging)
        |
        v
   -----------------------------------------------------------
   |            |              |              |              |
Compute      Network        Data/Storage   Monitoring     Other Tools
Layer        Layer          Layer          Layer          Layer
   |
   -------------------
   |                 |
Server           Serverless
Computing        Computing
(EC2, EKS,       (Lambda, ECS)
 Lightsail)
   |
   [ THIS SESSION'S FOCUS ]

5.2 Architecture Migration Decision Flow

Start: EC2 instance currently on Intel
        |
        v
Assess application compatibility
   (developer review + AWS Porting Advisor for Graviton scan)
        |
        v
    -------------------------------
    |                              |
No ARM-specific                ARM-specific
dependency found                dependency found
    |                              |
    v                              v
Plan direct or staged          Fix/remove dependency
migration                      OR exclude from ARM migration scope
    |                              |
    -------------------------------
        |
        v
Choose migration path (SAFER = staged):
    Intel -> AMD -> ARM   (smaller blast radius, recommended)
    Intel -> ARM directly (larger blast radius, faster but riskier)
        |
        v
Identify instance management category:
    Standalone | ASG | EKS Node Group
        |
        v
Apply category-specific migration procedure
        |
        v
Monitor 48-72 hrs (or longer per business criticality)
        |
        v
Validate actual $ savings in Cost Explorer
        |
        v
Delete AMI backup after ~1-2 weeks

5.3 Standalone Instance Migration Procedure (Live Demo Sequence)

1. Identify equivalent instance type in target architecture family
        |
2. Create AMI backup (named, described, tagged)
        |
3. WAIT for AMI status = "active"   <-- never skip in production
        |
4. Stop instance
        |
5. Actions -> Instance Settings -> Change Instance Type -> enter new type
        |
6. Start instance
        |
7. Monitor application (48-72 hrs)
        |
8. Verify cost savings in Cost Explorer (filter by instance ID)
        |
9. Delete AMI backup (after monitoring window, ~1-2 weeks)

5.4 Migration Difficulty Reversal (Instance Category × Direction)

                Intel -> AMD              AMD -> ARM
                -----------              -----------
Standalone        EASIEST                  HARDEST
ASG                MEDIUM                   MEDIUM
EKS Node Group    HARDEST                  EASIEST

5.5 Multi-Account FinOps Governance Flow (from Q&A)

Application Team requests new resources
        |
        v
Budget / Capacity / Forecast conversation
   (BEFORE provisioning, not after)
        |
        v
Resources provisioned + Budget alerts/monitoring configured together
        |
        v
        ----------------------------------------
        |                                        |
FinOps Team                              Application/Owner Team
(monitors, reports,                      (decides consumption levels,
 flags deviations)                        owns budget decisions)
        |
        v
Periodic Audit: Actual spend vs. forecast
        |
        v
  Within ~10-20% deviation --> acceptable, no action
  Beyond that (e.g. ~50%) --> re-evaluate original budget parameters
                               --> apply revised budget next cycle

6. Commands & Configurations

This session was primarily console-driven (AWS Management Console UI steps) rather than CLI/scripted, since it was a live teaching demo. Documented below are the concrete configuration steps and identifiers used.

Step / Config	Purpose	Explanation
Instance type comparison: `T3.medium` (Intel) → `T3a.medium` (AMD)	Identify the architecture-equivalent instance type before migrating	`a` suffix = AMD family; no suffix = Intel; `g` suffix = ARM/Graviton family — a naming-convention pattern used throughout the session
Console: Instance → Image and templates → Create image	Create an AMI backup before migration	Must include: descriptive name, description with date/time/purpose, attached volume(s), and full tag set (Name, Owner, Env, LOB)
Console: Instance → Actions → Instance settings → Change instance type	Change the underlying instance type/architecture after stopping the instance	Only usable while the instance is in a stopped state; console displays the price delta immediately upon selecting the new type
AWS Cost Explorer — filter by Instance ID	Validate actual before/after cost impact of a migration	Filter billing data down to the specific instance ID, compare day-over-day cost pre- and post-migration
AWS Pricing Calculator (“Create estimate” workflow)	Compare theoretical cost between architecture families before committing to a migration	Used live to compare `T3.medium` (Intel, On-Demand) vs. `T3a.medium` (AMD, On-Demand) pricing for a given region and instance count
Custom script built on AWS SDK	Programmatically compute cost differences across the full instance inventory (rather than manual one-by-one comparisons in the Pricing Calculator)	Described as producing “a comprehensive list of the cost vector” — the automation layer behind the $935 aggregate savings figure
AWS Porting Advisor for Graviton (installed locally in IDE, or run as a Docker image)	Scan application dependencies for ARM-architecture compatibility issues	Reports specific file/line-level flags where a third-party dependency has an architecture-specific issue that would block ARM migration
Tag schema: `Name`, `Owner`, `Env`, `LOB`	Standard resource tagging applied to every created resource (instances, AMIs, etc.)	Foundational for cost attribution, auditing, and automation scripts (e.g., filtering by `Env=dev` to schedule shutdowns)
EventBridge-triggered shutdown script (hosted on Jenkins or similar, per the discussion)	Automatically stop/start tagged non-prod resources on a schedule	E.g., stop all `Env=dev`-tagged instances at 10 p.m. IST, start at 6 a.m. IST — framed as a cost-conscious alternative to a pure Lambda-based approach

7. Tools & Technologies

AWS Cost Explorer

Purpose: Native AWS cost visualization and analysis tool.
When to use it: The first tool to enable in any AWS cost-optimization engagement — provides the foundational visibility into where spend is going.
Advantages: Free, built-in, granular filtering (including by instance ID, as demonstrated).

AWS Compute Optimizer

Purpose: Provides right-sizing and optimization recommendations across compute resources (EC2, Lambda, and other compute services).
When to use it: Alongside Cost Explorer, as part of the initial optimization-enablement checklist.

AWS Trusted Advisor

Purpose: Broad recommendation engine covering cost, security, performance, service limits, and operational excellence.
When to use it: As a comprehensive periodic health check across multiple dimensions, not just cost.
Limitations: The full recommendation set is a paid AWS capability — a recurring theme when comparing against GCP’s free equivalent, Active Assist.

AWS Cost Anomaly Detection

Purpose: Automated detection and alerting on unusual cost spikes.
When to use it: As a standing safety net once baseline cost patterns are established, to catch unexpected spend increases early.

AWS Pricing Calculator

Purpose: Estimate AWS costs for hypothetical resource configurations before committing to a change.
When to use it: Comparing architecture families (Intel vs. AMD vs. ARM), instance sizes, or entirely new deployments before implementation.

AWS Porting Advisor for Graviton

Purpose: Scans application code/dependencies for ARM (Graviton) architecture compatibility issues.
When to use it: Before any migration to ARM-based instances, to catch dependency-level incompatibilities early.
Advantages: Can run locally in an IDE or as a Docker container against the codebase; provides specific, actionable file/line-level findings.

Harbor

Purpose: Open-source container image registry (an alternative to AWS ECR).
When to use it: As a cost-saving substitute for a managed cloud container registry, when the operational overhead of self-hosting is acceptable.
Note: Actually implemented at HealthCorp as part of this engagement, not just discussed hypothetically.

Terraform / Pulumi / Ansible (production IaC stack, per Q&A discussion)

Purpose: Infrastructure-as-Code tooling for provisioning (Terraform/Pulumi) and configuration management (Ansible), layered with custom Python scripting for orchestration logic where needed.
When to use it: For any production-grade infrastructure change at meaningful scale — explicitly contrasted against manual ClickOps, which breaks auditability and state consistency.
Note: HealthCorp’s actual historical engagement did not use Terraform (ClickOps only) — explicitly acknowledged by the instructor as a deviation from best practice, not the recommended approach going forward.

CastAI / Karpenter / Kubecost (EKS cost tooling, previewed for a future session)

Purpose: Kubernetes-specific cost optimization and autoscaling tools (same tools as previously covered in the FintechPlatform GCP context — being applied here to HealthCorp’s EKS environment).
When to use it: For EKS cost optimization work, planned for the following session, including a comparative analysis of Karpenter alone vs. CastAI alone vs. both together.
Note: A third, similarly-purposed EKS cost tool was referenced by the instructor but the exact name wasn’t confidently captured in the transcript (heard approximately as “studious” or similar) — flagged in Gaps & Assumptions as needing verification.

8. Real-World Production Usage

Architecture migration as a high-leverage, low-drama cost lever: The Intel→AMD→ARM migration ladder is a genuinely strong real-world pattern precisely because — unlike many cost optimizations — it typically requires no application code changes for the majority of workloads (Intel→AMD especially), while still delivering meaningful, compounding savings across a large fleet (170 instances in this case).
The compatibility-check-before-migration discipline is the difference between a clean win and an outage: The emphasis on the AWS Porting Advisor for Graviton, and the deliberate staged Intel→AMD→ARM path (rather than a direct jump), reflects mature, risk-aware production practice — not a shortcut taken for the sake of a demo.
The IaC vs. ClickOps pushback from an experienced participant is a genuinely important real-world correction: it’s a realistic illustration of the gap between “how you’d demo something live for teaching purposes” and “how you’d actually be expected to execute the same change safely at scale in a governed enterprise environment” — and the instructor’s candid acknowledgment that HealthCorp’s actual engagement used ClickOps (not the recommended approach) is a useful, honest data point about how real engagements sometimes deviate from best practice under time/access constraints.
Multi-account FinOps governance (Landing Zone/Control Tower) is standard practice in larger organizations: The clear separation of responsibilities described (FinOps = monitor/report, application team = budget decision-maker) reflects how cost governance is actually structured in enterprises running AWS Organizations with many accounts — a pattern any DevOps/SRE engineer moving into a larger organization should expect to encounter.
Baseline-period selection is a genuinely debated, context-dependent practice — not a fixed rule: The exchange between participants (90 days vs. 365 days vs. “3 months is usually enough paired with ongoing monitoring”) reflects real disagreement/nuance that exists in the industry — there’s no single correct baseline window, and the right answer depends on the specific business’s traffic seasonality and feature-release cadence.
ECR → Harbor is a concrete example of “managed convenience vs. self-hosted cost” trade-off decisions that real DevOps teams make — worth remembering as a live example rather than a hypothetical when this trade-off comes up in other contexts (e.g., the Redis→Valkey and managed-queue-vs-Kafka discussions from the FintechPlatform sessions).

9. Interview Preparation

Beginner Questions

Q1: What’s the difference between Intel, AMD, and ARM/Graviton instance families on AWS, from a cost perspective? A: They represent three cost tiers for the same class of compute — Intel is typically the most expensive, AMD (same x86 family, different manufacturer) is a mid-tier, cost-saving option with broad compatibility, and ARM/Graviton (AWS’s own custom ARM-based processors) is typically the cheapest but requires verifying that the application and its dependencies are actually compatible with the ARM architecture before migrating.

Q2: What is AWS Trusted Advisor, and what categories of recommendations does it provide? A: Trusted Advisor is an AWS tool that scans your account and provides recommendations across five categories: cost optimization, security, performance, service limits (quota monitoring), and operational excellence (AWS best-practices compliance). Its full feature set requires a paid AWS Support plan.

Q3: Why is resource tagging described as foundational to cost optimization work? A: Tags (like Name, Owner, Environment, Line of Business) allow costs to be attributed to the right team/project, enable auditing of who owns what, and make automation possible — for example, a scheduled script can filter and act only on resources tagged with a specific environment (like shutting down everything tagged Env=dev outside business hours).

Intermediate Questions

Q4: Walk through the safe, step-by-step process for migrating a standalone EC2 instance from Intel to AMD in a production environment. A: First identify the equivalent instance type in the AMD family (e.g., T3.medium → T3a.medium). Create and tag an AMI backup, and wait for it to reach “active” status before proceeding — this step should never be skipped in production. Stop the instance, then use “Change Instance Type” to switch to the AMD-family equivalent. Start the instance and monitor application behavior for 48–72 hours (or longer depending on business criticality) to catch any regressions. Validate the actual cost impact in Cost Explorer by filtering on the specific instance ID and comparing pre/post cost. Finally, delete the AMI backup after the monitoring window closes (typically 1–2 weeks later) to avoid unnecessary backup storage cost.

Q5: Why does the recommended migration path go Intel → AMD → ARM instead of directly Intel → ARM? A: Because ARM is architecturally distinct from x86 (unlike AMD, which shares the x86 family with Intel), a direct Intel-to-ARM migration carries more risk of an undetected compatibility issue causing an outage — a larger “blast radius.” Staging the migration through AMD first (a lower-risk, high-compatibility step) isolates any remaining ARM-specific risk into a smaller, more controlled second step, making it easier to identify and roll back if something goes wrong.

Q6: Explain the difference in migration complexity between a standalone EC2 instance, an instance in an Auto Scaling Group, and an EKS node group instance — and why does the difficulty ordering change depending on migration direction? A: These represent three different management models, each requiring different migration mechanics. For Intel→AMD, standalone instances are easiest (simple stop/change-type/start), ASG instances add complexity because you need to update launch templates/configurations that the ASG uses to provision new instances, and EKS node groups are hardest in that direction because you’re coordinating node replacement across a live Kubernetes cluster. For AMD→ARM, this ordering reverses — EKS node groups become easiest (Kubernetes’ native ability to drain and replace nodes with a new node group makes ARM adoption relatively clean), while standalone instances become hardest (no orchestration layer to help manage the cutover safely). This reversal isn’t intuitive and is a genuinely useful piece of hard-won operational knowledge.

Q7: What’s the practical difference between a Savings Plan and a Reserved Instance, and when would you choose one over the other? A: A Reserved Instance commits you to a specific instance type/family in exchange for a discount — best when your usage on that exact instance type is highly predictable and stable. A Savings Plan commits you to a certain dollar-per-hour spend level instead, and that commitment flexibly applies across any instance type that fits within it — better when your workload mix might shift (e.g., you might right-size or migrate architectures later) and you don’t want to be locked into one specific instance family.

Advanced Questions

Q8: A colleague proposes buying AWS’s recommended Savings Plan directly from the console’s default suggestion. What risks would you flag, and what would you do instead? A: The console’s default recommendation doesn’t necessarily reflect your organization’s actual usage patterns, future architecture plans (e.g., an upcoming Intel→AMD→ARM migration that will change your effective hourly cost profile), or risk tolerance for over-committing. Blindly accepting it can lead to either under-covering your usage (missing available savings) or over-committing to a spend level you won’t actually reach, locking in unused capacity cost for the term length. Instead, use a dedicated Savings Plan calculation methodology — model your actual historical and projected usage, account for planned infrastructure changes, and choose payment/term parameters (upfront amount, 1-year vs. 3-year) deliberately based on that analysis rather than the default suggestion.

Q9: How would you design a cost-optimization approach for a client’s EC2 fleet where 116 out of 170 instances are candidates for architecture migration, while ensuring no production risk? A: Start with an inventory categorized by both current architecture and management type (standalone/ASG/EKS node group), since these dictate the migration procedure. Run an application compatibility assessment (developer review + tooling like AWS Porting Advisor for Graviton) to separate instances that are safe for direct ARM migration from those that need the safer Intel→AMD→ARM staged path, and from those that shouldn’t be touched at all due to unresolved dependencies. Prioritize by expected savings and migration simplicity — likely starting with standalone Intel→AMD instances (lowest complexity, immediate savings, minimal blast radius) before tackling ASG and EKS node group migrations. Every migration should follow the backup-first, stop/change/start, monitor-for-a-defined-window, validate-actual-savings, delete-backup-after-window procedure. At production scale, this entire workflow should be codified in Terraform/Ansible/scripting rather than executed manually, to preserve auditability and IaC state accuracy — and any change affecting production should respect an agreed downtime/maintenance window (e.g., HealthCorp’s ~30-minute daily window) rather than being executed ad hoc.

Q10: How should FinOps governance be structured across a multi-account AWS Organization to prevent runaway costs, without making the FinOps team a bottleneck for every provisioning decision? A: Structure it so budget/capacity/forecast conversations happen at the point an application team requests new resources — before provisioning, not after — with budget alerts and monitoring configured as part of that same provisioning step, not retrofitted later. The FinOps team’s role should be centered on monitoring, reporting, and flagging deviations (using tools like AWS Budgets and Service Quotas across accounts), while the actual consumption/budget decisions remain with the application/owner team, since they understand the real business need driving that consumption. Establish a tolerance band (a commonly cited rule of thumb is roughly ±10–20% deviation from forecast being acceptable) so minor, expected fluctuation doesn’t trigger unnecessary friction — but deviations well beyond that band (e.g., ±50%) should trigger a structured re-evaluation of the original budgeting assumptions, feeding into a revised forecast for the next cycle, rather than either being ignored or requiring FinOps to approve every individual resource change.

10. Exam & Certification Notes

(Relevant primarily to AWS Certified Solutions Architect, SysOps Administrator, and DevOps Engineer certifications, plus FinOps Certified Practitioner-adjacent content.)

Instance family naming conventions: Know that AWS instance family suffixes indicate processor architecture — no letter suffix generally implies Intel, a indicates AMD, and g indicates Graviton (ARM) — a frequently tested pattern for identifying architecture from an instance type string alone (e.g., m5 = Intel, m5a = AMD, m6g = Graviton).
Savings Plans vs. Reserved Instances: A very commonly tested distinction — Savings Plans commit to a spend level with flexible instance-type application; RIs commit to a specific instance configuration. Also know that Savings Plans apply only to On-Demand usage, not Spot.
Spot Instances: Remember the core exam fact reinforced in this session — Spot instances can be reclaimed by AWS with short notice and should never be the sole compute for production-critical, availability-sensitive workloads.
Trusted Advisor categories: Cost Optimization, Performance, Security, Fault Tolerance (not explicitly named in this transcript but standard on the exam), Service Limits, and Operational Excellence — a common exam question format asks you to match a specific recommendation to its Trusted Advisor category.
AMI creation requires a “pending” → “available” (or “active,” per this session’s informal terminology) status transition before it can be reliably used — exams sometimes test understanding that an AMI isn’t immediately usable the instant creation is initiated.
Changing an EC2 instance type requires the instance to be stopped first — a frequently tested operational fact (you cannot hot-swap instance type on a running instance).
AWS Graviton / ARM migration tooling: Know that AWS provides purpose-built tooling (like the Porting Advisor for Graviton) specifically to assess ARM compatibility — this is increasingly relevant on newer exam versions given AWS’s push toward Graviton adoption for cost/efficiency reasons.

11. Cheat Sheet

Architecture Cost Tiers (most → least expensive): Intel → AMD → ARM/Graviton

Safe Migration Path: Intel → AMD → ARM (staged, smaller blast radius) — preferred over direct Intel → ARM

Instance Category Migration Difficulty (memorize the reversal):

	Intel→AMD	AMD→ARM
Standalone	Easiest	Hardest
ASG	Medium	Medium
EKS Node Group	Hardest	Easiest

Standalone Migration — 9 Steps:

Identify equivalent instance type
Create AMI backup (tagged, named, described)
Wait for AMI “active” status
Stop instance
Change instance type
Start instance
Monitor 48–72 hrs
Validate savings in Cost Explorer
Delete AMI backup after ~1–2 weeks

Mandatory Tag Set: Name · Owner · Env · LOB

AWS Cost Tooling Enablement Checklist (in order):

Cost Explorer
Compute Optimizer
Trusted Advisor (paid)
Cost Anomaly Detection

Cost Optimization Layers (in typical order): Compute (server + serverless) → Network → Data/Storage → Monitoring → Other Tools

Savings Plan Reality Check:

Not tied to instance type (unlike RIs)
Doesn’t apply to Spot
Never accept the console’s default recommendation blindly — model actual usage first
3-year, all-upfront = deepest discount, but least flexible

FinOps Roles:

FinOps team = monitor, report, flag deviations
Application/owner team = budget decision-maker
Tolerance band ≈ ±10–20% before triggering re-evaluation

12. Gaps & Assumptions

Third EKS cost-optimization tool name uncertain: The instructor mentioned a tool similar to CastAI (heard approximately as “studious” or similar) that offers fewer features than CastAI — the exact tool name could not be confidently identified from the transcript audio. Flagged for direct verification before relying on it.
”Intel and AMD share the x86 architecture, AMD is 64-bit” — an imprecise simplification from the live Q&A: In reality, both modern Intel and AMD processors commonly used on AWS EC2 are x86-64 (64-bit x86 architecture) — the “64-bit” distinction isn’t actually what separates Intel from AMD instance families on AWS. The real practical distinction driving the cost difference is different silicon/manufacturer and AWS’s differentiated pricing, not the bit-width. This document preserves what was said live but flags it here as a simplification not to repeat verbatim in a technical interview or exam context.
Exact instance type equivalence logic: The session referenced “a sheet” mapping instance types to their cross-architecture equivalents, but did not fully dictate the underlying logic/rules for determining equivalence beyond the one worked example (T3.medium ↔ T3a.medium). Treat the general naming-convention pattern (no suffix / a / g) as reliable, but verify specific family-to-family equivalence against current AWS documentation rather than assuming a simple suffix swap always works for every family.
HealthCorp’s precise current status: The 80% cost reduction figure was described as a historical, already-completed achievement from a prior engagement (the instructor no longer has live access to HealthCorp’s actual infrastructure) — the “live” HealthCorp content in this session and future sessions is a replicated playground environment, not the actual client’s current infrastructure. This is an important distinction from the FintechPlatform engagement, which is genuinely live. Don’t conflate the two — HealthCorp is a project call (retrospective/replicated), FintechPlatform is a shadowing call (live/current).
AWS account suspension incident: Referenced as previously resolved in this session, but the underlying incident details (what commands were run, by whom) were not covered in this transcript — only that it happened and was addressed. Full details would need to be pulled from the earlier session where it originally occurred.
Downtime window figure (~30 minutes daily) applies specifically to HealthCorp, based on a Q&A answer — not necessarily generalizable to other clients’ constraints (compare to FintechPlatform’s ~30–60 minute Saturday-only window from the earlier shadowing sessions in this series, which is a different, client-specific constraint).
Program-structure disagreement left unresolved: Several participants raised a structural concern about the curriculum sequencing (jumping into advanced real-client architecture before covering basic reference architectures/CI-CD patterns for each cloud). The instructor deferred this to an off-call discussion — this document notes it accurately as an open, unresolved item rather than assuming an outcome.
This document consolidates a long, interruption-heavy live session (extended Q&A interspersed throughout, a mid-session break) — content has been reorganized topically for clarity rather than presented in strict chronological order, consistent with the approach used for prior packages in this series.