When trying to send mail with nodemailer library inside Firebase Cloud Function. I'm getting error:
Billing account not configured. External network is not accessible and quotas are severely limited. Configure billing account to remove these restrictions
I'm on Blaze (Pay as you go) plan.
I have same errors recently due to an expirated card, so i replace with fresh new card but errors persist Billing account not configured. External network is not accessible and quotas are severely limited. Configure billing account to remove these restrictions
So i revert to Spark plan and return to Blaze Plan
After that all it's working
Related
I see that the AWS Billing service was not included into the Golang SDK
We need to make a Lambda to connect with this service and collect the monthly billing to make a dashboard.
How can we do that ?
Regards
The go sdk's cost explorer package gives access to the aws cost explorer api:
You can use the Cost Explorer API to programmatically query your cost and usage data
I tried to create a new logging instance on LogDNA service on IBM cloud , although I chose lite plan
It is always failing with error message
Your account does not allow the use of non-lite plans. You can upgrade by adding a credit card to your account or you can select the lite plan if it's available.
This is a bug, it is being addressed. You could work around this by upgrading your account with a credit card. No charges will be assessed for the free lite plan for the logging with logdna service. Or you can wait for the problem to be addressed.
I am trying to setup Just in Time Access in Azure, so I have an account with subscription where I've enabled Security Center Standard edition (required for JIT). I've created there a Resource Group and a VM.
Now I took another account (let's call it a2#foo.com) and I've given it Reader privileges on the mentioned Resource Group and Contributor on VM and its Network Security Group.
After logging to the portal, a2#foo.com doesn't have access to JIT, because Subscriptions it owns don't have Security Center Standard enabled - these are separate subscriptions than the one mentioned earlier (so it's not possible to request JIT through the portal).
When I use PowerShell, I am able to select subscription where VM is deployed (Select-AzureRmSubscription), I am able to see that there is a JIT policy used there (Get-ASCJITAccessPolicy), but when I run Invoke-ASCJITAccess I get an error:
Invoke-ASCJITAccess : JIT VM Access requires a Standard tier subscription. For more info please visit aka.ms/asc-jit
Am I missing something or Just In Time Access works only on subscriptions you own?
Setting Contributor role for user a2#foo.com on the Resource Group solved the problem and this user is able to request JIT Access through PowerShell (not through portal).
I would like to use the dedicated bluemix for a streaming analytics POC. When I try to create the service I get this message.
The service instance cannot be created because paid service plans are not allowed.
What can I do to address.
Thanks,
j
You probably have a Bluemix free trial account.
With a free account you are limited to create services that offer a free plan only.
If you are trying to create a service from a paid plan you need to upgrade your account to a paid account.
You can see different types of accounts in the link below:
https://console.ng.bluemix.net/docs/pricing/index.html#pricing
I would like to find out what the best practices are for managing developers' access to a sub-set of resources on a client's subscription?
I've searched Google and the Azure documentation looking for definitive answers, but I have yet to come across an article that puts it all together. Because Azure is still developing so rapidly I often find it difficult to determine whether a particular article may still be relevant.
To sum up our situation:
I've been tasked with researching and implementing the Azure infrastructure for a web site our company is developing for a client. At the moment our manager and I have access to the client's entire subscription on the Azure Portal by means of the Service Administrator's credentials, even though we're managing only:
Azure Cloud Service running a Web-Role (2-instances with Production and Staging environments).
Azure SQL Database.
Azure Blob Storage for deployments, diagnostics etc.
We're now moving into a phase where more of the developers in the team will require access to perform maintenance type tasks such as performing a VIP swap, retrieving diagnostic info etc.
What is the proper way to manage developer's access on such a project?
The approach I've taken was to implement Role Based Access Control (https://azure.microsoft.com/en-us/documentation/articles/role-based-access-control-configure/)
Move 1, 2, and 3 above into a new Resource Group according to http://blog.kloud.com.au/2015/03/24/moving-resources-between-azure-resource-groups/
Creating a new User Group for our company, say "GroupXYZ".
Adding the "GroupXYZ" to the Contributor role.
Adding the particular developer's company accounts to "GroupXYZ"
Motivation for taking the role-based approach
From what I understand giving everyone access as a Co-Administrator would mean that they have full access to every subscription in the portal.
Account-based authentication is preferable to certificate-based authentication due to the complexity added by managing the certificates.
What caused me to question my approach was the fact that I could not perform a VIP swap against the Cloud Service using PowerShell; I received an error message stating that a certificate could not be found.
Do such role-based accounts only have access to Azure by means of the Resource Manager Commandlets?
I had to switch PowerShell to the Azure Service Manager (ASM) Mode before having access to the Move-AzureDeployment commandlet.
Something else I'm not sure of is whether or not Visual Studio will have access to those resources (in the Resource Group) when using Role Based Access Control.
When you apply RBAC to Azure as you have or just in general, give access to an account via RBAC, then those accounts can only access Azure via the Azure Resource Manager APIs, whether that's PowerShell, REST or VS.
VS 2015 can access Azure resources via RBAC when using the 2.7 SDK. VS 2013 will have support for it soon.