Loading…
Topic
202 posts about AWS. Every summary links to the original.
See the idea
Amazon Bedrock is the managed reasoning tier in an agent architecture, not the whole system. This layered view shows the pipelines, governed tables, query layer, and guardrails around it.
CloudFormation is a declarative reconciler: you describe the target state in a template, and it provisions, updates, and reports on the stack that results. Here is the loop.
Amazon EVS runs VMware Cloud Foundation on AWS bare metal, so the design question becomes where each workload's data lives. This layered diagram shows how vSAN, FSx for ONTAP, and cross-Region DR divide the work.
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
Newest first
MongoDB presented its 2025 Global Partner Awards to honor partner organizations across cloud infrastructure, systems integration, generative AI, and enterprise data management. Microsoft received the Global Cloud Partner award for joint go-to-market solutions integrating MongoDB Atlas with native Azure services across healthcare, telecommunications, and financial services. Amazon Web Services earned the Global AI Cloud Partner award after delivering an Amazon Bedrock and MongoDB Atlas workflow implementation for Novo Nordisk that reduced processing time from twelve weeks to ten minutes. Confluent was recognized as Global Technology Partner for exceeding 550 joint deployments leveraging Apache Kafka for real-time data streaming and event-driven AI architectures. Other honored partners include Google Cloud for joint sales development programs, Accenture for software engineering centers of excellence, LangChain for retrieval-augmented generation tooling, and IBM for Watsonx.ai integrations.
MongoDB announced the recipients of its 2025 Global Partner Awards, recognizing enterprise collaboration across cloud infrastructure, artificial intelligence, and systems modernization. Microsoft received the Global Cloud Partner award for joint integrations with Azure, while Amazon Web Services earned the Global AI Cloud Partner award following deployments combining Amazon Bedrock and MongoDB Atlas. Google Cloud was recognized for joint go-to-market initiatives, and Accenture received honours for establishing a dedicated MongoDB Center of Excellence within its software engineering division. Additional recognitions included Confluent for event-driven streaming deployments exceeding 550 customer implementations, BigID for data governance, gravity9 for modernization services, and Alibaba Cloud for managed database services. IBM and Accenture Federal Services were also acknowledged for strategic enterprise impact across mainframe architectures and public sector programs.
Stripe events can connect backend state changes to responsive frontend interfaces for payments, subscriptions, connected accounts, and Stripe Terminal workflows. The post contrasts polling, which can increase traffic, latency, and delta-computation complexity, with push subscriptions, while noting that a hybrid of initial API loading and incremental updates is common. It describes webhook endpoints and Amazon EventBridge as ingestion choices, then emphasizes idempotency, ordering, duplicate detection, and failure handling. Frontend delivery options include WebSockets, MQTT, gRPC, Server-Sent Events, polling, AWS AppSync, and Momento, selected according to messaging pattern, direction, latency, scale, and operational trade-offs. An abbreviated lounge example uses a PaymentIntent and Terminal reader, routes payment_intent.requires_payment_method through EventBridge to AWS AppSync Events, and lets a React client mark the reader ready to collect payment.
Maintaining consistent product data between an internal catalog and Stripe becomes difficult when outages, throttling, high volumes, and changes from both systems create reconciliation failures. The post compares a naive one-way flow, in which a Lambda calls the Stripe API with no persistent synchronization record, with a queue-based design that durably stores changes, controls processing rate, retries failures with exponential backoff, and sends persistent failures to dead-letter queues. For bidirectional synchronization, it contrasts periodic ETL, using extraction, transformation, and loading, with an event-driven model based on Stripe Event Destinations, EventBridge, SQS, and symmetrical events from internal systems. The conclusion is that durable, observable queues and event-driven processing provide buffering, auditability, near-real-time propagation, independent change processing, and more graceful scaling for distributed reconciliation.
Grab describes how it evolved its machine learning feature store as increasingly complex models began requiring high-cardinality keys and high-dimensional data. It replaced its initial Amphawa approach with feature tables: data-lake tables whose contents are atomically ingested into serving storage, with emphasis on consistency and reproducibility. The workflow stores feature tables and version-control metadata as Parquet objects in Amazon S3, validates schemas, loads data through reverse ETL into Aurora Postgres, and warms new tables through shadow reads before switching. The redesign supports contextual retrieval, atomic collection-wide updates, and isolation between reading and writing capacity; its SDK remains a thin database-driver wrapper that translates queries to SQL. Grab also chose decentralised deployments for version flexibility, rollout strategies, noisy-neighbor mitigation, and improved caching, concluding that Amazon Aurora for Postgres provides a robust, scalable, cost-effective foundation.
The post addresses performance, cost, latency, and rate-limiting challenges that arise when applications make high-volume requests to Stripe's API from AWS Lambda. It presents a two-level cache using ElastiCache for Redis as the first layer and DynamoDB as the durable second layer, with Lambda coordinating cache reads, Stripe retrieval, and writes. On a miss, the function checks Redis, then DynamoDB, fetches the customer from Stripe if necessary, and stores the response in both layers with one-hour Redis and 24-hour DynamoDB TTLs. The DynamoDB design uses composite keys, a GSI for cache-type and timestamp queries, TTL cleanup, and environment-specific capacity settings; the post also discusses Redis connection pooling, Lambda sizing, capacity planning, cost control, monitoring, and webhook-based invalidation.
Payment workflows can produce duplicate charges when a customer retries after a connection drop while the backend is still retrying the original request. The post frames network timeouts, crashes, database locks, downstream errors, and user interruptions as normal distributed-systems failures that can leave payment state uncertain. It recommends generating a unique idempotency key for one specific action, sending it with the Stripe request, and reusing it on every retry; Stripe recognizes the key for 24 hours and returns the original response. It also recommends placing payment jobs in a queue such as Amazon SQS, where workers retry failures and route repeatedly failing messages to a dead-letter queue. Together, queues preserve work during temporary outages and idempotency makes retries safe, while careful key scope and timing avoid stale or cross-operation behavior.
Enterprise subscription management must handle mid-cycle plan changes, usage-based billing adjustments, synchronized service updates, atomicity, failed operations, data consistency, and auditability beyond basic recurring billing. This sample architecture uses an event-driven AWS design in which subscription changes are published to EventBridge and routed to Step Functions workflows. EventBridge provides at-least-once delivery, content-based filtering, dead-letter queue support, and integration with Step Functions, while Lambda functions validate changes, calculate Stripe proration, update external subscriptions, and trigger service-specific actions. Step Functions supplies retries with exponential backoff for StripeTemporaryError, DynamoDB stores current and historical subscription data using transactional updates, and Stripe calls use an event identifier as an idempotency key. The pattern is presented as a flexible foundation for reliability, maintainability, compensation for partial changes, and auditability in systems handling financial transactions and service provisioning.
Payment processors such as Stripe emit numerous transaction events, while dashboard and API-based or batch approaches can limit historical analysis, real-time visibility, and correlation with business metrics as volumes grow. The proposed pipeline sends signed Stripe webhooks through API Gateway to Lambda for validation and enrichment, buffers them in Kinesis Data Streams, and uses a second Lambda to transform and index records in OpenSearch. OpenSearch Dashboards provides visualizations, while CloudWatch tracks pipeline health; Kinesis retention and replay support recovery and reprocessing. The post also describes a Kinesis Data Firehose route that can remove the consumer Lambda and reduce costs but may add batching latency. The resulting design is presented as scalable to millions of transactions per day, with sub-minute payment metrics visibility and flexible historical querying, while security guidance includes encryption, IAM configuration, and regular audits.
The guide describes a multi-region payment-processing architecture for applications that use Stripe’s API and need resilience against regional outages, latency, rate limits, and payment-data compliance constraints. It routes requests with Amazon Route 53 health checks and configurable latency-based, weighted, or geolocation policies, while identical regional API Gateway and Lambda deployments process payments. DynamoDB Global Tables replicate payment state and support distributed rate limiting, with optimistic locking, regional token-bucket allocation, retries, and exponential backoff for Stripe requests. The sample Lambda records a payment as PENDING, creates and confirms a Stripe PaymentIntent, then updates the state with the Stripe payment ID and returned status; the conclusion presents the design as a foundation for regional resilience, state consistency, and API-rate management.
The article presents a low-code method for analyzing Stripe business and customer data and moving scheduled report results into AWS. Stripe Sigma lets users query payment, subscription, and plan-related data with SQL, while Sigma Assistant can generate and execute queries from natural-language prompts such as cancellation analysis. For delivery, the article uses the sigma.scheduled_query_run.created event and Stripe's Event Destination to Amazon EventBridge, where a partner event bus and event rule trigger AWS services without a separate public webhook API. Its Lambda example downloads the report CSV with the Stripe API key, parses it into JavaScript objects, and publishes the result through Amazon SNS; the same event-driven pattern can support Lambda, Step Functions, or Glue workflows.
Pay-as-you-go services need a way to warn customers when consumption reaches a configured limit, but building usage aggregation, monitoring, and notification workflows adds operational complexity. This tutorial uses Stripe Billing Alerts to define a customer-specific usage threshold with a customer_id, meter_id, gte value, and recurrence, then sends billing.alert.triggered events through Stripe Event Destinations to an Amazon EventBridge partner event source. It tests the flow with Stripe Meter Events and shows AWS CLI rules routing the event to Amazon SNS, as well as a Lambda example that retrieves the customer's email from Stripe and sends mail with Amazon SES. The result is a minimal-code notification path using AWS services, with sandbox setup required because some APIs and features may not be available in conventional test mode.
The article presents a production-grade approach to securing Stripe API keys in AWS, motivated by the risks and operational limits of basic secret storage for payment processing. It compares AWS Parameter Store with Secrets Manager, emphasizing built-in rotation, CloudTrail audit trails, IAM integration, larger secrets, and cross-account access despite higher cost. The implementation uses environment-specific secret paths, tags, and IAM conditions to isolate development, staging, and production credentials, with separate rotation schedules. For zero-downtime rotation, applications refresh cached credentials after authentication failures while both old and new keys remain valid during a transition. The design also covers CloudWatch monitoring, emergency rotation procedures, cross-region replication, region-specific schedules, and cost considerations, concluding that ongoing review is necessary for secure and reliable payment operations.
Reliable Stripe webhook processing must account for lost deliveries from network or service outages, out-of-order events, and duplicates caused by Stripe retries. The proposed AWS architecture uses API Gateway for signature validation and throttling, an SQS FIFO queue for ordered delivery and content-based deduplication, Lambda for processing, DynamoDB for event-ID idempotency, and an SQS DLQ for failed messages. In the CloudFormation example, the main queue has a 300-second visibility timeout and sends messages to the FIFO DLQ after three receives; DynamoDB records expire through a seven-day TTL. Lambda retries failures with exponential backoff, while CloudWatch monitors queue depth, latency, and errors. The design is presented as a scalable foundation, with multi-region failover available at added cost and complexity, though single-region deployment may suffice for many applications.
As Canva expanded to over 200 million monthly active users, ingestion throughput reached 25 billion records daily, causing AWS Data Firehose costs to consume nearly half of the product analytics platform budget. To reduce these expenses and eliminate intermediate file staging, the engineering team integrated Snowflake's Snowpipe Streaming directly with their Java-based Kinesis Data Streams pipeline. The architecture streams records directly into Snowflake tables using logical channels with offset checkpoints while configuring client buffering up to a five-minute maximum lag. In handling Kinesis Client Library edge cases, record processors coordinate with the LeaseCoordinator to drop leases when channels become unhealthy. Operating in production for over six months, the system ingested more than 20.35 petabytes of data, decreased query latency to roughly ten minutes, and reduced overall cloud spend by 45 percent.
On November 12, 2024, canva.com suffered an outage lasting approximately one hour due to cascading API Gateway failures. The disruption began when a stale Cloudflare routing rule induced severe latency and packet loss between Ashburn and Singapore during an editor asset deployment. Cloudflare's concurrent streaming mechanism consolidated over 270,000 user requests for a single delayed JavaScript chunk; when the asset finally loaded, clients simultaneously generated a 1.5 million requests-per-second thundering herd to Canva's API Gateway. This surge collided with a telemetry performance regression involving lock contention on Netty event loop threads, exhausting off-heap memory and causing the Linux Out Of Memory Killer to terminate API Gateway containers. Canva mitigated the failure by temporarily blocking all traffic at the CDN level, stabilizing replacement Amazon ECS tasks, and gradually restoring traffic under strict rate limits.
Energy utilities can use embedded finance to create marketplace-like experiences for tariffs, solar installations, smart-home devices, storage, and related services while capturing more energy-related revenue. The proposed foundation combines Stripe Online Payment Flows, Billing, Payments, Connect, and Data Pipeline with AWS serverless services, including Lambda, EventBridge, DynamoDB, Redshift, S3, and QuickSight. A tariff enrollment or payment can trigger webhooks and real-time event processing, while transaction and customer data support dashboards, usage insights, personalized recommendations, subscriptions, and broader partner offerings. The architecture also describes PCI Level 1 security, encryption, Radar, Strong Customer Authentication, AWS IAM, KMS, Shield, WAF, Config, Security Hub, and CloudWatch for compliance and monitoring. It concludes that this integrated payment, analytics, and security foundation can help utilities improve customer engagement, support sustainable programs, and develop new revenue streams.
The DevRel Swag Store uses Stripe payments and AWS services to keep product inventory accurate and visible in near real time. Stripe products retain core payment information, while Amazon DynamoDB stores inventory and other attributes, keyed by Stripe product ID and store ID; EventBridge routes payment events to Lambda, which atomically decrements stock and publishes updates through AWS IoT Core to the frontend. DynamoDB condition expressions prevent decrements when stock is insufficient, while post-payment validation and refunds address the delay before a Stripe Payment Link is disabled, although Stripe fees may be non-refundable. A custom Payment Intent flow can check stock before payment, authorize funds with manual capture for up to seven days, update inventory after payment success, and then capture the charge.
Stripe events notify account owners about changes such as successful charges, failed invoice payments, and available reconciliation reports. Because Stripe retains events for 13 months but exposes older events than 30 days only as summaries, Amazon EventBridge can route them into an AWS account and Amazon CloudWatch Log Groups can provide longer-term monitoring and analysis. The setup uses CloudWatch metric filters to match event types such as invoice.payment_failed, convert matches into custom metrics, and support alarms, Amazon SNS notifications, dashboards, and Logs Insights queries. For example, a failed-invoice alarm can use a five-minute observation period, Sum statistics, and a threshold based on expected failure volume or anomaly detection. The resulting setup supports near-real-time visibility into successful charges and failed payments, historical trend analysis, troubleshooting, and responses to unusual activity.
The article examines how applications should store and access product data in simple Stripe integrations as requirements for security, performance, and scalability evolve. It compares using Stripe’s built-in product fields with a separate database, while explaining that publishable API keys cannot retrieve product details and that secret or restricted keys must remain server-side. A web backend or serverless function can proxy requests securely, while CloudFront caching reduces repeated calls and latency but requires an appropriate refresh cadence. For richer metadata, inventory, variants, or custom attributes, the article describes combining DynamoDB with Lambda and Stripe, using Event Destinations or webhooks to synchronize changes and weighing that flexibility against database overhead.
The best engineering reads, once a week.
