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.

Organizations cannot use Cloudflare's Developer Platform for applications with AWS resources or other infrastructure within VPCs, as Workers lack secure connectivity to VPC-isolated environments. This is a blocker for enterprise adoption.

As datasets grow, DynamoDB automatically increases partitions (10GB max per partition) but does not increase total provisioned throughput proportionally. This forces continuous throughput increases to maintain query performance, causing costs to spiral multi-fold.

DynamoDB partitions are limited to approximately 3,000 read capacity units and 1,000 write capacity units per second. When a single partition key receives excessive traffic ("hot key"), it can throttle and cause performance degradation. This is a hard limit that cannot be easily worked around and affects applications with uneven data access patterns.

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.

Common workarounds to extend DynamoDB (OpenSearch sync, RDS dual-write, Athena/Glue, Streams) introduce additional costs ($200-$1000/month), failure modes, operational overhead, and require specialized expertise. They essentially negate DynamoDB's simplicity benefit.

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.

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.

52% of developers using remote, containerized, or cloud-based environments experience redeploy times of 5+ minutes, with 13% reporting 10+ minutes. This is more than double the 23% experiencing such delays in local environments, creating a significant productivity barrier.

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.

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.

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.

DynamoDB is AWS-only with no support for multi-cloud or on-premises deployments. Its architecture doesn't translate easily to other databases, making migration off DynamoDB expensive and time-consuming. Organizations needing cloud provider independence or data sovereignty cannot use DynamoDB.

When application requests exceed provisioned read or write capacity units (RCUs/WCUs), DynamoDB throttles requests, leading to increased latency or application errors. Requires manual throughput adjustment via AWS CLI.

DynamoDB forces developers to decide partition and sort keys and design access patterns before product requirements crystallize. Changing queries later requires backfilling GSIs, schema migrations, and complex denormalized projections, whereas traditional databases allow simple index additions.

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.

Developers fear vendor lock-in due to Supabase's deep integration with cloud providers and the high operational overhead and complexity of migration, limiting willingness to adopt for long-term projects.

Loading large datasets into DynamoDB is cost-prohibitive and time-consuming. While DynamoDB excels at steady read/write operations of small, randomly distributed documents, bulk loading or batch operations can become economically unfeasible, making it unsuitable for analytical workloads or initial data migration.

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.

Working with DynamoDB locally is not straightforward. Unlike traditional databases, it cannot simply be run in a Docker container, forcing developers to use remote development environments deployed to AWS. This prevents offline work and requires deployment cycles even for configuration changes.

DynamoDB does not support SQL JOINs, stored procedures, triggers, or complex nested structures (beyond 32 levels). Applications requiring these features must implement logic in application code or use additional services, increasing complexity and performance overhead.

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.

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.

DynamoDB provides limited built-in visibility into table usage, access patterns, and cost drivers. Developers must integrate external monitoring tools like CloudWatch, Prometheus, or DataDog to understand performance issues. Issues like hot partitions and throttling aren't automatically resolved, requiring developer expertise to diagnose.

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.

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

Developers using Backend-as-a-Service solutions for AI agents encounter pricing cliffs as soon as their app gains traction. BaaS platforms also lock in behavior and reduce flexibility to fine-tune backend operations, forcing developers who need control to migrate to IaaS platforms like AWS or Azure.

Managing applications across diverse deployment environments (AWS, Azure, on-premise, Kubernetes, serverless) requires different NGINX configurations, tools, and operational knowledge. This diversity leads to complexity sprawl, configuration drift, and increased operational toil.

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.

DynamoDB's on-demand pricing model can lead to unexpected expenses with variable workloads. Provisioned mode requires careful capacity planning to avoid throttling or waste, and cost monitoring is complex without proper tooling configuration.

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 S3 documentation is difficult to understand, especially when integrating with other AWS services like Elemental MediaConvert. Developers must rely on external resources like AI, YouTube videos, or third-party aids to complete integrations.

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 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.

DynamoDB latencies range from under 10 milliseconds to tens of milliseconds and can spike significantly under heavy load or during throttling. Cross-region replication adds additional latency. Applications requiring consistent sub-5ms or sub-1ms latency must use alternative solutions.

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.

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.

DynamoDB enforces a hard 400KB limit per item, significantly smaller than competing document databases (MongoDB 16MB, Cassandra 2GB). Applications storing large objects must split data across items or use external storage like S3, adding architectural complexity.

DynamoDB global tables introduce ~1 second replication lag, preventing immediate global consistency across regions. Applications requiring true ACID consistency across tables or regions cannot rely on DynamoDB.

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.