Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Risoluzione degli errori RFC in AMS
Molti errori RFC relativi al provisioning di AMS possono essere esaminati tramite la documentazione. CloudFormation Vedi Risoluzione dei problemi di AWS CloudFormation: Risoluzione degli errori
Ulteriori suggerimenti per la risoluzione dei problemi sono forniti nelle seguenti sezioni.
Errori RFC di «gestione» in AMS
I tipi di cambio di categoria AMS «Management» (CTs) consentono di richiedere l'accesso alle risorse e di gestire le risorse esistenti. Questa sezione descrive alcuni problemi comuni.
Errori di accesso RFC
Assicurati che il nome utente e il nome di dominio completo che hai specificato nella RFC siano corretti e che esistano nel dominio. Per informazioni su come trovare il tuo FQDN, vedi Ricerca del tuo FQDN.
Assicurati che l'ID dello stack che hai specificato per l'accesso sia uno stack correlato allo stack. EC2 Gli stack come ELB e Amazon Simple Storage Service (S3) non sono candidati RFCs all'accesso, ma utilizza il tuo ruolo di accesso di sola lettura per accedere a queste risorse degli stack. Per assistenza nella ricerca di un ID dello stack, consulta Finding stack IDs
Assicurati che l'ID dello stack che hai fornito sia corretto e appartenga all'account pertinente.
Per informazioni su altri errori RFC di accesso, consulta Gestione degli accessi.
YouTube Video: Come posso inviare correttamente una Request for Change (RFC) per evitare rifiuti ed errori
Errori di pianificazione CT RFC (manuale)
La maggior parte dei tipi di modifica sono ExecutionMode =Automatizzati, ma alcuni sono ExecutionMode =Manuali e ciò influisce sulla modalità di pianificazione per evitare errori RFC.
Pianificato RFCs con ExecutionMode =Manual, deve essere impostato per essere eseguito almeno 24 ore nelle future se si utilizza la console AMS per creare la RFC. Questa avvertenza non si applica all'API/CLI AMS, ma è comunque importante programmare il manuale con RFCs almeno 8 ore di anticipo.
AMS mira a rispondere a una CT manuale entro quattro ore e risponderà il prima possibile, ma potrebbe essere necessario molto più tempo prima che la RFC venga effettivamente eseguita.
Utilizzo RFCs con aggiornamento manuale CTs
AMS Operations reject Management | Other | Other RFCs per gli aggiornamenti agli stack, quando esiste un tipo di modifica Update per il tipo di stack che si desidera aggiornare.
Errori di eliminazione dello stack RFC
Errori di eliminazione dello stack RFC: se utilizzi Management | Standard stacks | Stack | Delete CT, vedrai gli eventi dettagliati nella Console per lo stack con il nome dello stack AMS. CloudFormation Puoi identificare lo stack confrontandolo con il nome che ha nella console AMS. La CloudFormation console fornisce maggiori dettagli sulle cause dei guasti.
Prima di eliminare uno stack, è necessario considerare come è stato creato lo stack. Se avete creato lo stack utilizzando un CT AMS e non avete aggiunto o modificato le risorse dello stack, potete aspettarvi di eliminarlo senza problemi. Tuttavia, è consigliabile rimuovere tutte le risorse aggiunte manualmente da uno stack prima di inviare una richiesta RFC relativa allo stack di eliminazione. Ad esempio, se crei uno stack utilizzando lo stack CT completo (HA Two Tier), include un gruppo di sicurezza -. SG1 Se poi usi AMS per creare un altro gruppo di sicurezza e fai riferimento al nuovo SG2 gruppo SG1 creato come parte dello stack completo, e poi usi lo stack di eliminazione CT per eliminare lo stack, non SG1 verrà eliminato in quanto è referenziato da. SG2 SG2
Importante
L'eliminazione degli stack può avere conseguenze indesiderate e impreviste. Per questo motivo, AMS preferisce *non* eliminare gli stack o le risorse dello stack per conto dei clienti. Tieni presente che AMS eliminerà solo le risorse per tuo conto (tramite un tipo di modifica inviato in Gestione | Altro | Altro | Aggiorna) che non è possibile eliminare utilizzando il tipo di modifica appropriato e automatizzato da eliminare. Ulteriori considerazioni:
Se le risorse sono abilitate per la «protezione da eliminazione», AMS può aiutarti a sbloccarla inviando un tipo di modifica Gestione | Altro | Altro | Aggiorna e, dopo aver rimosso la protezione da eliminazione, puoi utilizzare il CT automatico per eliminare quella risorsa.
Se ci sono più risorse in uno stack e desideri eliminare solo un sottoinsieme delle risorse dello stack, usa il tipo di modifica CloudFormation Update (vedi Ingest Stack: Updating). CloudFormation Puoi anche inviare un tipo di modifica Management | Other | Other | Update e gli ingegneri AMS possono aiutarti a creare il changeset, se necessario.
In caso di problemi nell'utilizzo di CloudFormation Update CT dovuti a deviazioni, AMS può aiutarti inviando un Management | Other | Other | Update per risolvere la deriva (nella misura supportata dal CloudFormation servizio AWS) e fornirne uno ChangeSet da convalidare ed eseguire utilizzando CT, Management/Custom Stack/Stack From CloudFormation Template/Approve Changeset e Update automatizzati.
AMS mantiene le restrizioni di cui sopra per garantire che non si verifichino eliminazioni di risorse impreviste o impreviste.
Per ulteriori informazioni, consulta Risoluzione dei problemi di AWS CloudFormation: delete stack fail.
Errori DNS di aggiornamento RFC
L'aggiornamento multiplo RFCs di una zona ospitata DNS può fallire, in alcuni casi senza motivo. La creazione RFCs simultanea di più zone ospitate dal DNS per aggiornare (private o pubbliche) può causare il fallimento RFCs di alcune zone, in quanto tentano di aggiornare lo stesso stack contemporaneamente. La gestione delle modifiche AMS rifiuta o RFCs fallisce chi non è in grado di aggiornare uno stack perché lo stack è già aggiornato da un'altra RFC. AMS consiglia di creare una RFC alla volta e di attendere che la RFC abbia esito positivo prima di crearne una nuova per lo stesso stack.
Errori delle entità RFC IAM
AMS fornisce una serie di ruoli e profili IAM predefiniti negli account AMS progettati per soddisfare le tue esigenze. Tuttavia, potrebbe essere necessario richiedere occasionalmente risorse IAM aggiuntive.
Il processo di invio della RFCs richiesta di risorse IAM personalizzate segue il flusso di lavoro standard per il manuale RFCs, ma il processo di approvazione include anche una revisione della sicurezza per garantire che siano in atto controlli di sicurezza appropriati. Pertanto, il processo richiede in genere più tempo rispetto ad altri manuali. RFCs Per ridurre il tempo di ciclo di questi RFCs, segui le seguenti linee guida.
Per informazioni su cosa intendiamo per revisione IAM e su come corrisponda ai nostri standard tecnici e al processo di accettazione dei rischi, consultaComprendi le revisioni sulla sicurezza RFC.
Richieste comuni di risorse IAM:
Se stai chiedendo una policy relativa a una delle principali applicazioni compatibili con il cloud, ad esempio CloudEndure, consulta la CloudEndure policy IAM preapprovata da AMS: decomprimi il file di esempio WIGs Cloud Endure Landing Zone e apri il
customer_cloud_endure_policy.jsonNota
Se desideri una policy più permissiva, discuti le tue esigenze e richiedi, se necessario, un'AMS Security Review CloudArchitect/CSDM and Signoff prima di inviare una RFC che implementi la policy.
Se desideri modificare di default una risorsa distribuita da AMS nel tuo account, ti consigliamo di richiedere una copia modificata di quella risorsa anziché modificare quella esistente.
Se richiedi le autorizzazioni per un utente umano (anziché assegnarle all'utente), allega le autorizzazioni a un ruolo, quindi concedi all'utente il permesso di assumere quel ruolo. Per maggiori dettagli su questa operazione, consulta Accesso temporaneo alla console AMS Advanced.
Se hai bisogno di autorizzazioni eccezionali per una migrazione o un flusso di lavoro temporanei, fornisci una data di fine per tali autorizzazioni nella richiesta.
Se avete già discusso l'argomento della richiesta con il team addetto alla sicurezza, fornite al CSDM una prova della loro approvazione nel modo più dettagliato possibile.
Se AMS rifiuta una RFC IAM, forniamo un motivo chiaro per il rifiuto. Ad esempio, potremmo rifiutare una policy IAM, creare una richiesta e spiegare quali aspetti della policy sono inappropriati. In tal caso, puoi apportare le modifiche identificate e inviare nuovamente la richiesta. Se è necessaria maggiore chiarezza sullo stato di una richiesta, invia una richiesta di assistenza o contatta il tuo CSDM.
L'elenco seguente descrive i rischi tipici che AMS cerca di mitigare mentre esaminiamo il vostro IAM. RFCs Se la tua RFC IAM presenta uno di questi rischi, ciò potrebbe comportare il rifiuto della RFC. Nei casi in cui è necessaria un'eccezione, AMS richiede l'approvazione del team di sicurezza. Per cercare un'eccezione di questo tipo, contattate il vostro CSDM.
Nota
AMS può, per qualsiasi motivo, rifiutare qualsiasi modifica alle risorse IAM all'interno di un account. Per dubbi riguardanti il rifiuto di una RFC, contatta AMS Operations tramite una richiesta di assistenza o contatta il tuo CSDM.
Aumento dei privilegi, ad esempio autorizzazioni che consentono di modificare le proprie autorizzazioni o di modificare le autorizzazioni di altre risorse all'interno dell'account. Esempi:
L'uso di con un altro ruolo più
iam:PassRoleprivilegiato.Autorizzazione alle politiche attach/detach IAM da parte di un ruolo o di un utente.
La modifica delle politiche IAM nell'account.
La capacità di effettuare chiamate API nel contesto dell'infrastruttura di gestione.
Autorizzazioni per modificare risorse o applicazioni necessarie per fornirti i servizi AMS. Esempi:
Modifica dell'infrastruttura AMS come i bastions, l'host di gestione o l'infrastruttura EPS.
Eliminazione delle funzioni o dei flussi di log di gestione dei log di AWS Lambda.
L'eliminazione o la modifica dell'applicazione di CloudTrail monitoraggio predefinita.
La modifica di Directory Services Active Directory (AD).
Disabilitazione degli CloudWatch allarmi (CW).
La modifica dei principi, delle politiche e dei namespace implementati nell'account come parte della landing zone.
Implementazione dell'infrastruttura al di fuori delle migliori pratiche, ad esempio autorizzazioni che consentono la creazione di infrastrutture in uno stato che mette a rischio la sicurezza delle informazioni. Esempi:
La creazione di bucket S3 pubblici o non crittografati o la condivisione pubblica di volumi EBS.
Fornitura di indirizzi IP pubblici.
La modifica dei gruppi di sicurezza per consentire un ampio accesso.
Autorizzazioni eccessivamente ampie in grado di influire sulle applicazioni, ad esempio autorizzazioni che possono causare perdita di dati, perdita di integrità, configurazione inappropriata o interruzioni del servizio per l'infrastruttura e le applicazioni all'interno dell'account. Esempi:
Disabilitazione o reindirizzamento del traffico di rete tramite like or. APIs
ModifyNetworkInterfaceAttributeUpdateRouteTableLa disabilitazione dell'infrastruttura gestita mediante il distacco dei volumi dagli host gestiti.
Le autorizzazioni per i servizi non fanno parte della descrizione del servizio AMS e non sono supportate da AMS.
I servizi non elencati nella descrizione del servizio AMS non possono essere utilizzati negli account AMS. Per richiedere assistenza per una funzionalità o un servizio, contatta il tuo CSDM.
Autorizzazioni che non soddisfano l'obiettivo dichiarato in quanto troppo generose o troppo conservative o applicate a risorse sbagliate. Esempi:
Una richiesta di
s3:PutObjectautorizzazioni per un bucket S3 con crittografia KMS obbligatoria, senzaKMS:Encryptautorizzazioni per la chiave pertinente.Autorizzazioni relative a risorse che non esistono nell'account.
IAM RFCs in cui la descrizione della RFC non sembra corrispondere alla richiesta.
Errori RFC di «implementazione»
I tipi di cambio di categoria AMS «Deployment» (CTs) consentono di richiedere l'aggiunta di varie risorse supportate da AMS al proprio account.
La maggior parte degli AMS CTs che creano una risorsa si basano su CloudFormation modelli. In qualità di cliente hai accesso in sola lettura a tutti i servizi AWS CloudFormation, tra cui puoi identificare rapidamente lo CloudFormation stack che rappresenta il tuo stack in base alla descrizione dello stack utilizzando la Console. CloudFormation Lo stack fallito sarà probabilmente nello stato DELETE_COMPLETE. Una volta identificato lo CloudFormation stack, gli eventi mostreranno la risorsa specifica che non è stata creata e il motivo.
Utilizzo della CloudFormation documentazione per la risoluzione dei problemi
La maggior parte del provisioning AMS RFCs utilizza un CloudFormation modello e tale documentazione può essere utile per la risoluzione dei problemi. Consulta la documentazione relativa a quel CloudFormation modello:
Errore di creazione del sistema di bilanciamento del carico delle applicazioni: AWS::ElasticLoadBalancingV2::LoadBalancer (Application Load Balancer)
Crea gruppo di Auto Scaling: AWS::AutoScaling::AutoScalingGroup (Auto Scaling Group)
Crea cache memcached: AWS::ElastiCache::CacheCluster (Cache Cluster)
Crea cache Redis: AWS::ElastiCache::CacheCluster (Cache Cluster)
Crea un file system elastico (EFS): AWS::EFS::FileSystem (Elastic File System)
Crea un sistema di bilanciamento del carico: AWS::ElasticLoadBalancing::LoadBalancer (Elastic Load Balancer)
Crea DB RDS: AWS::RDS::DBInstance (database relazionale)
Crea Amazon S3: AWS::S3::Bucket (Servizio di storage semplice)
Crea coda: AWS::SQS::Queue (Simple Queue Service)
Errori di creazione di RFC AMIs
Un'Amazon Machine Image (AMI) è un modello che contiene una configurazione software (ad esempio un sistema operativo, un server di applicazioni e le applicazioni). Da un'AMI, si avvia un'istanza, che è una copia dell'AMI in esecuzione come server virtuale nel cloud. AMIs sono molto utili e necessari per creare EC2 istanze o gruppi di Auto Scaling; tuttavia, è necessario rispettare alcuni requisiti:
L'istanza specificata
Ec2InstanceIddeve essere interrotta affinché la RFC abbia esito positivo. Non utilizzate istanze del gruppo Auto Scaling (ASG) per questo parametro perché l'ASG interromperà un'istanza interrotta.Per creare un'Amazon Machine Image (AMI) AMS, devi iniziare con un'istanza AMS. Prima di poter utilizzare l'istanza per creare l'AMI, è necessario prepararla assicurandosi che venga interrotta e disconnessa dal relativo dominio. Per i dettagli, consulta Creare un'immagine di macchina Amazon standard utilizzando Sysprep
Il nome specificato per la nuova AMI deve essere univoco all'interno dell'account, altrimenti la RFC fallirà. La procedura per eseguire questa operazione è descritta in AMI | Create e per ulteriori dettagli, consulta AWS AMI Design
.
Nota
Per ulteriori informazioni sulla preparazione per la creazione di AMI, consulta AMI | Create.
RFCs creazione di errori EC2s ASGs
In caso di EC2 errori ASG con timeout, AMS consiglia di confermare se l'AMI utilizzato è personalizzato. In tal caso, consulta la procedura di creazione dell'AMI inclusa in questa guida (vedi AMI | Crea) per assicurarti che l'AMI sia stata creata correttamente. Un errore comune quando si crea un'AMI personalizzata è non seguire i passaggi indicati nella guida per rinominare o richiamare Sysprep.
RFCs creazione di errori RDS
I guasti di Amazon Relational Database Service (RDS) possono verificarsi per molte ragioni diverse, perché è possibile utilizzare molti motori diversi quando si crea l'RDS e ogni motore ha i propri requisiti e limitazioni. Prima di tentare di creare uno stack AMS RDS, esamina attentamente i valori dei parametri AWS RDS, consulta Create. DBInstance
Per ulteriori informazioni su Amazon RDS in generale, incluse le raccomandazioni sulle dimensioni, consulta la documentazione di Amazon Relational Database Service
RFCs creazione di errori Amazon S3s
Un errore comune durante la creazione di un bucket di archiviazione S3 è il mancato utilizzo di un nome univoco per il bucket. Se hai inviato un bucket S3 Create CT con lo stesso nome di uno inviato in precedenza, non riuscirebbe perché esisterebbe già un bucket S3 con quello stesso nome. BucketName Questo verrebbe descritto in dettaglio nella CloudFormation Console, dove vedrai che l'evento stack mostra che il nome del bucket è già in uso.
Validazione RFC rispetto agli errori di esecuzione
Gli errori RFC e i messaggi correlati differiscono nei messaggi di output nella pagina dei dettagli RFC della console AMS per un RFC selezionato:
I motivi degli errori di convalida sono disponibili solo nel campo Status
I motivi degli errori di esecuzione sono disponibili in Execution Output e Status Fields.
Messaggi di errore RFC
Quando riscontri il seguente errore per i tipi di modifica elencati (CTs), puoi utilizzare queste soluzioni per individuare l'origine dei problemi e risolverli.
{"errorMessage":"An error has occurred during RFC execution. We are investigating the issue.","errorType":"InternalError"}
Se hai bisogno di ulteriore assistenza dopo aver fatto riferimento alle seguenti opzioni di risoluzione dei problemi, contatta AMS tramite corrispondenza RFC o crea una richiesta di assistenza. Per maggiori dettagli, consulta Corrispondenza e allegato RFC (console) e Creazione di una richiesta di servizio in AMS.
Errori di inserimento del carico di lavoro (WIGS)
Nota
Gli strumenti di convalida per Windows e Linux possono essere scaricati ed eseguiti direttamente sui server locali e sulle EC2 istanze in AWS. È possibile trovarli nella AMS Advanced Application Developer's GuideMigrating workload: Linux pre-ingestion validation e Migrating workload: Windows pre-ingestion validation.
EC2 Assicurati che l'istanza esista nell'account AMS di destinazione. Ad esempio, se hai condiviso il tuo AMI da un account non AMS a un account AMS, dovrai creare un' EC2 istanza nel tuo account AMS con l'AMI condiviso prima di poter inviare un Workload Ingest RFC.
Verifica se per i gruppi di sicurezza collegati all'istanza è consentito il traffico in uscita. L'agente SSM deve essere in grado di connettersi al suo endpoint pubblico.
Verifica se l'istanza dispone delle autorizzazioni giuste per connettersi con l'agente SSM. Queste autorizzazioni vengono fornite con
customer-mc-ec2-instance-profile, puoi verificarle nella console: EC2
EC2 errori di blocco dello stack di istanze
Verifica se l'istanza è già interrotta o terminata.
Se l' EC2 istanza è online e vedi l'
InternalErrorerrore, invia una richiesta di servizio affinché AMS possa esaminarla.Tieni presente che non puoi utilizzare il tipo di modifica Management | Advanced stack components | EC2 instance stack | Stop ct-3mvvt2zkyveqj per interrompere un'istanza del gruppo Auto Scaling (ASG). Se devi interrompere un'istanza ASG, invia una richiesta di servizio.
EC2 lo stack di istanze crea errori
Il InternalError messaggio proviene da CloudFormation; un motivo dello stato CREATION_FAILED. Puoi trovare i dettagli sull'errore dello stack negli eventi dello CloudWatch stack seguendo questi passaggi:
Nella console di gestione AWS, puoi visualizzare un elenco di eventi dello stack durante la creazione, l'aggiornamento o l'eliminazione dello stack. In questo elenco, trova l'evento relativo al problema e quindi visualizzane il motivo dello stato.
Il motivo dello stato potrebbe contenere un messaggio di errore di AWS CloudFormation o di un particolare servizio che può aiutarti a comprendere il problema.
Per ulteriori informazioni sulla visualizzazione degli eventi dello stack, consulta Visualizzazione dei dati e delle risorse di AWS CloudFormation Stack nella Console di gestione AWS.
EC2 errori di ripristino del volume dell'istanza
AMS crea una RFC interna per la risoluzione dei problemi quando il ripristino del volume dell' EC2 istanza fallisce. Ciò avviene perché il ripristino del volume delle EC2 istanze è una parte importante del disaster recovery (DR) e AMS crea automaticamente questa RFC interna per la risoluzione dei problemi.
Quando viene creata la RFC interna per la risoluzione dei problemi, viene visualizzato un banner contenente i collegamenti alla RFC. Questa RFC interna per la risoluzione dei problemi offre una maggiore visibilità sugli errori RFC e, anziché ripetere RFCs i tentativi che generano gli stessi errori o richiedere di contattare manualmente AMS in caso di errore, potete tenere traccia delle modifiche apportate e sapere che AMS sta lavorando sull'errore. In questo modo si riduce anche la metrica time-to-recovery (TTR) relativa alla modifica, in quanto gli operatori AMS lavorano in modo proattivo sull'errore RFC anziché attendere la richiesta dell'utente.
Come ottenere assistenza con un RFC
Puoi contattare AMS per identificare la causa principale del tuo errore. L'orario di lavoro di AMS è 24 ore al giorno, 7 giorni alla settimana, 365 giorni all'anno.
AMS offre diverse possibilità per chiedere aiuto o effettuare richieste di assistenza.
Per richiedere informazioni o consigli, o per accedere a un servizio IT gestito da AMS o per richiedere un servizio aggiuntivo ad AMS, utilizza la console AMS e invia una richiesta di servizio. Per i dettagli, consulta Creazione di una richiesta di assistenza. Per informazioni generali sulle richieste di assistenza AMS, vedere Gestione delle richieste di assistenza.
Per segnalare un problema di prestazioni del servizio AWS o AMS che ha un impatto sull'ambiente gestito, utilizza la console AMS e invia un rapporto sull'incidente. Per i dettagli, consulta Segnalazione di un incidente. Per informazioni generali sulla gestione degli incidenti con AMS, consulta Risposta agli incidenti.
Per domande specifiche su come voi, le vostre risorse o applicazioni state lavorando con AMS o per segnalare un incidente, inviate un'e-mail a uno o più dei seguenti documenti:
Innanzitutto, se non siete soddisfatti della richiesta di servizio o della risposta alla segnalazione dell'incidente, inviate un'e-mail al vostro CSDM: ams-csdm@amazon.com
Successivamente, se è necessaria un'escalation, puoi inviare un'e-mail all'AMS Operations Manager (ma probabilmente il tuo CSDM lo farà): ams-opsmanager@amazon.com
Un'ulteriore escalation verrebbe indirizzata al direttore di AMS: ams-director@amazon.com
Infine, puoi sempre contattare il vicepresidente di AMS: ams-vp@amazon.com
