AWS

AWS IAM's core design prioritizes deterministic permission evaluation over security usability, resulting in a system where CRUD-style permissions cannot be implemented auditably. The architecture uses low-level API action lists with boolean logic complexity ('deny sandwich'), strict character limits forcing wildcard usage, and unpredictable new actions added without warning, making it impossible to implement basic security expectations.

AWS services exhibit inconsistent API naming conventions (List vs Describe vs Get), response formats (items vs item), and field naming (StreamName vs StreamARN, CreationTime vs other patterns). This inconsistency forces developers to constantly refer to documentation, increases mental load, reduces code reliability, and can introduce production bugs when assumptions fail.

AWS billing is opaque and difficult to track. Hidden charges from services like EBS snapshots, NAT gateways, and Route 53 are hard to identify. Billing alerts arrive before invoices are sent, and AWS's pay-per-use model makes experimentation risky without proper monitoring.

IAM error messages are vague and don't clearly indicate what permissions are missing or what the actual issue is. Developers resort to support tickets to understand error messages, creating blocker dependencies.

AWS services can be discontinued or changed in breaking ways that force major application rewrites. Combined with deep vendor lock-in from using service-specific features, developers face long-term risk of forced refactoring or application unavailability.

Deploying a basic webapp to AWS requires navigating IAM Identity Center, SSO, permission sets, IAM roles, GitHub Actions/CodeBuild integration, OIDC setup, and service selection (Amplify vs CodeCatalyst vs others) before any code runs. Without pre-existing CI/CD infrastructure, the process is prohibitively complex compared to platforms like Vercel.

Migrating legacy applications to AWS can fail due to outdated dependencies and incompatible configurations. Requires thorough assessment and code refactoring.

When something goes wrong in an AWS environment, it is difficult to identify root causes and determine fixes. Error handling across distributed services is complex and time-consuming.

Using AWS services optimally demands general knowledge of all AWS services and their trade-offs, plus deep expertise in the chosen service (e.g., DynamoDB, Step Functions). Mediocre knowledge is insufficient, and the learning curve is steep with limited training materials available.

Large Terraform applies trigger API throttling (429 errors) when hitting per-account or per-region cloud provider limits. Additionally, eventually-consistent cloud services may not reflect changes immediately, causing subsequent API calls to fail or return stale data.

Developers must balance using the best resources for performance with managing costs. Finding the optimal resource configuration to meet both requirements is a constant struggle.

When IAM permission errors occur, developers must manually add permissions rather than having AWS automatically generate the required policy. A simple 'Fix this' button that generates required IAM records would dramatically reduce friction, but this feature doesn't exist.

AWS IaC solutions lack the ability to deploy running resources via simple URLs (which would allow non-technical stakeholders to provision infrastructure). Instead, developers must use CLI tools, and CloudFormation—the only AWS IaC supporting URL deployment—is painful to write and slow to iterate on.

AWS documentation is difficult to navigate, unclear, and poorly organized. It reads as if written in isolation without practical developer context. The SSO/IAM Identity Center URL is so hard to remember developers build custom redirectors. Documentation doesn't effectively explain relationships between services or provide clear decision trees.

Meeting regulatory requirements and compliance standards is a significant challenge for AWS developers. Applications must comply with industry regulations and follow governance best practices.

Many AWS services are incomplete or poorly designed (e.g., SageMaker Studio vs regular SageMaker). The vast product portfolio means quality varies significantly and some products are not production-ready.

AWS adding IPv6/AAAA support to endpoints breaks existing IAM policies that use v4-centric statements (like aws:SourceIp). This causes unexpected DENYs or, worse, unexpected ALLOWs that compromise access control, impacting customers in affected regions with limited workarounds.

Moving large volumes of data to AWS is time-consuming and expensive. Even with AWS Database Migration Service, phased strategies, and optimization, the process remains a significant operational and financial burden.

Deploying an app requires managing resources scattered across different AWS console sections (S3, CloudFront, Route 53, EC2/Fargate/Lambda+API Gateway, RDS/DynamoDB, billing alarms). These services don't integrate well out-of-the-box, forcing context switching and manual coordination.

AWS does not communicate when services will be ready or whether specific requirements will be supported. Features evolve unpredictably, and if AWS doesn't add needed functionality within required timeframes, developers must compose workaround services.

AWS VPC networking topology is confusing, with non-intuitive constraints like subnets being restricted to single availability zones ('one subnet equals one availability zone'). This creates gotchas when designing multi-AZ deployments.

NAT Gateway pricing is inconsistent with cloud elasticity promises—developers are charged for provisioning NAT Gateways even when not using them heavily, creating unexpected cost surprises and misalignment between pay-as-you-go expectations and actual billing.

AWS cost management tools (Trusted Advisor, Cost Explorer) provide only historical analysis and recommendations, not proactive guidance. They lag real-time spending and cannot predict whether current costs will match forecasts, making it difficult to catch cost overruns early.

Recent AWS announcements at major events (like re:Invent) are perceived by some attendees as reiterations of existing offerings with minimal added value to current products, rather than groundbreaking innovations. This erodes customer confidence and reduces incentive for platform adoption.