amazonaws.com

Amazon Web Services (AWS) è un'organizzazione che offre servizi cloud con funzionalità per sviluppare e gestire applicazioni e altri carichi di lavoro. La sua offerta comprende calcolo, archiviazione, database, analisi, integrazione delle applicazioni e altri ambiti. La distinzione utile è che AWS fornisce molti servizi con scopi diversi, anziché un'unica applicazione con un solo flusso di lavoro.

Il dominio amazonaws.com rappresenta lo spazio dei nomi degli endpoint dei servizi AWS, dove il software può connettersi a singoli servizi e risorse AWS. Il sito informativo pubblico di AWS è aws.amazon.com, quindi il dominio degli endpoint e la homepage promozionale svolgono ruoli diversi. Comprendere questa distinzione aiuta a spiegare perché un'applicazione può contattare amazonaws.com senza che qualcuno stia navigando sul sito AWS.

Che cosa permette di sviluppare e gestire AWS?

AWS è stato lanciato nel 2006 e offre funzionalità cloud che le organizzazioni possono utilizzare per creare e gestire carichi di lavoro. Il materiale ufficiale fornito descrive servizi per eseguire applicazioni, archiviare informazioni, lavorare con database e collegare sistemi distribuiti. Scegliere AWS implica quindi individuare le funzionalità necessarie a un carico di lavoro e comprendere i servizi corrispondenti.

Il catalogo dei servizi illustra questa varietà, senza rendere tutti i servizi intercambiabili. EC2 viene descritto come un servizio che fornisce server virtuali, S3 come un servizio di archiviazione di oggetti e Lambda come un servizio per eseguire codice senza gestire server o cluster. Sono componenti diversi, anche se le applicazioni che li utilizzano possono inviare richieste all'interno della stessa ampia famiglia di domini.

Esigenza del carico di lavoro	Esempi descritti nel materiale AWS fornito	Distinzione pratica
Eseguire carichi di lavoro applicativi	EC2 e Lambda	I servizi di calcolo offrono approcci diversi all'esecuzione del codice.
Archiviare oggetti	S3	L'archiviazione di oggetti ha uno scopo diverso da quello di un database relazionale.
Lavorare con database	RDS e DynamoDB	AWS comprende servizi di database relazionali e NoSQL.
Collegare componenti applicativi	API Gateway, SQS e Step Functions	Accesso alle API, code di messaggi e flussi di lavoro rispondono a esigenze di integrazione diverse.
Analizzare e osservare i carichi di lavoro	Athena e CloudWatch	Interrogare i dati e monitorare le operazioni sono attività distinte.

Questa varietà rende AWS rilevante per chi sviluppa sistemi che richiedono diverse funzionalità cloud all'interno di un carico di lavoro. Comporta anche un'attività di selezione: un'organizzazione deve individuare il servizio, il modello di accesso e le responsabilità operative adatti alla propria applicazione. Un dominio principale familiare non elimina la necessità di queste decisioni.

A cosa serve amazonaws.com?

La documentazione AWS definisce un endpoint come il punto di accesso URL di un servizio web AWS. Molti endpoint utilizzano amazonaws.com come parte del nome host, insieme a informazioni che identificano un servizio e talvolta una Regione AWS. Il software usa questi indirizzi per raggiungere il punto di accesso del servizio pertinente.

Una richiesta a un endpoint AWS può far parte del funzionamento di un'applicazione, anziché essere una visita intenzionale a un sito web. Richieste diverse all'interno del dominio principale possono riguardare servizi, account, risorse e modelli di accesso diversi. Il suffisso condiviso fornisce meno informazioni sul contesto applicativo rispetto alla richiesta completa.

Interpretare l'endpoint di un servizio

L'esempio documentato dynamodb.us-west-2.amazonaws.com contiene informazioni più utili del solo amazonaws.com. Identifica DynamoDB e include il codice di Regione us-west-2. Queste informazioni circoscrivono il contesto del servizio, ma non rivelano tutto sul chiamante o sulla risorsa coinvolta.

• Nome del servizio: aiuta a identificare la funzionalità AWS contattata.
• Codice di Regione: fornisce un contesto regionale quando l'endpoint segue uno schema regionale.
• Nome host completo: conserva distinzioni che si perdono quando un'osservazione viene ridotta al dominio principale.
• Percorso della richiesta: fornisce ulteriore contesto sulla richiesta, da interpretare utilizzando la documentazione del servizio.
• Applicazione richiedente: aiuta a collegare un indirizzo tecnico all'attività prevista da una persona o da un'organizzazione.

Questi dettagli vanno considerati insieme. Il nome host di un servizio è un elemento utile per identificare una destinazione, mentre l'applicazione e la richiesta forniscono il contesto sul motivo per cui quella destinazione viene utilizzata. Né il nome del servizio né il dominio principale stabiliscono, da soli, lo scopo dei dati coinvolti.

Perché alcuni indirizzi AWS includono una Regione?

Molti endpoint AWS contengono un codice di Regione perché forniscono un punto di accesso regionale a un servizio. AWS documenta anche endpoint generali e globali per alcuni servizi. Il comportamento esatto dell'endpoint dipende dal singolo servizio, quindi non si dovrebbe applicare un unico schema di denominazione all'intero catalogo.

Per chi sviluppa, la domanda pratica è quale endpoint sia indicato nella documentazione del servizio scelto per l'operazione prevista. Riconoscere un codice di Regione può aiutare nella verifica, ma dedurre un indirizzo dallo schema di un altro servizio non sostituisce il controllo della documentazione. Il Riferimento generale AWS e la documentazione sugli endpoint dei servizi forniscono i punti di partenza.

Tipo di endpoint	Che cosa stabilisce la ricerca fornita	Che cosa resta da verificare
Regionale	Molti nomi host includono un codice di servizio, un codice di Regione e amazonaws.com.	L'endpoint documentato per il servizio e la Regione selezionati.
Generale	Alcuni servizi dispongono di endpoint generali.	Come il servizio specifico gestisce le richieste inviate a quell'endpoint.
Globale	AWS documenta endpoint globali per alcuni servizi.	Quali operazioni e comportamenti regionali sono documentati per il servizio.

Il vantaggio degli endpoint specifici per servizio è un instradamento più chiaro e una separazione tra le funzionalità. Lo svantaggio, per chi esamina l'attività di rete, è che un'osservazione con carattere jolly come *.amazonaws.com nasconde gran parte di questi dettagli utili. Raggruppa destinazioni che possono avere scopi sostanzialmente diversi.

Un indirizzo AWS identifica chi gestisce un'applicazione?

Vedere amazonaws.com non identifica il cliente, il carico di lavoro o il proprietario dell'applicazione responsabile di una determinata richiesta. AWS fornisce il contesto del servizio cloud, ma il dominio principale non chiarisce quale account o risorsa sia alla base dell'attività. Inoltre, non stabilisce quali informazioni vengano archiviate, recuperate o elaborate.

Questo è rilevante quando qualcuno nota una connessione sconosciuta nell'attività di un'applicazione o nei registri di rete. L'indirizzo può aiutare a identificare un servizio AWS, ma per interpretare la connessione servono elementi ricavati dal software che la effettua. La domanda giusta è che cosa stia facendo quell'applicazione con la destinazione.

Un'analisi utile distingue le seguenti domande:

1. Quale applicazione ha avviato la richiesta? Collega la destinazione al software e all'attività oggetto dell'analisi.
2. Qual è la destinazione completa? Conserva il nome host e il percorso, anziché soltanto il suffisso del dominio.
3. Quale servizio rappresenta? Confronta l'indirizzo con la documentazione AWS pertinente.
4. Quale operazione è prevista? Stabilisci come la richiesta si collega al comportamento previsto dell'applicazione.
5. Quale modello di accesso si applica? Verifica le credenziali e le autorizzazioni richieste dal servizio e dalla risorsa.
6. Che cosa resta da chiarire? Lascia irrisolte le questioni relative a proprietà, scopo dei dati o autorizzazione quando il contesto disponibile non consente di stabilirli.

Questo approccio evita di trattare l'identità dell'infrastruttura come se fosse l'identità dell'applicazione. Rende anche l'indagine più specifica: l'incertezza sulla richiesta di un'applicazione diventa una questione relativa a quell'applicazione e a quel servizio, anziché una conclusione su tutte le destinazioni che condividono il suffisso.

In che modo credenziali e autorizzazioni influiscono sull'accesso?

Le credenziali e le autorizzazioni AWS rispondono a domande diverse. Le credenziali autenticano un chiamante, mentre le autorizzazioni stabiliscono quali azioni quel chiamante può eseguire. Sapere a quale servizio appartiene un endpoint non stabilisce se un determinato chiamante possa utilizzare una determinata risorsa.

I requisiti esatti dipendono dal singolo servizio e dal suo modello di accesso. Chi sviluppa dovrebbe consultare la panoramica delle credenziali di sicurezza AWS insieme alla documentazione del servizio e dell'operazione previsti. La sola esistenza di un endpoint non descrive tutti questi requisiti.

Domanda sull'accesso	Concetto pertinente	Che cosa non stabilisce da solo
Chi sta effettuando la richiesta?	Autenticazione tramite credenziali	Se il chiamante può eseguire l'azione richiesta.
Il chiamante può eseguire questa azione?	Autorizzazione tramite permessi	Se sia consentita anche un'azione o una risorsa non correlata.
Quali requisiti si applicano in questo caso?	Documentazione specifica del servizio	Una regola di accesso universale per ogni endpoint AWS.

La responsabilità va oltre il riconoscimento del fornitore

AWS pubblica un modello di responsabilità condivisa per comprendere la ripartizione delle responsabilità nell'uso dei suoi servizi. Si tratta di una questione distinta dal riconoscimento di un nome host AWS. I team devono considerare le proprie responsabilità insieme ai requisiti di accesso del servizio, anziché presumere che l'identità del fornitore risolva le questioni a livello applicativo.

Gli elementi forniti consentono di spiegare questa ripartizione nell'ambito di una valutazione di AWS. Non stabiliscono come un determinato cliente abbia configurato un'applicazione o una risorsa. Per valutare una specifica implementazione servono informazioni su quell'implementazione.

Un'organizzazione dovrebbe consentire o bloccare l'intera famiglia di domini?

Una decisione che riguarda l'intero dominio ha una portata ampia, perché amazonaws.com comprende più servizi e carichi di lavoro potenzialmente non correlati. Bloccare l'intera famiglia può interferire con le applicazioni che dipendono da quelle destinazioni. Consentirla indiscriminatamente lascia irrisolte le questioni sull'identità e sullo scopo delle singole richieste.

Nessuna delle due scelte deriva automaticamente dalla presenza di un nome host AWS. Un amministratore di rete ha bisogno dei criteri dell'organizzazione, dello scopo dell'applicazione richiedente e del contesto della destinazione specifico del servizio. La ricerca fornita supporta l'esame di questi dettagli prima di decidere l'ambito di accesso appropriato.

Situazione	Passo successivo utile	Limite degli elementi disponibili
Un'applicazione nota contatta un endpoint AWS	Confrontare la destinazione con l'uso dei servizi previsto per l'applicazione.	Conoscere l'applicazione non spiega ogni richiesta.
Un processo sconosciuto contatta amazonaws.com	Identificare il processo e conservare il contesto completo della richiesta.	Il dominio principale non identifica il proprietario del processo né il suo intento.
Una regola proposta comprende tutti i sottodomini	Valutare quali applicazioni e servizi sarebbero interessati dalla regola.	Un carattere jolly nasconde le differenze tra le singole destinazioni.
Una richiesta appare sospetta	Esaminare l'applicazione, la risorsa e il contesto del servizio pertinente.	L'identità dell'infrastruttura AWS non è una garanzia di sicurezza.

Lo stesso ragionamento vale per chi cerca di comprendere un indirizzo inatteso. Riconoscere AWS può chiarire la categoria di infrastruttura, ma non può stabilire se la connessione sia appropriata. Il comportamento dell'applicazione e lo scopo della richiesta restano centrali.

Dove si possono trovare documentazione, aiuto dalla community o contatti per segnalare abusi?

L'indice della documentazione AWS è il punto di accesso generale alle guide dei servizi. Il Riferimento generale e le pagine sugli endpoint dei servizi sono particolarmente pertinenti per identificare indirizzi e comportamenti regionali. La panoramica delle credenziali fornisce la spiegazione complementare dell'autenticazione del chiamante.

AWS offre anche re:Post, un servizio di domande e risposte della community. Offre a chi sviluppa uno spazio per porre domande sull'uso di AWS, mentre le risorse di contatto ufficiali consentono di ottenere assistenza e segnalare sospetti abusi. Le discussioni della community e le segnalazioni di abusi hanno scopi diversi e vanno scelte di conseguenza.

• Identificare un endpoint: iniziare dal Riferimento generale AWS e dalla documentazione sugli endpoint.
• Comprendere un servizio: utilizzare l'indice della documentazione per individuare la guida del servizio pertinente.
• Chiarire i requisiti di accesso: leggere la panoramica delle credenziali insieme alla documentazione sulle autorizzazioni del servizio.
• Porre domande sull'implementazione: utilizzare la community AWS re:Post.
• Trovare risorse di contatto o per segnalare abusi: consultare la pagina ufficiale dei contatti AWS.
• Esaminare le informazioni sulla privacy di AWS: consultare l'Informativa sulla privacy di AWS, esaminando separatamente l'applicazione responsabile di una richiesta.

AWS si rivolge alle organizzazioni e a chi sviluppa sistemi che richiedono funzionalità cloud per eseguire applicazioni, archiviare informazioni, integrare componenti e gestire carichi di lavoro. Gli elementi disponibili consentono di descrivere amazonaws.com come uno spazio dei nomi degli endpoint che collega il software a queste funzionalità. È adatto ai lettori che valutano servizi specifici e a chi li implementa, purché mantengano il contesto relativo a servizio, Regione, applicazione e accesso che il solo dominio principale non può fornire.