Title:
Cosmos DB | Update Add Account Pipeline to Configure 7-Day Continuous Backup in Lower Environments

Story:
As a developer,
I want to update the Cosmos DB add account pipeline to configure continuous backup with 7-day retention for lower environments,
so that new Cosmos DB accounts remain compliant with the backup policy before it is moved from Audit mode to Deny mode.

Description:
A backup-related policy has recently been implemented in Audit mode for Cosmos DB. Before this policy is moved to Deny mode, the add Cosmos account pipeline needs to be updated to ensure that Cosmos DB accounts created in lower environments are configured with continuous backup using 7-day retention.

This change will help avoid future policy non-compliance and prevent account creation failures once the policy enforcement is changed to Deny.

Scope:

• Review the current add Cosmos account pipeline.
• Identify where backup configuration is handled during account creation.
• Update the pipeline to configure continuous backup with 7-day retention for lower environments.
• Validate the change in applicable lower environments.
• Capture test evidence and update issue comments.

Acceptance Criteria:

• Add Cosmos account pipeline is updated with 7-day continuous backup configuration for lower environments.
• Backup policy compliance is validated after pipeline change.
• Testing evidence is added to the issue.
• Any dependency or blocker is documented.
• Change is ready before policy moves from Audit to Deny mode.

Impacted Product:
Azure Cosmos DB

Impacted Environments:
Dev, Test, UAT / lower environments

Dependency:
Pipeline / Control Plane / Policy implementation, as applicable.

Posted By Nikhil07:43

0

Continue Reading

 Thank you Murali, appreciate your support and guidance. I’m also trying to stay aligned across Oracle, PostgreSQL, Azure and Emerging DB topics, so happy to share any context that helps the team.

Posted By Nikhil07:59

0

Continue Reading

 

You can reply warmly but professionally like this:

Thanks Murali, appreciate your support.

Likewise, I am also learning and catching up as we move across Oracle, PostgreSQL on-prem, Azure, and now Emerging DB topics. Since our paths have crossed across these areas, I’m happy to share whatever context I have and keep things aligned wherever possible.

Thanks again.

Posted By Nikhil07:58

0

Continue Reading

 Before progressing RFC14049525, can we please revalidate the actual requirement and DBA ownership?

This appears to be related to synonym execution/creation, which is normally an application object activity and not something DBA should execute in this environment unless there is a formally agreed exception.

Also, before assigning such RFCs to DBAs, especially over the weekend, please ensure the requirement is reviewed properly and the DBA scope is clear.

Thanks.

Posted By Nikhil07:47

0

Continue Reading

 

Hi Ajinkya,

Thanks for highlighting this.

We are aware of the AMR capacity situation across the mentioned Azure regions. Microsoft has also acknowledged the concern in our recent discussion, and we are awaiting their detailed plan/next steps.

In the meantime, could you please confirm if the suggested mitigation options have been tried from your side, such as retrying the provisioning, trying during off-peak hours, checking alternate SKU options, or validating if another region can be used where workload requirements allow?

Once we receive further guidance from Microsoft, we will share the update accordingly.

Regards,
Nikhil

Posted By Nikhil07:23

0

Continue Reading

 

Please summarize this meeting as a structured Q3 cost-optimization alignment note for Emerging DB.

Include:

1. Key discussion points by product: Azure Cosmos DB, MongoDB vCore, Azure Managed Redis / Redis.
2. Cost-optimization ideas discussed, including SKU right-sizing, autoscale restriction, HA/geo-replica restriction, persistence removal, retention/logging review, unused resource cleanup, policy controls, and lower-environment guardrails.
3. Decisions made during the call.
4. Items agreed as potential Q3 objectives.
5. Items needing further analysis/refinement.
6. Dependencies, risks, or blockers identified.
7. Action items with owner, next step, and target timeline where mentioned.
8. Any open questions for PO or engineers.

Keep the summary concise, professional, and suitable to share with the team after the meeting.

Posted By Nikhil21:39

0

Continue Reading

 Do we have cost visibility around this

Are queries consuming high RUs due to poor filters or cross-partition scans?

Review oversized Redis/AMR instances.

Review Mongo vCore cluster sizing and usage patterns to ensure compute, storage, backup, and environment configuration are aligned with actual workload needs.

Do we have idle or rarely used clusters?

Is storage growing due to unused or test data?

Are diagnostic settings consistent across products?

Review diagnostic logging, metrics, and retention configuration to avoid unnecessary monitoring cost .

uncontrolled logging becomes expensive.

Do any Emerging DB non-prod resources support scheduled scale-down or reduced capacity during non-business hours?”

Objective: Review whether Cosmos containers are indexing all fields unnecessarily.

Why it matters: excessive indexing can increase RU consumption during writes.

“Can we review if Cosmos indexing policies are optimized, especially for containers with heavy write activity?”

Can we review memory utilization versus allocated SKU for Redis/AMR and identify right-sizing opportunities?”

Policy expiration review

Where we allow high SKU, HA, autoscale, persistence, or geo-replication by exception, can we add review/expiry so exceptions don’t stay forever?

Can we define standard lower-environment templates for Cosmos, vCore, and AMR so teams don’t accidentally provision production-like configurations?

Posted By Nikhil21:32

0

Continue Reading