DEV Community: Kiran More

Unlocking Real Business Value: My Hands-On Journey

Kiran More — Thu, 01 Jan 2026 12:40:11 +0000

Cloud migration stories are everywhere, but every journey is unique. As an AWS Solution Architect, I’ve led multiple migrations from legacy on-premise environments to AWS, and I’ve learned that success isn’t just about moving workloads-it’s about transforming business outcomes.

Here’s my practical approach, blending AWS’s proven framework with real-world lessons:

Assess: Beyond the Checklist
I start with a deep-dive discovery, not just inventorying assets but mapping dependencies, business priorities, and pain points. This means engaging with stakeholders across IT and business units to uncover hidden risks and opportunities.
Mobilize: Building the Right Foundation
Instead of a generic landing zone, I design a tailored AWS environment that aligns with compliance, security, and operational needs. Automation is key-using Infrastructure as Code (IaC) to ensure repeatability and governance from day one.
Migrate: Orchestrating with Precision
I leverage AWS Migration Hub and native tools, but also integrate custom scripts and third-party solutions for complex workloads. My focus: zero business disruption, phased cutovers, and continuous validation.
Modernize: Accelerating Innovation
Migration isn’t the finish line. I work with teams to refactor applications, adopt serverless, and implement CI/CD pipelines-unlocking agility and cost savings that weren’t possible on-premise.

What Sets Approach Apart:
Business-first mindset: Every technical decision is tied to measurable business value.
Hands-on leadership: I’m in the trenches with teams, solving problems as they arise.
Continuous improvement: Post-migration, I drive optimization sprints to maximize ROI.

Conclusion:
Cloud migration is more than a technical project-it’s a catalyst for business transformation. If you’re planning your own journey, focus on outcomes, not just activities. Let’s connect and share insights!
hashtag#AWS hashtag#CloudMigration hashtag#DigitalTransformation hashtag#SolutionArchitect hashtag#Modernization

On-Prem Oracle vs. AWS RDS: A Comparison 📊

Kiran More — Wed, 31 Dec 2025 12:18:10 +0000

I’ve been deep-diving into the architectural impact of migrating On-Premise Oracle databases to AWS RDS. The shift isn't just about changing where
the data lives; it's about fundamentally changing the operational model.
Here are my key takeaways from a recent deep dive:

⚙️ Database Engine
On-Prem: Full control over versions and patching.
RDS: Managed service. You choose the version, but AWS manages the OS. Options for "License Included" or "Bring Your Own License" (BYOL).
⚡ High Availability (HA)
On-Prem: Complex setup (RAC, manual Data Guard).
RDS: Multi-AZ deployment. Synchronous replication to a standby instance with automatic failover.
📈 Scalability
On-Prem: Limited by physical hardware; lengthy procurement cycles.
RDS: Vertical scaling (push-button instance resizing) and Storage Auto Scaling (up to 64TB) with zero downtime.
🛡 Security & Backups
On-Prem: Physical security + Network firewalls. Manual RMAN scripts for backups.
RDS: VPC Security Groups, IAM integration, and Encryption at Rest (KMS). Automated backups and Point-in-Time Recovery (PITR).
⚙️Maintenance
On-Prem: DBA manages OS patching, DB patching, and hardware.
RDS: AWS handles OS patching. You define a "Maintenance Window" for DB updates.
🔍 Monitoring
On-Prem: OEM (Enterprise Manager).
RDS: CloudWatch metrics + Performance Insights (visualizes load by waits/SQL).
🛠 Migration Tools
The Winners: AWS Schema Conversion Tool (SCT) for heterogenous migrations and AWS DMS (Database Migration Service) for continuous data replication.
The move to RDS isn't just a "lift and shift"—it's a shift from managing infrastructure to managing data value.
hashtag#AWS hashtag#Oracle hashtag#CloudMigration hashtag#DatabaseArchitecture hashtag#SolutionArchitect hashtag#TechTips

🌐 Strengthening the Security Pillar of the AWS Well-Architected Framework: Introducing EC2 Instance Attestation

Kiran More — Mon, 29 Dec 2025 12:32:35 +0000

AWS continues to raise the bar on cloud security with the launch of EC2 Instance Attestation - a new feature that allows you to cryptographically verify that your EC2 instance is running a trusted and approved configuration.

🔒 Security as a Pillar in the AWS Well-Architected Framework
One of the six pillars of the AWS Well-Architected Framework, the Security Pillar, focuses on protecting data, systems, and assets through strong identity management, traceability, and infrastructure protection.

EC2 Instance Attestation aligns perfectly with this by bringing a new layer of integrity verification to your compute layer.

🧩 How It Strengthens the Security Pillar

✅ Identity and Access Management
By using cryptographic proofs tied to the Nitro TPM, you can ensure only attested (trusted) instances are allowed to decrypt secrets or access AWS KMS keys.
This moves your design closer to a Zero Trust model - “never trust, always verify,” even for your own compute resources.

✅ Infrastructure Protection
Instance attestation validates the integrity of your AMIs and runtime environment.
This ensures that only approved, tamper-free images can run - significantly reducing risks from unauthorized software or image drift.

✅ Data Protection
When paired with KMS condition keys or a custom certificate authority (CA), you can enforce that only instances verified through attestation can decrypt or access sensitive data.
This creates a chain of trust from infrastructure to application.

✅ Operational Excellence & Compliance
For regulated workloads, attestation provides strong evidence that the infrastructure remains compliant and unchanged - a valuable control point during audits and reviews.

💡 Tips & considerations
Start by integrating attestation into non-critical workloads to validate processes before scaling to business-critical systems.
Treat your AMI creation flow like code: versioning, reproducibility, immutability, code reviews.
Think about your CA/PKI strategy early - issuance, rotation, revocation, and how other systems validate certs.
Monitor and log attestation events (successes/failures) in your security telemetry.
Educate stakeholders (DevOps, security, auditors) on what “attested instance” really means in your context.

💡 Key Takeaway

The AWS Well-Architected Security Pillar has always emphasized building a strong foundation of identity, traceability, and protection.
With EC2 Instance Attestation, AWS gives architects and security teams a new tool to prove trust at the compute layer - reinforcing defense-in-depth principles.

💭 How are you planning to integrate attestation into your Well-Architected workloads?
Would love to hear how teams are aligning this feature with their security pillar strategies.

Optimizing AWS Lambda Performance: Balancing Power and Cost

Kiran More — Sun, 28 Dec 2025 22:58:58 +0000

Over the past week, I ran a series of performance tests to fine-tune an AWS Lambda function’s configuration- focusing on finding the right balance between execution speed and cost efficiency.

Using AWS Lambda Power Tuning, I tested the function with memory allocations of 128 MB, 256 MB, 512 MB, and 1024 MB. Each configuration was then load-tested using Postman’s Performance Testing feature to simulate concurrent requests and measure throughput, latency, and stability.

Here’s a summary of the results from the Postman reports:

128 MB: Slowest response times, with average latency exceeding 1 second under load.
256 MB: Noticeable improvement, but still some lag under higher concurrency.
512 MB: Significant performance boost- average response time dropped to around 505 ms, with throughput of 4.09 requests/sec
1024 MB: Best overall performance - average response time reduced further to 295 ms, and throughput increased to 5.03 requests/sec
All tests completed successfully with 0% error rate, confirming stable performance across configurations.

Key Takeaways:

Increasing Lambda memory allocation not only boosts available CPU power but also reduces execution time.
However, higher memory means higher cost per invocation - so the goal is to find the “sweet spot” where performance gains justify the additional expense.
In this case, 512 MB offered a strong balance between speed and cost, while 1024 MB delivered maximum performance for latency-sensitive workloads.
By combining AWS Lambda Power Tuning with Postman Load Testing, it’s possible to make data-driven decisions that optimize both performance and cost efficiency in serverless applications.

hashtag#AWS hashtag#Serverless hashtag#Lambda hashtag#PerformanceTesting hashtag#Postman hashtag#CloudComputing hashtag#Optimization

⚡ The AWS Outage: A Reminder That Resilience Is an Architecture, Not an Assumption ⚡

Kiran More — Sat, 27 Dec 2025 13:27:17 +0000

The recent AWS outage once again reminded us that even the most resilient cloud providers are not immune to failure. Availability zones, regions, and SLAs are not a substitute for a well-designed Disaster Recovery (DR) strategy -
they are only the foundation.

As architects and technology leaders, we must design for failure by intent, not by reaction.

Let’s revisit two fundamental metrics that drive every effective DR plan:

🕒 Recovery Time Objective (RTO) – How long can your systems be down?
If your RTO is 3 hours, your system must be restored and operational within that window. Achieving this often means implementing automated failover and multi-zone or multi-region deployments to reduce manual recovery time and ensure continuity.

💾 Recovery Point Objective (RPO) – How much data can you afford to lose?
If your RPO is 2 hours, you should be able to restore data to a point not older than two hours before the incident. That requires frequent replication, cross-region backups, and robust data synchronization mechanisms.

A multi-zone or multi-region architecture plays a pivotal role in achieving low RTOs and RPOs. Spreading workloads across availability zones ensures that even if one zone goes down, your applications continue to serve users from another, minimizing disruption.

However, architecture alone isn’t enough. The real test of resilience lies in execution.
That’s why regular DR testing is non-negotiable for mission-critical business applications. Simulated failovers, backup restoration drills, and chaos engineering exercises help uncover hidden weaknesses long before a real disaster strikes.

💡 Key Takeaways:

Design for failure, not perfection.

Multi-zone and multi-region deployments are essential, not optional.

An RTO and RPO are only meaningful if they are tested and achieved consistently.

Downtime costs far more than investment in proactive resilience.

Outages will happen — but how quickly you recover and how much you lose is entirely within your control.

hashtag#CloudArchitecture hashtag#AWS hashtag#DisasterRecovery hashtag#Resilience hashtag#DevOps hashtag#RTO hashtag#RPO hashtag#CloudComputing hashtag#HighAvailability hashtag#MultiRegion hashtag#Observability

When "Good Enough" isn't enough: Why Netflix moved to Amazon Aurora. 🎬☁️

Kiran More — Fri, 26 Dec 2025 21:05:32 +0000

I just finished reading the AWS deep dive on how Netflix consolidated their relational database infrastructure on Amazon Aurora.
While the headline is the massive 75% improvement in performance, the real architectural takeaway for me was the strategy of Consolidation.
Netflix didn't just migrate; they simplified. By moving from a fragmented landscape of self-managed and legacy databases to a unified Aurora ecosystem, they achieved:
Reduced Operational Toil: Less time patching and managing varied engines.
Scalability: Leveraging Aurora’s storage auto-scaling to handle "Netflix scale" traffic spikes.
Cost Efficiency: Performance improvements often translate directly to fewer instances required.
For Solution Architects, this is a prime example of how modernizing the data layer isn't just a tech upgrade-it's a business efficiency play.
Read the full case study here: https://lnkd.in/ek2hGZ6D

💡 Interview Prep Tip:
Question : WHY Aurora is faster ?
Answer: Aurora is faster because it separates Compute from Storage. It writes to a shared, distributed storage volume across 3 Availability Zones (6 copies of data) without the heavy I/O overhead of traditional synchronous replication. This allows the compute nodes to focus purely on query processing.

hashtag#AWS hashtag#CloudArchitecture hashtag#Netflix hashtag#AmazonAurora hashtag#Database hashtag#SystemDesign

I posted about AWS WAF cost savings, and the AWS Product Team shared a game-changer with me...

Kiran More — Thu, 25 Dec 2025 15:56:34 +0000

In my last post, I shared a deep dive into architecting AWS WAF for cost efficiency (using scope-down statements and rule prioritization).
But a Principal Product Manager at AWS reached out with a different perspective-one that solves the biggest headache for Solution Architects and FinOps teams: Predictability.
While technical optimization is crucial, sometimes the business just needs a bill that doesn't fluctuate.
They introduced me to the new CloudFront Flat-Rate Pricing model. If you are managing high-traffic workloads, this is a massive shift.
📦 What’s in the bundle?
Instead of paying for every request and rule, you get a single monthly price that includes:
✅ Amazon CloudFront (Content Delivery)
✅ AWS WAF (Web Application Firewall)
✅ AWS Shield (DDoS Protection)
✅ Bot Control (Common Bot Rules)
✅ Route 53 & CloudWatch Logs
✅ S3 Storage Credits
💡 The Hidden Gem:
It waives the costs for regional data transfer to CloudFront. If you’ve ever looked at your "Data Transfer" line item, you know how huge that saving is.
The takeaway:
My previous post helps you reduce the bill. This new model helps you fix the bill.
The cloud is always evolving. Huge thanks to the AWS team for sharing this resource!

Link to the full breakdown : https://lnkd.in/eAgX5q9n

Huge thanks to Cristian Graziano for pointing this out.

hashtag#AWS hashtag#CloudFront hashtag#FinOps hashtag#AWSCommunity hashtag#SolutionArchitect hashtag#CloudSecurity

Stop Overpaying for AWS WAF! (5 Cost Optimization Tips)

Kiran More — Wed, 24 Dec 2025 20:56:18 +0000

As a Solution Architect, I was deep diving into the cost saving of AWS WAF, and I realized we were burning money on "noise."

Are you looking at the Cost Optimization pillar of the AWS Well-Architected Framework? Don't overlook your Web Application Firewall.
WAF costs can spiral if you treat it as a "set and forget" service. Here is how to align AWS WAF with cost-efficiency best practices:
1️⃣ Use "Scope-Down" Statements 📉
Don't run expensive rules (like Bot Control or Regex patterns) on every single request. Use scope-down statements to only inspect specific paths (like /login or /checkout). This massive reduction in inspected traffic directly lowers your bill.
2️⃣ Optimize Rule Order 🔢
AWS WAF evaluates rules in priority order.Place your "cheap" and high-volume block rules (like IP rate limits or Geo-blocking) at the top. Block the noise early so you don't pay for expensive rule evaluations on junk traffic.[3]
3️⃣ Leverage AWS Shield Advanced 🛡️
If your monthly WAF + Data Transfer bill is high (typically >$3k/mo), switch to AWS Shield Advanced.[4][5] It creates a flat-fee model and waives standard WAF WebACL and Rule fees for protected resources.
4️⃣ Smart Logging 📝
Logging every single request to CloudWatch Logs gets expensive fast.
✅ Use Kinesis Data Firehose for high-volume logs (cheaper ingestion).
✅ Filter logs to only capture "Blocked" requests or specific rule matches to reduce storage costs.
5️⃣ Separation of Concerns 🏗️
Don't put WAF on static assets (images, CSS) unless absolutely necessary. Route static traffic through a separate CloudFront behavior that doesn’t invoke the WAF, or use WAF rules to explicitly ignore those file extensions.

💡 Pro Tip: Review your "Unused Rules" quarterly. If a rule hasn't triggered in 90 days, it's just costing you monthly rental fees. Delete it!
hashtag#AWS hashtag#CloudSecurity hashtag#CostOptimization hashtag#FinOps hashtag#AWSCommunity hashtag#CyberSecurity hashtag#WellArchitected

Reliability isn’t about avoiding failure; it’s about how fast you recover. ☁️

Kiran More — Mon, 22 Dec 2025 22:04:37 +0000

I’ve been diving deep into the Reliability Pillar of the AWS Well-Architected Framework, specifically focusing on the “Self-Healing” capabilities of distributed systems.
The real magic happens when you couple Application Load Balancer (ALB) health checks with Auto Scaling Groups (ASG).
In the configuration below, I’ve set up a robust detection mechanism:

Granular Detection: Using a specific port override (8080) to check the application process, not just the server status.
Fast Isolation: With an Unhealthy Threshold of 2, the ALB stops routing traffic to a failing node almost immediately (within ~1 minute given the interval).
Conservative Recovery: A Healthy Threshold of 5 ensures the new instance is absolutely ready before receiving live traffic, preventing “flapping.” The result? The ALB isolates the fault, and the ASG automatically replaces the instance. Zero human intervention required. How do you tune your health check intervals for high-traffic apps? hashtag#AWS hashtag#SolutionArchitect hashtag#CloudComputing hashtag#DevOps hashtag#Reliability hashtag#WellArchitected

IAM Roles, Temporary Credentials & Alerting - AWS Well-Architected Framework (Security Pillar)

Kiran More — Thu, 18 Dec 2025 21:32:57 +0000

I recently deep dived on IAM roles, temporary credentials, and proactive alerting through the lens of the AWS Well-Architected Framework - Security Pillar, focusing on how identity, monitoring, and protection work together to reduce risk.
🚀 What I explored:
✅ Strong identity foundations (IAM Roles)
Designed a least-privilege IAM role for an EC2-based application, granting read-only access to S3 and eliminating long-term static credentials.
✅ Short-lived access with AWS STS
Used AWS Security Token Service (STS) to assume roles and generate temporary credentials, significantly reducing credential exposure and blast radius.
✅ Explicit trust relationships
Defined precise trust policies to control who can assume roles-ensuring access is intentional, secure, and auditable.
✅ Continuous monitoring & alerting
Configured CloudWatch alarms backed by AWS Config metrics to detect IAM user creation, modification, or deletion in near real time.

IAM & least privilege → Strong identity controls
STS temporary credentials → Reduced blast radius
CloudWatch & AWS Config → Detection and response
Together, these practices form a well-architected, security-first cloud foundation.
🔑 Key takeaway:
Security starts with identity. Short-lived credentials, least privilege, and real-time alerting are core principles of the AWS Well-Architected Security Pillar.
hashtag#AWSWellArchitected hashtag#SecurityPillar hashtag#IAM hashtag#STS hashtag#CloudSecurity