{"id":780,"date":"2026-03-25T06:41:34","date_gmt":"2026-03-25T06:41:34","guid":{"rendered":"https:\/\/cloudfirst.in\/insight\/?p=780"},"modified":"2026-03-26T06:57:50","modified_gmt":"2026-03-26T06:57:50","slug":"aws-well-architected-framework-a-pillar-by-pillar-audit-guide-for-indian-enterprises","status":"publish","type":"post","link":"https:\/\/cloudfirst.in\/insight\/aws-well-architected-framework-a-pillar-by-pillar-audit-guide-for-indian-enterprises\/","title":{"rendered":"AWS Well-Architected Framework: A Pillar-by-Pillar Audit Guide for Indian Enterprises"},"content":{"rendered":"\n

Every AWS<\/a> partner sells Well-Architected Reviews. Few explain what they actually surface \u2014 and fewer still explain what the findings mean in the specific context of an Indian enterprise, where regulatory requirements, attrition dynamics, and the characteristics of AWS India regions create a distinct risk profile.<\/p>\n\n\n\n

The AWS Well-Architected Framework is a structured set of best practices across six pillars: Operational Excellence, Security, Reliability, Performance Efficiency, Cost Optimization, and Sustainability. A Well-Architected Review (WAR) uses the framework to evaluate your AWS workloads against these pillars, producing a prioritised list of High Risk Issues (HRIs) and Medium Risk Issues (MRIs).<\/p>\n\n\n\n

This guide does two things. First, it explains what each pillar actually evaluates \u2014 in practical terms, not AWS documentation language. Second, for each pillar it identifies the High Risk Issues most commonly found in Indian enterprise environments, the India-specific compliance and operational context that shapes those risks, and the priority actions to address them.<\/p>\n\n\n\n

If you are preparing for a Well-Architected Review, have received a WAR report and are trying to prioritise remediation, or are an IT leader who wants to understand what ‘Well-Architected’ actually means for your environment, this guide is written for you.<\/p>\n\n\n\n

A note on the AWS Well-Architected Tool: <\/strong>The AWS Well-Architected Tool is available at no cost in the AWS Management Console (AWS Console \u2192 Well-Architected Tool). You can run a self-assessment against all six pillars without engaging a partner. However, partner-led reviews consistently surface more findings \u2014 certified reviewers bring cross-industry pattern recognition that self-assessments anchored to internal assumptions tend to miss.<\/p>\n\n\n\n

Understanding High Risk Issues (HRIs)<\/h2>\n\n\n\n

The AWS Well-Architected Tool categorises findings into three tiers: High Risk Issues (HRIs), Medium Risk Issues (MRIs), and best practice improvements. HRIs are the critical findings \u2014 architectural or operational choices that may cause significant negative business impact. AWS defines them as foundational, must-do practices within each pillar.<\/p>\n\n\n\n

In practice, an HRI means: if this is not addressed, you are operating with a known, material risk to your business. Not a theoretical risk \u2014 a risk that has caused incidents, breaches, or significant cost overruns in environments similar to yours.<\/p>\n\n\n\n

The most common HRIs across Indian enterprise AWS environments \u2014 based on pattern data from reviews conducted in the ap-south-1 (Mumbai) and ap-south-2 (Hyderabad) regions \u2014 cluster in three pillars: Security, Reliability, and Cost Optimization.<\/strong> These are the areas where the gap between intended architecture and actual deployed state is largest, and where the India-specific context \u2014 DPDP Act, CERT-In, data residency, currency risk \u2014 adds additional dimensions.<\/p>\n\n\n\n

Pillar 1: Operational Excellence<\/h2>\n\n\n\n

The Operational Excellence pillar evaluates how well you run and monitor your workloads, respond to operational events, and continuously improve your processes. The core principle is that everything operational \u2014 deployments, incident response, runbooks, monitoring \u2014 should be defined as code and subject to the same discipline as application code.<\/p>\n\n\n\n

What the Pillar Evaluates<\/h3>\n\n\n\n
    \n
  • Whether workloads are deployed using Infrastructure as Code (IaC) rather than manual console actions.<\/li>\n\n\n\n
  • Whether runbooks exist for common operational scenarios \u2014 and whether they are tested and current.<\/li>\n\n\n\n
  • Whether changes are made frequently, in small increments, and are reversible \u2014 rather than large, infrequent, high-risk deployments.<\/li>\n\n\n\n
  • Whether operational metrics are defined and monitored \u2014 not just infrastructure metrics, but business and application-level indicators.<\/li>\n\n\n\n
  • Whether post-incident reviews are conducted and learnings are actually implemented.<\/li>\n<\/ul>\n\n\n\n

    Most Common HRIs in Indian Enterprise Environments<\/h3>\n\n\n\n

    HRI: <\/strong>No IaC for production infrastructure. Manual provisioning is widespread in Indian enterprise AWS deployments, particularly in environments that migrated from on-premise without a cloud-native rebuild. Resources provisioned through the console drift from intended state, cannot be audited or version-controlled, and create knowledge concentration risk when the engineer who built them leaves.<\/p>\n\n\n\n

    HRI: <\/strong>No documented, tested runbooks. Most Indian enterprises have undocumented operational knowledge \u2014 the equivalent of ‘ask Rajan, he knows how to restart the service.’ When Rajan leaves, the knowledge goes with him. WAR reviews consistently flag the absence of structured runbooks as a high-risk operational gap.<\/p>\n\n\n\n

    HRI: <\/strong>Deployments are infrequent and large. Batching changes into monthly or quarterly releases is common in Indian enterprises with legacy governance models. Each release is a high-risk event. The framework’s design principle of frequent, small, reversible changes reduces blast radius significantly.<\/p>\n\n\n\n

    \ud83c\uddee\ud83c\uddf3  India Context: <\/strong>India’s IT attrition rate makes the IaC and runbook gaps especially acute. An environment that relies on one senior engineer’s undocumented knowledge is one resignation away from an operational crisis. IaC and runbooks are not just best practice \u2014 in the Indian context, they are business continuity controls.<\/em><\/p>\n\n\n\n

    Key review questions:<\/strong><\/p>\n\n\n\n

      \n
    • Is all production infrastructure defined in Terraform, CloudFormation, or CDK \u2014 with no manually provisioned resources?<\/li>\n\n\n\n
    • Do runbooks exist for your top five incident scenarios? When were they last tested?<\/li>\n\n\n\n
    • How many deployments did you make to production in the last 30 days? Can each one be individually rolled back?<\/li>\n\n\n\n
    • What is the mean time to recovery (MTTR) for your most recent five P1 incidents?<\/li>\n<\/ul>\n\n\n\n

      Priority actions:<\/strong><\/p>\n\n\n\n

        \n
      • Audit all production resources for IaC coverage. Any resource not managed by IaC should be imported or rebuilt. Use AWS Config to detect configuration drift.<\/li>\n\n\n\n
      • Create runbooks for: database failover, certificate expiry, auto-scaling incidents, deployment rollback, and security alert response. Store in a wiki with version history.<\/li>\n\n\n\n
      • Implement CI\/CD pipelines for all production deployments. No manual console changes to production \u2014 ever.<\/li>\n<\/ul>\n\n\n\n

        Pillar 2: Security<\/h2>\n\n\n\n

        The Security pillar is consistently the highest-density source of HRIs in Indian enterprise AWS environments. It evaluates identity and access management, data protection, infrastructure security, detection capabilities, and incident response readiness. In the Indian context, the DPDP Act and CERT-In compliance requirements add regulatory weight to findings that would otherwise be treated as technical best practices.<\/p>\n\n\n\n

        What the Pillar Evaluates<\/h3>\n\n\n\n
          \n
        • Whether IAM follows least-privilege principles \u2014 no overpermissioned roles, no root account usage, no long-lived access keys.<\/li>\n\n\n\n
        • Whether all data at rest and in transit is encrypted \u2014 S3, EBS, RDS, and all data transfer between services.<\/li>\n\n\n\n
        • Whether detection capabilities are active \u2014 GuardDuty, Security Hub, CloudTrail, and Config enabled across all accounts.<\/li>\n\n\n\n
        • Whether a documented incident response plan exists and has been tested.<\/li>\n\n\n\n
        • Whether network security is layered \u2014 VPC design, security groups, NACLs, and WAF where applicable.<\/li>\n<\/ul>\n\n\n\n

          Most Common HRIs in Indian Enterprise Environments<\/h3>\n\n\n\n

          HRI: <\/strong>Root account used for day-to-day operations. The AWS root account has unrestricted access to every service and cannot be restricted by IAM policies. Using it for routine tasks is one of the highest-risk configurations in any AWS environment. It is also one of the most common findings in Indian enterprise reviews, particularly in accounts that were set up without formal cloud governance.<\/p>\n\n\n\n

          HRI: <\/strong>No MFA on IAM users and root account. Long-lived IAM user credentials without MFA are a primary attack vector. Combined with root account access, this is the configuration that leads to the most severe account compromises.<\/p>\n\n\n\n

          HRI: <\/strong>GuardDuty disabled or alerts not reviewed. GuardDuty is AWS’s managed threat detection service. It is not enabled by default. In a majority of Indian enterprise reviews, GuardDuty is either disabled or enabled but with no process for reviewing and responding to findings.<\/p>\n\n\n\n

          HRI: <\/strong>S3 buckets with public access not explicitly blocked. Despite S3 Block Public Access being available at the account level, many Indian enterprise environments have buckets \u2014 often created by application teams without central oversight \u2014 with public access enabled. This is a recurring source of data exposure incidents.<\/p>\n\n\n\n

          HRI: <\/strong>No encryption at rest on RDS and EBS. Encryption at rest is not enabled by default on RDS instances or EBS volumes. Many Indian enterprise environments migrated from on-premise with encryption disabled, and enabling it on existing resources requires snapshot-and-restore \u2014 a non-trivial operation that is frequently deferred indefinitely.<\/p>\n\n\n\n

          India Context: <\/strong>The DPDP Act classifies failure to implement reasonable security safeguards as a penalty-eligible contravention, with fines up to \u20b9250 crore per contravention. CERT-In mandates 6-hour incident reporting and 180-day log retention. Security pillar HRIs in an Indian enterprise context are not just technical debt \u2014 they are regulatory exposure. GuardDuty disabled, CloudTrail not retained for 180 days, and no incident response plan are three findings that map directly onto CERT-In compliance gaps.<\/em><\/p>\n\n\n\n

          Key review questions:<\/strong><\/p>\n\n\n\n

            \n
          • When did someone last log into the AWS root account? Is MFA enabled on it?<\/li>\n\n\n\n
          • Are all IAM users using MFA? Are any IAM users still using long-lived access keys instead of IAM roles?<\/li>\n\n\n\n
          • Is GuardDuty enabled in every region, including regions where you have no active workloads? Is there a process for responding to findings?<\/li>\n\n\n\n
          • Is S3 Block Public Access enabled at the account level across all AWS accounts?<\/li>\n\n\n\n
          • Is CloudTrail enabled in all regions, with logs retained for at least 180 days? Is there a log integrity validation process?<\/li>\n\n\n\n
          • Has your incident response plan been tested in the last 12 months?<\/li>\n<\/ul>\n\n\n\n

            Priority actions:<\/strong><\/p>\n\n\n\n

              \n
            • Enable MFA on the root account immediately and lock it away \u2014 use a hardware key, store credentials in a vault, and treat root login as an extraordinary event requiring dual approval.<\/li>\n\n\n\n
            • Enable GuardDuty in all regions and all accounts in your AWS Organisation. Configure findings to route to Security Hub for centralised visibility. Assign a named owner for weekly findings review.<\/li>\n\n\n\n
            • Enable S3 Block Public Access at the account level via AWS Organisations. Audit all existing buckets for public access and remediate.<\/li>\n\n\n\n
            • Enable default encryption on all new S3 buckets, EBS volumes, and RDS instances. Plan a snapshot-and-restore cycle to encrypt existing unencrypted RDS instances.<\/li>\n\n\n\n
            • Ensure CloudTrail is enabled in all regions with 180-day log retention and log file validation enabled. This is your CERT-In compliance baseline.<\/li>\n<\/ul>\n\n\n\n

              Pillar 3: Reliability<\/h2>\n\n\n\n

              The Reliability pillar evaluates how well your workloads perform their intended function, recover from failures, and dynamically meet demand. It is the pillar most directly connected to business uptime \u2014 and the one where the gap between ‘designed for’ and ‘actually tested’ is largest in most Indian enterprise environments.<\/p>\n\n\n\n

              What the Pillar Evaluates<\/h3>\n\n\n\n
                \n
              • Whether workloads are designed to withstand component failures without service interruption.<\/li>\n\n\n\n
              • Whether databases and critical services are deployed across multiple Availability Zones.<\/li>\n\n\n\n
              • Whether backup and recovery procedures exist, are automated, and are actually tested.<\/li>\n\n\n\n
              • Whether the architecture can scale automatically to meet demand spikes.<\/li>\n\n\n\n
              • Whether service limits and quotas are monitored and managed proactively.<\/li>\n<\/ul>\n\n\n\n

                Most Common HRIs in Indian Enterprise Environments<\/h3>\n\n\n\n

                HRI: <\/strong>Single-AZ database deployment. Deploying RDS instances in a single Availability Zone is one of the most common reliability HRIs in Indian enterprise reviews. A single-AZ RDS instance has no automatic failover \u2014 a hardware failure or AZ outage takes down the database until manual recovery is complete, which typically takes 15\u201330 minutes at minimum. Multi-AZ deployment is a single checkbox that eliminates this risk.<\/p>\n\n\n\n

                HRI: <\/strong>Backups never tested. Most Indian enterprises have backup policies configured. Very few have ever successfully restored from a backup in a test environment. Backups that have never been tested are backups you cannot trust. The framework treats untested backups as a high-risk gap \u2014 not because backups are missing, but because recovery capability is unproven.<\/p>\n\n\n\n

                HRI: <\/strong>No auto-scaling for variable workloads. Indian e-commerce, BFSI, and SaaS environments frequently experience significant traffic variability \u2014 seasonal peaks, marketing campaigns, end-of-month processing. Without auto-scaling, these events either cause performance degradation or require manual intervention that is slow, error-prone, and often too late.<\/p>\n\n\n\n

                HRI: <\/strong>Single region for all workloads. Most Indian enterprise environments run entirely in ap-south-1 (Mumbai). A region-level disruption \u2014 rare but not impossible, as the October 2024 AWS outage demonstrated \u2014 takes down all workloads simultaneously. For tier-1 applications, multi-region or at minimum cross-region backup is a reliability requirement.<\/p>\n\n\n\n

                India Context: <\/strong>The ap-south-1 (Mumbai) region has three Availability Zones, making Multi-AZ deployment fully supported. The ap-south-2 (Hyderabad) region, launched in 2022, provides a second India region for cross-region redundancy for organisations with data residency requirements that preclude international regions. For Indian enterprises with DPDP Act obligations around data localisation, ap-south-2 as a DR region is the natural architecture choice.<\/em><\/p>\n\n\n\n

                Key review questions:<\/strong><\/p>\n\n\n\n

                  \n
                • Are all production RDS instances deployed in Multi-AZ configuration?<\/li>\n\n\n\n
                • When did you last successfully restore from a backup? Is there a scheduled restore test in your calendar?<\/li>\n\n\n\n
                • What is your documented RTO and RPO for each tier-1 application? Have these been validated in a real or simulated recovery?<\/li>\n\n\n\n
                • Do your critical applications have auto-scaling configured? What is the maximum scale-out capacity, and has it been load-tested?<\/li>\n\n\n\n
                • Is there a DR plan that uses ap-south-2 or another region as a recovery target?<\/li>\n<\/ul>\n\n\n\n

                  Priority actions:<\/strong><\/p>\n\n\n\n

                    \n
                  • Enable Multi-AZ on all production RDS instances immediately. For large databases where the conversion causes downtime, schedule a maintenance window. This is non-negotiable for tier-1 workloads.<\/li>\n\n\n\n
                  • Schedule monthly backup restore tests for all critical databases and file stores. Run them in a separate test account to avoid production impact. Document the results.<\/li>\n\n\n\n
                  • Implement Application Auto Scaling for EC2, ECS, and Lambda where variable load is expected. Set scale-in and scale-out policies based on CloudWatch metrics, not manual observation.<\/li>\n\n\n\n
                  • Define RTO and RPO targets for each application tier and build recovery procedures that meet them. Test annually with an actual failover drill.<\/li>\n<\/ul>\n\n\n\n

                    Pillar 4: Performance Efficiency<\/h2>\n\n\n\n

                    The Performance Efficiency pillar evaluates how efficiently you use AWS resources to meet your performance requirements \u2014 and whether you are using the right resource types for your workloads. It is less likely to produce HRIs than Security or Reliability, but frequently surfaces significant cost and performance waste through over-provisioning and poor resource selection.<\/p>\n\n\n\n

                    What the Pillar Evaluates<\/h3>\n\n\n\n
                      \n
                    • Whether the right instance types and sizes are selected for each workload \u2014 including whether newer, more efficient generations are being used.<\/li>\n\n\n\n
                    • Whether caching is implemented to reduce load on downstream services and databases.<\/li>\n\n\n\n
                    • Whether serverless or managed services are used where they are more efficient than self-managed infrastructure.<\/li>\n\n\n\n
                    • Whether performance metrics are tracked, baselines are established, and degradation is detected proactively.<\/li>\n\n\n\n
                    • Whether the architecture evolves as AWS releases new services and instance types.<\/li>\n<\/ul>\n\n\n\n

                      Most Common Findings in Indian Enterprise Environments<\/h3>\n\n\n\n

                      HRI: <\/strong>Outdated instance families still in use. AWS regularly releases new instance generations with better price-performance. M5 instances replaced M4. M6i and M7i followed. Many Indian enterprise environments migrated from on-premise onto a specific instance type and never revisited the choice. Running M4 or C4 instances when M7i or C7i offers 20\u201340% better price-performance is a cost and performance gap simultaneously.<\/p>\n\n\n\n

                      HRI: <\/strong>No caching layer for read-heavy workloads. Applications that query a relational database for the same data repeatedly \u2014 product catalogues, configuration data, user session state \u2014 are common in Indian enterprise environments. Without ElastiCache or a comparable caching layer, these queries hit the database on every request, limiting scalability and increasing RDS cost.<\/p>\n\n\n\n

                      India Context: <\/strong>AWS Graviton-based instances (m7g, c7g, r7g) offer up to 40% better price-performance than equivalent x86 instances for supported workloads. Graviton adoption in Indian enterprises has been slow due to application compatibility concerns \u2014 many legacy Java and .NET applications require testing before migration. However, for containerised workloads and modern applications, Graviton is a significant cost and performance lever that most Indian enterprise WAR reviews identify as an unrealised opportunity.<\/em><\/p>\n\n\n\n

                      Key review questions:<\/strong><\/p>\n\n\n\n

                        \n
                      • What EC2 instance families are you running? Are any older than two generations (e.g., M4, C4, R4)?<\/li>\n\n\n\n
                      • Has AWS Compute Optimizer been enabled? What are its top rightsizing recommendations, and why have they not been acted on?<\/li>\n\n\n\n
                      • Do your read-heavy database workloads use a caching layer? What is the cache hit rate?<\/li>\n\n\n\n
                      • Are any workloads candidates for serverless (Lambda, Fargate) that are currently running on always-on EC2?<\/li>\n<\/ul>\n\n\n\n

                        Priority actions:<\/strong><\/p>\n\n\n\n

                          \n
                        • Enable AWS Compute Optimizer across all accounts. Review its recommendations monthly and implement rightsizing in non-production environments first to validate before production rollout.<\/li>\n\n\n\n
                        • Identify workloads running on pre-2020 instance families and plan migration to current-generation equivalents. Prioritise by size \u2014 large instances generate the largest savings.<\/li>\n\n\n\n
                        • Evaluate ElastiCache for your three most query-intensive database workloads. Even modest cache hit rates of 60\u201370% can halve database load and significantly reduce RDS instance size requirements.<\/li>\n\n\n\n
                        • Test Graviton-based instances for containerised workloads in a staging environment. For compatible workloads, the migration is typically low-risk and delivers 20\u201340% cost reduction.<\/li>\n<\/ul>\n\n\n\n

                          Pillar 5: Cost Optimization<\/h2>\n\n\n\n

                          The Cost Optimization pillar evaluates whether you are paying for what you use, using what you pay for, and making intentional pricing decisions. It is the pillar where WAR reviews most reliably identify immediate, quantifiable savings \u2014 typically 15\u201325% of AWS spend \u2014 in Indian enterprise environments that have been running without structured FinOps practices.<\/p>\n\n\n\n

                          What the Pillar Evaluates<\/h3>\n\n\n\n
                            \n
                          • Whether cloud financial management is owned by a named individual or team \u2014 not just the finance department reviewing invoices.<\/li>\n\n\n\n
                          • Whether Reserved Instances or Savings Plans are used for predictable workloads.<\/li>\n\n\n\n
                          • Whether tagging is implemented consistently enough to support cost allocation and accountability.<\/li>\n\n\n\n
                          • Whether idle and over-provisioned resources are identified and addressed regularly.<\/li>\n\n\n\n
                          • Whether cost anomaly detection is configured and alerts are acted on.<\/li>\n<\/ul>\n\n\n\n

                            Most Common HRIs in Indian Enterprise Environments<\/h3>\n\n\n\n

                            HRI: <\/strong>No Reserved Instance or Savings Plan coverage for predictable workloads. On-demand pricing is 30\u201340% more expensive than equivalent 1-year Reserved Instance pricing. Indian enterprise environments running consistent baseline workloads entirely on On-Demand are paying a significant premium. WAR reviews consistently identify this as the single largest recoverable cost gap.<\/p>\n\n\n\n

                            HRI: <\/strong>Zombie resources accumulating without review. DMS instances running months after migrations are complete. EC2 instances in stopped state but with EBS volumes still attached and billed. Unused Elastic IP addresses. Unattached EBS volumes. Load balancers with no registered targets. These resources generate cost silently. A review at one Indian enterprise found over 40 unattached EBS volumes totalling 12TB of storage \u2014 approximately \u20b980,000 per month of unnecessary spend.<\/p>\n\n\n\n

                            HRI: <\/strong>No cost anomaly detection. Cost overruns discovered at month-end rather than when they start occurring is a consistent finding. AWS Cost Anomaly Detection identifies spend patterns deviating from baseline within hours and sends alerts. It is not enabled by default.<\/p>\n\n\n\n

                            India Context: <\/strong>For Indian enterprises, AWS Reserved Instances and Savings Plans are purchased in USD. This creates a currency risk dynamic \u2014 a commitment made when USD\/INR is at 83 may be significantly more expensive in INR terms if the rupee weakens. Organisations should factor currency exposure into RI purchasing decisions, particularly for large 3-year commitments. Monthly RI purchases (convertible, 1-month) reduce commitment risk while still delivering approximately 10\u201315% discount versus On-Demand.<\/em><\/p>\n\n\n\n

                            Key review questions:<\/strong><\/p>\n\n\n\n

                              \n
                            • What is your current Reserved Instance and Savings Plan coverage rate? What percentage of your compute spend is On-Demand?<\/li>\n\n\n\n
                            • When did you last audit for zombie resources? How many stopped EC2 instances, unattached EBS volumes, and unused Elastic IPs are in your environment?<\/li>\n\n\n\n
                            • Is AWS Cost Anomaly Detection configured? When did it last generate an alert, and what was done with it?<\/li>\n\n\n\n
                            • Can you allocate 100% of your AWS spend to a business unit, team, or project using tags? If not, what percentage is unallocated?<\/li>\n<\/ul>\n\n\n\n

                              Priority actions:<\/strong><\/p>\n\n\n\n

                                \n
                              • Enable AWS Cost Anomaly Detection immediately. Configure alerts to route to the cloud owner’s email and your operations Slack channel. Set thresholds appropriate to your spend level.<\/li>\n\n\n\n
                              • Run an AWS Trusted Advisor cost optimisation check and a Compute Optimizer rightsizing report. Treat the outputs as a mandatory review agenda item, not optional recommendations.<\/li>\n\n\n\n
                              • Audit for zombie resources monthly: stopped EC2 instances older than 7 days, unattached EBS volumes, unused Elastic IPs, idle load balancers, and forgotten RDS snapshots.<\/li>\n\n\n\n
                              • Purchase 1-year Savings Plans for your stable baseline compute. Start with Compute Savings Plans (more flexible than EC2 Reserved Instances) at 50\u201360% coverage of your baseline, then increase based on utilisation data.<\/li>\n<\/ul>\n\n\n\n

                                Pillar 6: Sustainability<\/h2>\n\n\n\n

                                The Sustainability pillar \u2014 added to the framework in 2021 \u2014 evaluates the environmental impact of your cloud workloads and whether you are minimising energy consumption and resource waste. It is the newest pillar and the least likely to generate HRIs in the traditional sense, but it is increasingly relevant for Indian enterprises with ESG reporting obligations or sustainability commitments.<\/p>\n\n\n\n

                                What the Pillar Evaluates<\/h3>\n\n\n\n
                                  \n
                                • Whether resources are appropriately sized to avoid idle capacity \u2014 which wastes energy as well as money.<\/li>\n\n\n\n
                                • Whether Graviton-based instances are used where appropriate \u2014 AWS Graviton uses up to 60% less energy than comparable x86 instances for the same performance.<\/li>\n\n\n\n
                                • Whether development and test environments are shut down outside business hours.<\/li>\n\n\n\n
                                • Whether data lifecycle policies are in place to move infrequently accessed data to lower-energy storage tiers.<\/li>\n\n\n\n
                                • Whether serverless and managed services are preferred where they eliminate the need for always-on infrastructure.<\/li>\n<\/ul>\n\n\n\n

                                  Key Findings in Indian Enterprise Environments<\/h3>\n\n\n\n

                                  HRI: <\/strong>Development environments running 24\/7. In most Indian enterprises, development, staging, and QA environments run continuously \u2014 even though developers work roughly 10 hours a day, 5 days a week. Shutting down non-production environments outside business hours reduces both energy consumption and cost by 60\u201370% for those resources.<\/p>\n\n\n\n

                                  India Context: <\/strong>India’s commitment to net-zero by 2070 and the growing ESG reporting requirements for listed companies under SEBI’s BRSR framework are increasing the relevance of sustainability metrics in Indian enterprises. AWS’s Customer Carbon Footprint Tool, available in the Billing Console, provides emissions data by service and region that can be used for BRSR sustainability reporting. AWS India regions are powered increasingly by renewable energy sources \u2014 a factor in AWS’s India sustainability commitments.<\/em><\/p>\n\n\n\n

                                  Key review questions:<\/strong><\/p>\n\n\n\n

                                    \n
                                  • Do development and test environments have scheduled start\/stop policies? What is their utilisation rate outside business hours?<\/li>\n\n\n\n
                                  • Is S3 Intelligent-Tiering or lifecycle policy configured to move infrequently accessed objects to lower-energy storage classes?<\/li>\n\n\n\n
                                  • Have you reviewed the AWS Customer Carbon Footprint Tool? What are your emissions by region and service?<\/li>\n<\/ul>\n\n\n\n

                                    Priority actions:<\/strong><\/p>\n\n\n\n

                                      \n
                                    • Implement AWS Instance Scheduler to automatically stop development and test EC2 instances and RDS clusters outside business hours. This delivers 60\u201370% cost reduction for those resources with zero architecture change.<\/li>\n\n\n\n
                                    • Configure S3 lifecycle policies to transition objects older than 90 days to S3 Intelligent-Tiering, and objects older than 365 days to S3 Glacier Instant Retrieval.<\/li>\n\n\n\n
                                    • Review the AWS Customer Carbon Footprint Tool and include emissions data in your annual ESG or sustainability report.<\/li>\n<\/ul>\n\n\n\n

                                      How to Run a Well-Architected Review: A Practical Process<\/h2>\n\n\n\n

                                      The AWS Well-Architected Tool walks you through the review process workload by workload. Here is the recommended process for Indian enterprises running their first formal review.<\/p>\n\n\n\n

                                      Step 1: Scope the review<\/h3>\n\n\n\n

                                      Do not attempt to review your entire AWS environment at once. Start with your most critical production workload \u2014 the one where an outage or breach would cause the most business impact. A focused review of one workload takes 2\u20133 days. A broad review covering multiple workloads takes 1\u20133 weeks.<\/p>\n\n\n\n

                                        \n
                                      • Identify your tier-1 workload: the application that generates the most revenue or serves the most users.<\/li>\n\n\n\n
                                      • Assemble the right team: cloud architect or lead engineer, security contact, application owner, and ideally a finance or FinOps stakeholder.<\/li>\n\n\n\n
                                      • Gather the artefacts you will need: architecture diagrams, IaC code, IAM policy documentation, monitoring dashboards, and incident history.<\/li>\n<\/ul>\n\n\n\n

                                        Step 2: Run the assessment<\/h3>\n\n\n\n
                                          \n
                                        • Open the AWS Well-Architected Tool in the AWS Console and create a workload.<\/li>\n\n\n\n
                                        • Work through the questions pillar by pillar \u2014 answer based on how the environment is actually configured, not how it was designed on paper.<\/li>\n\n\n\n
                                        • For each question, mark risk level and add notes capturing the specific gap or the rationale for accepted risk.<\/li>\n\n\n\n
                                        • Do not try to answer the questions from memory alone. Pull up the actual AWS Console, IAM policies, and CloudTrail logs as you go.<\/li>\n<\/ul>\n\n\n\n

                                          Step 3: Prioritise findings<\/h3>\n\n\n\n

                                          The tool generates a report categorising findings as HRIs and MRIs. Not all HRIs are equal \u2014 prioritise based on business impact, not just risk category.<\/p>\n\n\n\n

                                            \n
                                          • Rank HRIs by: likelihood of occurrence, blast radius if it does occur, and effort to remediate.<\/li>\n\n\n\n
                                          • Security and Reliability HRIs almost always take priority over Cost and Performance findings.<\/li>\n\n\n\n
                                          • Map each HRI to an owner, a remediation timeline, and a success criterion. Without ownership, findings sit in a report and nothing changes.<\/li>\n<\/ul>\n\n\n\n

                                            Step 4: Fix in code, not in the console<\/h3>\n\n\n\n

                                            This is the step where most organisations lose the value from a WAR. They fix HRIs through the AWS Console, close the tickets, and consider the review complete. Six months later, a new deployment recreates the problem because the fix was never codified.<\/p>\n\n\n\n

                                              \n
                                            • All remediations should be implemented in IaC \u2014 Terraform, CloudFormation, or CDK. Console fixes drift. IaC fixes persist.<\/li>\n\n\n\n
                                            • Add AWS Config rules to detect if a remediated configuration is reverted. Treat configuration drift as an operational alert.<\/li>\n\n\n\n
                                            • Run the review again in 6\u201312 months. A Well-Architected Review is not a one-time exercise \u2014 it is a recurring audit of your cloud discipline.<\/li>\n<\/ul>\n\n\n\n

                                              \ud83c\uddee\ud83c\uddf3  India Context: <\/strong>AWS Partner-led Well-Architected Reviews are available at no cost when conducted by an AWS Well-Architected Partner. The partner bears the review cost; AWS funds it as part of the Partner Program. If your MSP is an AWS Well-Architected Partner, request a partner-led review as part of your managed services engagement. If they are not, that is itself a signal worth noting during your next MSP evaluation.<\/em><\/p>\n\n\n\n

                                              What a Well-Architected Environment Actually Looks Like<\/h2>\n\n\n\n

                                              The AWS Well-Architected Framework is not a certification or a compliance standard. There is no passing score. The goal is not to answer every question with ‘yes’ \u2014 it is to make intentional, documented decisions about which risks you accept and which you remediate, based on your business context.<\/p>\n\n\n\n

                                              For Indian enterprises, the most urgent pillar is almost always Security \u2014 specifically because of the regulatory weight that DPDP Act and CERT-In compliance add to findings that would otherwise be treated as optional best practices. An HRI in the Security pillar is not just technical debt. In the Indian regulatory context, it is a potential enforcement finding.<\/p>\n\n\n\n

                                              Reliability comes second. Single-AZ databases, untested backups, and the absence of auto-scaling are the findings that become headlines \u2014 ‘Company X’s platform went down for 6 hours’ \u2014 and the root causes are almost always traceable to Reliability pillar gaps identified in a WAR that was never remediated.<\/p>\n\n\n\n

                                              Cost Optimization findings are typically the most immediately actionable and the easiest to justify to leadership \u2014 savings identified in a WAR often fund the rest of the remediation programme. Start there if you need internal momentum.<\/p>\n\n\n\n

                                              If you have not run a Well-Architected Review, start with the AWS Well-Architected Tool in your console this week. Open it, create a workload for your most critical production application, and work through the Security and Reliability pillars. What you find in the first two hours will tell you more about the state of your AWS environment than any monitoring dashboard.<\/p>\n\n\n\n

                                              <\/p>\n","protected":false},"excerpt":{"rendered":"

                                              Every AWS partner sells Well-Architected Reviews. Few explain what they actually surface \u2014 and fewer still explain what the findings mean in the specific context of an Indian enterprise, where…<\/p>\n","protected":false},"author":1,"featured_media":781,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5],"tags":[],"class_list":["post-780","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-cloud"],"_links":{"self":[{"href":"https:\/\/cloudfirst.in\/insight\/wp-json\/wp\/v2\/posts\/780","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/cloudfirst.in\/insight\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cloudfirst.in\/insight\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/cloudfirst.in\/insight\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/cloudfirst.in\/insight\/wp-json\/wp\/v2\/comments?post=780"}],"version-history":[{"count":1,"href":"https:\/\/cloudfirst.in\/insight\/wp-json\/wp\/v2\/posts\/780\/revisions"}],"predecessor-version":[{"id":782,"href":"https:\/\/cloudfirst.in\/insight\/wp-json\/wp\/v2\/posts\/780\/revisions\/782"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/cloudfirst.in\/insight\/wp-json\/wp\/v2\/media\/781"}],"wp:attachment":[{"href":"https:\/\/cloudfirst.in\/insight\/wp-json\/wp\/v2\/media?parent=780"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cloudfirst.in\/insight\/wp-json\/wp\/v2\/categories?post=780"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cloudfirst.in\/insight\/wp-json\/wp\/v2\/tags?post=780"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}