please I have amazon-connect instances in a specific region, and I want to implement failover, like I wanna make my amazon-connect instances multi-region or multi-AZ , so that if the primary region failed , the secondary instances from the other region can pick-up the workload easily without downtime?
You don't need to do anything, Amazon takes care of Connect resiliancy as part of the service. See: https://docs.aws.amazon.com/connect/latest/adminguide/reliability-bp.html
Amazon Connect Global Resiliency provides a set of APIs that you use to:
Provision a linked Amazon Connect instance in another AWS Region.
Provision and manage phone numbers that are global and accessible in both Regions.
Distribute telephony traffic between the instances and across Regions in 10% increments.
For example, you can distribute traffic 100% in US East (N. Virginia) / 0% in US West (Oregon), or 50% in each Region.
Access reserved capacity across Regions.
https://docs.aws.amazon.com/connect/latest/adminguide/setup-connect-global-resiliency.html
Related
We are currently operating a backend stack in central europe, Japan and Taiwan and are perparing our stack to transition to docker swarm.
We are working with real time data streams from sensor networks to do fast desaster warnings which means that latency is critical for some services. Therefore, we currently have brokers (rabbitmq) running on dedicated servers in each region as well as a backend instance digesting the data that is sent accross these brokers.
I'm uncertain how to best achieve a comparable topology using docker swarm. Is it possible to group nodes, let's say by nationality and then deploy a latency critical service stacks to each of these groups? Should I create separate swarms for each region (feels conceptually contradictory to docker swarm)?
The swarm managers should be in a low latency zone. Swarm workers can be anywhere. You can use a node label to indicate the location of the node, and restrict your workloads to a particular label as needed.
Latency critical considerations on the container-to-container network across large regional boundaries may be relevant depending on your required data path. If the only latency-critical data path is to the rabbitmq service that is external to the swarm, then you won't need to worry about the container-to-container latency.
It is also a valid pattern to have one swarm per region. If you need to be able to lose any region without impacting services on another region, then you'd want to split it up. If you have multiple low latency regions, then you can spread the master nodes across those.
I have a fully managed Google Cloud Run service running in Frankfurt. I was not able to choose a zone but only a region, so I took "europe-west3". For my Google Cloud SQL server I can and have to choose a zone. I want to select the same data center for my SQL server and my service to keep the distance short and connections fast but I don't know which zone I should use (a, b, c). Do you know a way to determine which zone fits best to a fully managed Cloud Run Service?
Unfortunetly you cannot choose a Zone to deploy your Cloud Run service, the control goes only until Region. However, this is not something that you should be worried about, as you can see in this documentation:
A zone is a deployment area for Google Cloud resources within a region
That means that even thought the resources might not be in the same Cluster or VM, they are still very close geographically and very likely to be in the same Data Center, and as mentioned in the same documentation:
Locations within regions (Zones) tend to have round-trip network latencies of under <1ms on the 95th percentile.
So you are looking at a very low latency between your resources anyway, to the point that might not even noticible.
For example, my company requires 4 VMs, 2 TB and 256k memory. Which cloud service provider is better for me among AWS, Azure and Google and why?
Do you care about data location, price, security, network, or what?
If you give no information except some random server specs that even say "256k memory", maybe you should just get a cheap server from Hetzner or other bulk VPS provider.
I have a question on inter-zone egress charges on Google Cloud Run (managed). As I understand there is no control over which zones Cloud Run chooses. So potentially when deploying several microservices talking to each other, there could be significant charges.
In kubernetes this can be alleviated via service topology (preferring same zone or even same host if available). Is there anyway to achieve this with Cloud Run?
https://kubernetes.io/docs/concepts/services-networking/service-topology/
According to Cloud Run pricing and internet egress pricing cost stays the same
independent if apps are within the same zone or not.
Now if you plan to have heavy traffic between your apps you should consider using different setup. Either GKE or Cloud Run for Anthos will allow you to setup communication between your apps through internal IP addresses which is free of charge assuming they are in the same zone. Refer to this table.
I'm currently working on a project which has a large amount of IAM users, each of whom need limited access to particular SQS queues.
For instance, let's say I have an IAM user named 'Bob' and an SQS queue named 'BobsQueue'. What I'd like to do is grant Bob full permission to manage his queue (BobsQueue), but I'd like to restrict his usage such that:
Bob can make only 10 SQS requests per second to BobsQueue.
Bob cannot make more than 1,000,000 SQS requests per month.
I'd essentially like to apply arbitrary usage restrictions to this SQS queue.
Any ideas?
From the top of my head none of the available AWS services offers resource usage limits at all, except if built into the service's basic modus operandi (e.g. the Provisioned Throughput in Amazon DynamoDB) and Amazon SQS is no exception, insofar the Available Keys supported by all AWS services that adopt the access policy language for access control currently lack such resource limit constraints.
While I can see your use case, I think it's actually more likely to see something like this see the light as an accounting/billing feature, insofar it would make sense to allow cost control by setting (possibly fine grained) limits for AWS resource usage - this isn't available either yet though.
Please note that this feature is frequently requested (see e.g. How to limit AWS resource consumption?) and it's absence actually allows to launch what Christofer Hoff aptly termed an Economic Denial of Sustainability attack (see The Google attack: How I attacked myself using Google Spreadsheets and I ramped up a $1000 bandwidth bill for a somewhat ironic and actually non malicious example).
Workaround
You might be able to achieve an approximation of your specification by facilitating Shared Queues with an IAM policy granting access to user Bob as outlined in Example AWS IAM Policies for Amazon SQS and monitoring this queue with Amazon CloudWatch in turn by Creating Amazon CloudWatch Alarms for one or more of the Amazon SQS Dimensions and Metrics you want to limit, e.g. NumberOfMessagesSent. Once the limit is reached you could revoke the IAM grant for user Bob for this shared queue until he is in compliance again.
Obviously it is not necessarily trivial to implement the 'per second'/'per-month' specification based on this metric alone without some thorough bookkeeping, nor will you be able to 'pull the plug' precisely when the limit is reached, rather need to account for the processing time and API delays.
Good luck!