<\/p>\n\n\n\n
Migrating from Google Cloud (Cloud Run + GKE) to AWS EKS while serving users from both environments requires careful planning. The goal is to gradually shift traffic to AWS<\/strong> without service interruption, confirm stability on EKS, then fully cut over \u2013 all while maintaining zero downtime<\/strong>. The domain\u2019s DNS is hosted on Google Cloud DNS (with zones for prod, stage, uat), and this will remain unchanged. We need a strategy that allows hybrid traffic routing<\/strong> (to GCP and AWS) during the transition, smoothly migrates<\/strong> users to AWS, and provides instant failover<\/strong> if any backend is unhealthy.<\/p>\n\n\n\n Key requirements and challenges:<\/p>\n\n\n\n To meet these goals, we\u2019ll explore DNS-based routing<\/strong> options, global load balancers<\/strong>, and service mesh\/API gateway<\/strong> approaches. Each offers trade-offs in complexity, control, and reliability. Below is a comprehensive guide with recommendations, architecture considerations, and example configurations for each approach.<\/p>\n\n\n\n One of the simplest multi-cloud routing methods is to leverage DNS policies. Google Cloud DNS supports advanced routing policies like Weighted Round Robin (WRR)<\/strong> and Geolocation<\/strong> routing, similar to AWS Route 53. This allows the authoritative DNS server to decide which backend\u2019s IP to return for a client\u2019s query.<\/p>\n\n\n\n 1. Weighted DNS (Canary\/Gradual Cutover):<\/strong> With a weighted DNS policy, you create multiple DNS records for the same name, each pointing to a different backend (GCP or AWS) and assign a weight to each. Traffic is distributed in proportion to these weights<\/strong> \u2013 for example, 80% of DNS responses resolving to the GCP IP, 20% to the AWS IP (DNS routing policies for geo-location & weighted round robin | Google Cloud Blog<\/a>) (Best Practices for Zero Downtime Migration to AWS | ClearScale<\/a>). By adjusting weights over time, you can smoothly shift load to AWS:<\/p>\n\n\n\n Google Cloud DNS\u2019s weighted round-robin policy makes this possible natively. For example, you could configure TTL and Caching Considerations:<\/strong> DNS-based steering relies on clients periodically querying DNS. To minimize lag during changes, use a low TTL<\/strong> on these records (e.g. 30 seconds) during the migration (Best Practices for Zero Downtime Migration to AWS | ClearScale<\/a>). Lower TTL ensures that when you adjust weights or switch traffic, clients will pick up new DNS answers quickly. (Be aware that some ISPs or resolvers might not strictly honor very low TTLs, and browsers\/device caches could retain DNS entries for longer (Best Practices for Zero Downtime Migration to AWS | ClearScale<\/a>).<\/em>) It\u2019s wise to lower the TTL well before<\/strong> the migration starts, so that by the time you make weight changes most clients are already using the low TTL setting (Best Practices for Zero Downtime Migration to AWS | ClearScale<\/a>).<\/p>\n\n\n\n High-Level DNS Setup:<\/strong> In Cloud DNS, you would create a resource record set for the service domain with a WRR (Weighted Round Robin) routing policy<\/strong>. For example:<\/p>\n\n\n In this hypothetical example, Health Checks & Failover:<\/strong> Basic DNS round-robin by itself doesn\u2019t automatically detect outages \u2013 if the GCP service goes down while still in DNS, some clients might get that IP until TTL expires. To mitigate this, Cloud DNS also supports a Failover<\/strong> routing policy and can integrate health checks for DNS endpoints (Global Load Balancer Approaches<\/a>) (Global Load Balancer Approaches<\/a>). One approach is to combine policies: for example, use weighted routing with health checks<\/strong> on each record. Google Cloud DNS health-checking can detect if the GCP or AWS endpoint is down and stop returning its IP (Global Load Balancer Approaches<\/a>). Another approach is to use DNS failover policy<\/strong> once you reach the final cutover: designate AWS as primary and GCP as secondary (failover target). During the hybrid period, though, weighted policies with manual control are typically used (since you want<\/em> both active). Keep TTL low so even if one backend fails, you can quickly adjust weights to 0 for that backend (or rely on the health-check to remove it).<\/p>\n\n\n\n Geo-Location DNS (optional):<\/strong> In addition to weighting, Google Cloud DNS allows geo-based policies (DNS routing policies for geo-location & weighted round robin | Google Cloud Blog<\/a>). If your user base is regionally divided or if the GCP and AWS clusters are in different regions, you could route users to the nearest cloud. For example, during migration<\/em> you might direct EU customers to GCP and US customers to AWS (or vice versa) using Geo DNS, gradually expanding the geo coverage of AWS as confidence grows. Geo policies can also ensure optimal latency by keeping users on the closest service (Global Load Balancer Approaches<\/a>) (DNS routing policies for geo-location & weighted round robin | Google Cloud Blog<\/a>). However, in this scenario (gradual migration) weighted routing is more straightforward for splitting traffic globally. Geo-DNS could be combined with weights (e.g. weighted within each region), but Cloud DNS does not<\/strong> allow combining geo and custom weights simultaneously on the same record set (Configure DNS routing policies and health checks | Google Cloud<\/a>). So you\u2019d typically choose one strategy or the other. Weighted routing is usually sufficient unless you have multi-region deployments in both clouds.<\/p>\n\n\n\n Pros & Cons of DNS Steering:<\/strong><\/p>\n\n\n\n In practice, weighted DNS is a great low-complexity approach<\/strong> to achieve near zero-downtime migration. Many organizations use it for cloud migrations \u2013 for example, gradually shifting 5% of traffic at a time (Best Practices for Zero Downtime Migration to AWS | ClearScale<\/a>). As long as both old and new services run in parallel and serve identical content\/APIs, end-users will not notice the difference. Just be sure to monitor both environments closely during the shift (e.g. compare error rates, latencies) and plan for how to quickly react if the new environment has issues (e.g. set AWS weight back to 0 or remove that record).<\/p>\n\n\n\n An alternative (often more sophisticated) method is to put a global load balancing layer<\/strong> in front of your services. Instead of relying on DNS to make the routing decision, a global load balancer can accept user traffic at a single entry point and then proxy it to either GCP or AWS backends. This can provide faster failover, detailed traffic control (at the request level), and shielding users from any DNS propagation delays.<\/p>\n\n\n\n (Load Balancing with Weighted Pools<\/a>) Example of a global load balancer splitting traffic 80\/20 between two origin pools (e.g., one in a data center and one in cloud). A similar approach can route users to GCP or AWS backends based on assigned weights.<\/em><\/p>\n\n\n\n Two primary options in this category are Google Cloud HTTP(S) Load Balancing<\/strong> (with hybrid backends) and AWS Global Accelerator<\/strong>. We\u2019ll also mention third-party anycast networks (like Cloudflare) as an option.<\/p>\n\n\n\n Google Cloud\u2019s external Application Load Balancer (HTTP(S) LB) is a global, Anycast load balancer that can distribute traffic across multiple regions \u2013 and even across different backend types. You can leverage it to route traffic to both your GCP services and<\/strong> AWS services during the migration:<\/p>\n\n\n\n Architecture Diagram \u2013 GCP LB Hybrid:<\/strong> Imagine this setup: the DNS for From the client perspective, they are always talking to one host\/IP (the LB). This indirection adds a bit of overhead (requests to AWS now go through Google\u2019s infrastructure first), but it gives strong control. Google\u2019s LB also supports features like Cloud CDN, Cloud Armor (WAF), etc., which you could use to enhance security\/performance during the transition.<\/p>\n\n\n\n Traffic Shifting with LB:<\/strong> Initially, you configure the LB to send 0% to AWS (all traffic to Cloud Run\/GKE). Then as EKS comes online, start with a small percentage to the AWS backend service. Google\u2019s traffic management supports very fine-grained splits (even 1% if desired) (Application Load Balancer overview | Load Balancing | Google Cloud<\/a>). Increase AWS share gradually until it\u2019s 100%. At that point, you could even remove the GCP backend from the LB. The DNS doesn\u2019t need to change at cutover at all \u2013 it was already pointing to the LB, so users notice nothing. Essentially, the cutover happens inside the LB configuration.<\/p>\n\n\n\n Zero Downtime and Testing:<\/strong> During this process, the LB ensures no downtime: it will only send traffic to healthy backends and you can adjust weights without interrupting existing connections. You can test AWS in production with a small trickle of real traffic. If any problem is detected, simply dial the AWS backend weight down (even to 0%) and the LB will immediately stop sending new requests there. This offers a very fast rollback mechanism (faster than waiting for DNS TTLs to expire) (Introduction to AWS Global Accelerator – Whizlabs Blog<\/a>) (Introduction to AWS Global Accelerator – Whizlabs Blog<\/a>).<\/p>\n\n\n\n Costs and Complexity:<\/strong> Introducing a global load balancer has some overhead. There are GCP costs for LB bandwidth\/requests, and configuring the LB (especially with an Internet NEG to AWS) is a bit more work than just adding DNS records. You also need to ensure the AWS service is exposed publicly<\/strong> in a way the GCP LB can reach \u2013 likely through an AWS ALB or NLB with a public IP. One common pattern is to use an AWS Network Load Balancer with a static Elastic IP, so you have a stable IP for the NEG target. Alternatively, use the AWS ALB\u2019s hostname in a \u201cfully qualified domain name (FQDN) NEG\u201d (the GCP Internet NEG can point to a domain name and will resolve it). Make sure to allow the LB\u2019s health check IPs<\/strong> and traffic through any firewalls (the GCP LB uses Google Front Ends that will connect from Google IP ranges).<\/p>\n\n\n\n Lifecycle:<\/strong> Once the migration is done and AWS is serving 100%, you have a choice: you could keep the GCP LB in place permanently (still directing everything to AWS). Some teams do this for a period to allow an easy fallback. Eventually, though, you might decide to simplify by pointing DNS directly to the AWS ALB and removing the GCP LB from the path (to reduce an extra network hop). That final DNS change can be done at a convenient time since the AWS backend is already handling all traffic \u2013 or you might even continue to use the GCP LB as a layer of indirection if it offers value (e.g., using Cloud Armor WAF in front of AWS). It\u2019s up to your architecture preferences.<\/p>\n\n\n\n Summary of Pros:<\/strong> The global LB approach provides fine-grained control and fast failover<\/strong>. Weight changes take effect immediately on new requests (no waiting for DNS). Health checks make it safer \u2013 failing backends are automatically removed from rotation (Introduction to AWS Global Accelerator – Whizlabs Blog<\/a>). You also get centralized logging and monitoring of all traffic in one place (the LB), which can simplify observing the cutover. And clients only ever see one IP\/endpoint, which can avoid certain DNS sticking issues or cross-origin concerns.<\/p>\n\n\n\n Cons:<\/strong> The main downsides are the added complexity and potential performance impact for cross-cloud calls. For example, if a user and the AWS cluster are in the same region (say both in us-east) but the GCP LB node handling the request is in a different region (or routes inefficiently), you could introduce a slight latency penalty. In practice, Google\u2019s network is very optimized, and any extra latency is usually small (tens of milliseconds). Another consideration is stateful sessions<\/strong>: if your LB does not have session affinity and you are switching traffic gradually, a user might bounce between GCP and AWS across requests (unless you enable session affinity on the LB by cookie or IP \u2013 though note that Google\u2019s weighted traffic splitting does not combine with session affinity<\/strong>; if you set affinity, it might override the weights (Traffic management overview for global external Application Load Balancers | Load Balancing | Google Cloud<\/a>)). If session stickiness is needed, you might use a different strategy (like route all users of a certain cohort to one side using a header or path). For mostly stateless services or API calls, this isn\u2019t an issue.<\/p>\n\n\n\n In short, using the Google Cloud global load balancer for migration is a powerful approach that essentially gives you \u201ccloud-agnostic\u201d traffic management<\/strong>: you decouple the user-facing endpoint from the underlying cloud. It requires setup, but it ensures absolutely minimal disruption during the migration.<\/p>\n\n\n\n AWS Global Accelerator (GA) is another global traffic management service, but it operates at the network layer. GA provides you with a pair of stable anycast IP addresses that edge locations announce globally. It then routes traffic from those edges to designated endpoint groups<\/strong> in AWS (which can be regional load balancers, EC2 instances, etc.). GA supports weighting traffic between AWS regions using a feature called the traffic dial<\/strong> \u2013 for example, splitting 70\/30 between two AWS regions (Introduction to AWS Global Accelerator – Whizlabs Blog<\/a>). It also monitors health and will fail over if an endpoint goes unhealthy.<\/p>\n\n\n\n In the context of a GCP-to-AWS migration, AWS GA could be useful after<\/strong> most traffic is in AWS (especially if you plan multi-region deployments in AWS for high availability). However, GA by itself can\u2019t directly split traffic between AWS and GCP, because its endpoints must be AWS resources. One theoretical approach would be to have one GA endpoint group in an AWS region for the EKS cluster, and another endpoint group that points to an AWS resource which forwards to GCP (e.g., an EC2 instance proxying to GCP). This is generally not worth the complexity \u2013 essentially it means hairpinning GCP traffic through AWS.<\/p>\n\n\n\n So, while Global Accelerator is great for multi-region AWS traffic management<\/strong> (and could be part of your end-state architecture for AWS-only, ensuring low latency globally and quick failover across regions), it\u2019s not typically used to manage a hybrid cloud cutover. We mention it for completeness because it\u2019s an example of an anycast load balancer similar in concept to Google\u2019s, but tied to AWS. If in the final state you need global IPs for your service and multi-region resilience, you might deploy GA once you\u2019re fully on EKS, but during the migration, other methods (DNS or GCP\u2019s LB) are more straightforward for cross-cloud balancing.<\/p>\n\n\n\n Beyond cloud-native solutions, there are providers like Cloudflare<\/strong>, Akamai<\/strong>, Fastly<\/strong>, or F5\/Citrix ADC<\/strong> that offer global load balancing as a service (Global Load Balancer Approaches<\/a>). For example, Cloudflare\u2019s Load Balancer can sit at the DNS\/proxy level and distribute traffic between multiple origins (which could be GCP and AWS) with weights, health checks, geo-steering, etc. This can be very effective: Cloudflare\u2019s network will direct users to whichever origin you configure (they support session affinity and fine routing rules as well).<\/p>\n\n\n\n To use Cloudflare in this way, you would typically delegate your DNS to Cloudflare or at least configure your domain to proxy through Cloudflare\u2019s CDN. Since the question states DNS stays on Google Cloud, switching to Cloudflare DNS may not be desired. However, you could still use Cloudflare by making Pros:<\/strong> Third-party solutions can be cloud-agnostic and very feature-rich. For instance, you could set up health checks from multiple continents, do latency-based routing (serve each user from whichever cloud is faster for them), or even do per-user sticky routing (like send a particular user ID consistently to one backend). Cloudflare\u2019s example in the embedded diagram above shows how weights can be adjusted to quickly shift load when one origin pool is scaled up (80\/20 split) (Load Balancing with Weighted Pools<\/a>) (Load Balancing with Weighted Pools<\/a>).<\/p>\n\n\n\n Cons:<\/strong> The downside is you\u2019re adding another external dependency and potentially cost. Also, using a third-party means your traffic flows through their network (for Cloudflare in proxy mode, traffic goes through Cloudflare POPs). This can actually improve performance (due to caching and faster routes), but it\u2019s a change to consider. Since our primary focus is using the existing cloud providers, a third-party LB is an option if neither Cloud DNS nor GCP\/AWS native solutions meet a requirement you have (for example, if you needed true latency-based routing across clouds, a service like Cloudflare LB or Cedexis would be needed, as Cloud DNS doesn\u2019t do latency measurements).<\/p>\n\n\n\n In summary, a global load balancer approach adds an abstraction layer<\/strong> that can greatly smooth out the migration. It\u2019s often used in enterprise multi-cloud deployments. If your team is comfortable setting it up, it provides the most control and safety (at the cost of some complexity).<\/p>\n\n\n\n A third approach involves the application layer routing<\/strong> rather than DNS or a global LB. This typically means deploying either a shared API gateway or using a service mesh<\/strong> that spans both environments.<\/p>\n\n\n\n Service mesh technologies (like Istio<\/strong>, Linkerd<\/strong>, or Consul<\/strong> mesh) can be used to route traffic between services across clusters. If you have the same application deployed on GKE and EKS, you could establish a mesh that includes both clusters and then use mesh routing features (layer 7 routing) to control traffic splitting. For example, Istio\u2019s VirtualService<\/strong> resource can be configured to send X% of requests to one service version and Y% to another \u2013 even if those \u201cversions\u201d live in different clusters. Projects like Istio Multi-Cluster<\/strong> or Gloo Mesh<\/strong> allow tying two Kubernetes clusters together in one logical mesh. You\u2019d typically need network connectivity between the clusters (VPN or VPC peering across clouds) so that services can talk to each other. With that in place, you can deploy a common control plane or a federated service mesh configuration.<\/p>\n\n\n\n How it would work:<\/strong> You might expose the service on GKE (mesh ingress gateway) and also on EKS (mesh gateway). You then configure the mesh so that when requests hit the ingress, it can split them: e.g., 90% to local service (GKE pods) and 10% forwarded to the EKS service (via the mesh\u2019s cross-cluster communication). As you gain confidence, you adjust the weights in the VirtualService to send more to EKS. Eventually, you send 100% to EKS, and you could even switch the DNS to point directly to the EKS ingress at that time. This is essentially a layer 7 load balancing done by the service mesh sidecar proxies<\/em>.<\/p>\n\n\n\n Pros:<\/strong> This approach keeps the traffic management in the application layer, which means you have full context of requests (you can do routing based on HTTP headers, etc., beyond just percentages). It also doesn\u2019t rely on public DNS or public load balancers \u2013 the clusters could be connected privately. It\u2019s a very powerful technique if you already use a service mesh, because you can leverage the same tools for canarying that you use within one cluster but now across clusters. For instance, Istio can even mirror traffic to the new deployment or do gradual rollouts with rich telemetry.<\/p>\n\n\n\n Cons:<\/strong> However, implementing a multi-cloud service mesh is non-trivial<\/strong>. You need to set up secure connectivity between GCP and AWS (like a direct VPN or use Istio\u2019s mesh VPN capabilities) and ensure service discovery works across clouds. There is also a learning curve and operational overhead to running a service mesh across two environments. If you do not already have a mesh, introducing one just for the migration may be overkill. Meshes also typically assume a relatively stable set of connectivity; using them for a one-time migration might be more work than benefit, unless you want to adopt a mesh long-term for multi-cloud operations.<\/p>\n\n\n\n In most cases, DNS or global LB solutions are simpler for a short-term migration. That said, if your architecture is microservices-heavy and you foresee staying hybrid for a while, a service mesh could provide a consistent way to manage traffic splitting, security (mTLS between clouds), and monitoring.<\/p>\n\n\n\n Another application-layer approach is to use an API Gateway<\/strong> as the unified front-end. This could be a cloud-managed gateway or a self-hosted one:<\/p>\n\n\n\n The API gateway approach, like the service mesh, gives you a lot of flexibility (you can do things like auth, transformations, etc., in one place during the migration). But again, you are introducing a new component that must be highly available itself. It can become a bottleneck or single point of failure if not done carefully.<\/p>\n\n\n\n When to consider mesh\/gateway:<\/strong> If your system already uses an API gateway layer, then extending it to handle multi-cloud can make sense. Or if you require advanced routing logic (say only certain users go to the new environment \u2013 e.g., internal beta testers \u2013 which could be done by gateway inspecting a header or cookie), an app-layer solution is needed. Otherwise, for pure load distribution, DNS or LBs are typically easier.<\/p>\n\n\n\n Regardless of which approach you choose, here are some best practices<\/strong> to ensure zero or minimal downtime:<\/p>\n\n\n\n By following these practices, you can achieve a zero-downtime migration<\/strong>. In fact, users should not even notice the transition if done correctly. Many companies have done cloud-to-cloud migrations in this fashion (weighted DNS or L7 splitting) without their users ever being aware of the backend move. The combination of careful traffic management and comprehensive monitoring is key to success (Best Practices for Zero Downtime Migration to AWS | ClearScale<\/a>) (Application Load Balancer overview | Load Balancing | Google Cloud<\/a>).<\/p>\n\n\n\n Considering the scenario (DNS in Google Cloud, services in Cloud Run\/GKE moving to EKS), a two-phase approach<\/strong> might work best:<\/p>\n\n\n\n In either case, planning and testing are crucial<\/strong>. Test the weighted routing in a lower environment (e.g., use stage.example.com with 50\/50 weights and see how the traffic flows). Test failure scenarios (e.g., what happens if the AWS service is down \u2013 does DNS or LB correctly keep traffic on GCP?). Also, test the performance when some users are served from AWS \u2013 ensure your CDN, if any, or client-side logic, works the same against both.<\/p>\n\n\n\n For a concrete example, suppose \n
DNS-Based Traffic Steering<\/h2>\n\n\n\n
\n
app.prod.example.com<\/code> with two A records: one pointing to the GCP load balancer IP, one to the AWS load balancer\u2019s IP, weighted say \u201c0.8=GCP_IP;0.2=AWS_IP\u201d to start (Configure DNS routing policies and health checks | Google Cloud<\/a>). Cloud DNS will dynamically compute which IP to return on each query according to those ratios (DNS routing policies for geo-location & weighted round robin | Google Cloud Blog<\/a>). You can change weights via the API or gcloud CLI as you progress (these changes take effect at the DNS level immediately, though clients respect TTL).<\/p>\n\n\n\ngcloud dns record-sets create app.prod.example.com. --type=A --ttl=30<\/span> \\\n --routing-policy-type=WRR \\\n --routing-policy-data=\"0.8=203.0.113.10;0.2=198.51.100.50\"<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n203.0.113.10<\/code> could be the IP of a Google Cloud Load Balancer fronting Cloud Run\/GKE, and 198.51.100.50<\/code> an IP (or IP range) of an AWS ALB\/NLB fronting the EKS service. Cloud DNS will return the GCP IP ~80% of the time and the AWS IP ~20% (DNS routing policies for geo-location & weighted round robin | Google Cloud Blog<\/a>). Over time, you\u2019d update the routing-policy-data<\/code> weights to shift the percentages. (If using hostnames\/CNAMEs \u2013 e.g. Cloud Run custom domain or ALB DNS name \u2013 Cloud DNS can weight those via CNAME records similarly. However, root\/apex domain cannot use CNAME, so an A\/AAAA with direct IPs or using alias\/ANAME-like features would be needed.)<\/p>\n\n\n\n\n
Global Load Balancer Approach<\/h2>\n\n\n\n
Using Google Cloud External Load Balancer (Anycast Global LB)<\/h3>\n\n\n\n
\n
app.prod.example.com<\/code> to this load balancer\u2019s IP or CNAME. After that, you no longer need to change DNS; all traffic goes to the LB.<\/li>\n\n\n\napp.example.com\/*<\/code>) and attach two backend services to that route: Backend A (GCP) with weight 95, Backend B (AWS) with weight 5 to start. The LB will then route 5% of requests to AWS and 95% to GCP<\/strong>, at the HTTP request level (Application Load Balancer overview \u00a0|\u00a0 Load Balancing \u00a0|\u00a0 Google Cloud<\/a>). This is analogous to weighted DNS, but the balancing is done by the LB on each request, not by DNS responses. You can gradually adjust these weights over time using gcloud or the GCP console, just like with DNS policies. The difference is the LB makes the decision for each incoming request<\/em> in real time.<\/li>\n\n\n\napp.prod.example.com<\/code> resolves to a Global LB IP<\/strong> (anycast). A user\u2019s request goes to the LB, which then decides where to forward it:<\/p>\n\n\n\n\n
AWS Global Accelerator<\/h3>\n\n\n\n
Third-Party Global Load Balancers (Cloudflare, etc.)<\/h3>\n\n\n\n
app.example.com<\/code> a CNAME to a Cloudflare-managed domain that does the load balancing (Cloudflare allows weighted pools as we saw). Similar capabilities exist in other DNS services like NS1 or Dyn Traffic Director \u2013 they sit between the user and your origin servers.<\/p>\n\n\n\nService Mesh \/ API Gateway Approach<\/h2>\n\n\n\n
Multi-Cloud Service Mesh<\/h3>\n\n\n\n
API Gateway<\/h3>\n\n\n\n
\n
Ensuring Zero Downtime During Cutover<\/h2>\n\n\n\n
\n
Recommendation and Example Strategy<\/h2>\n\n\n\n
\n
api.prod.example.com<\/code> is currently an A record pointing to a Cloud Run custom domain (which maps to some Google front-end). You want to introduce the AWS EKS service which is exposed via an Amazon ALB (say URL eks-prod-123.us-east-1.elb.amazonaws.com). Here\u2019s how you might proceed:<\/p>\n\n\n\n\n