Simplifying Multi-Cloud Serverless Telemetry with CloudWatch Bearer Token Auth

AWS has introduced Bearer token authentication support for Amazon CloudWatch OpenTelemetry Protocol (OTLP) endpoints, allowing serverless runtimes and external workloads across multiple cloud environments to stream metrics and structured logs directly over HTTPS without AWS-specific SDKs or complex signature signing. ### What Happened In a technical update, AWS detailed native Bearer token authentication for CloudWatch OTLP ingestion endpoints, currently supporting metrics and logs. Traditionally, exporting telemetry from compute resources running in external clouds—such as Google Cloud Functions or Azure Functions—to Amazon CloudWatch required configuring AWS IAM credentials, managing cross-cloud credential rotation, and signing every request using AWS Signature Version 4 (SigV4). The new capability replaces this overhead with standard `Authorization: Bearer <token>` HTTP headers, enabling ephemeral and serverless runtimes anywhere to export OpenTelemetry-compliant telemetry directly to CloudWatch without dedicated collector agents or proprietary client libraries. ### Why It Matters Multi-cloud serverless architectures present unique operational challenges: functions are ephemeral, lack background daemons or sidecars, and cannot reliably host persistent telemetry collectors. Requiring proprietary cloud SDKs or intricate cross-cloud IAM role federation just to ship basic logs and performance metrics inflated function package sizes, added cold-start latency, and created significant maintenance burdens. For DevOps engineers, platform teams, and SREs managing distributed microservices across clouds, this approach streamlines ingestion pipelines and eliminates the infrastructure overhead of standing up separate collector tiers. ### The Broader Context This update aligns with a wider industry shift toward adopting vendor-neutral open standards, particularly OpenTelemetry, while cloud providers compete to become the primary operations control plane. Rather than forcing workloads into proprietary logging formats or heavy client dependencies, hyperscalers are treating OTLP and HTTP-standard token authentication as first-class citizens. This interoperability push mirrors broader efforts across the multi-cloud ecosystem to reduce operational silos and standardize observability across diverse environments. ### Practical Implications and Next Steps Practitioners operating multi-cloud serverless applications should account for key operational tradeoffs: - **Token Management**: Generate and scope Bearer tokens per signal type (metrics vs. logs) and store them securely within each provider's native secrets management solution (such as Azure Key Vault or Google Secret Manager) to load during execution initialization. - **Trace Support Gaps**: Because Bearer token authentication currently applies to metrics and logs rather than distributed traces, end-to-end request tracing still requires standard collector topologies or native tooling until trace endpoints gain token auth support. - **Semantic Standardization**: Enforce OpenTelemetry semantic conventions across all serverless functions to ensure query consistency and reliable correlation across multi-cloud logs and metrics in CloudWatch.