tecRacer Amazon AWS Blog Infos rund um das Thema Amazon Web Services von den tecRacer Cloud Experten 2017-12-11T15:28:13Z http://www.aws-blog.de/feed/atom/ WordPress Sven Ramuschkat <![CDATA[AWS Re:Invent 2017 Sessions Slideshare List]]> http://www.aws-blog.de/?p=2673 2017-12-11T15:28:13Z 2017-12-11T15:28:13Z Re:Invent 2017 Sessions available on Slideshare (Status Dec 11, 2017) in an Excel-File for Download. AWS-Re-Invent2017-Slideshare-Sessions

Der Beitrag AWS Re:Invent 2017 Sessions Slideshare List erschien zuerst auf tecRacer Amazon AWS Blog.

]]>
Re:Invent 2017 Sessions available on Slideshare (Status Dec 11, 2017) in an Excel-File for Download.

AWS-Re-Invent2017-Slideshare-Sessions

Der Beitrag AWS Re:Invent 2017 Sessions Slideshare List erschien zuerst auf tecRacer Amazon AWS Blog.

]]>
0
Sven Ramuschkat <![CDATA[50 Mitarbeiter Zertifizierungen für AWS]]> http://www.aws-blog.de/?p=2666 2017-09-17T13:10:41Z 2017-09-17T13:10:41Z   Seit vielen Jahren haben darauf hin gearbeitet … jetzt die Marke von 50 Mitarbeiter Zertifizierungen für die Amazon Web Services Cloud erreicht. Insider wissen, wie schwer diese Zertifizierungen sind, so dass sich unsere Kunden […]

Der Beitrag 50 Mitarbeiter Zertifizierungen für AWS erschien zuerst auf tecRacer Amazon AWS Blog.

]]>
 

Seit vielen Jahren haben darauf hin gearbeitet … jetzt die Marke von 50 Mitarbeiter Zertifizierungen für die Amazon Web Services Cloud erreicht.

Insider wissen, wie schwer diese Zertifizierungen sind, so dass sich unsere Kunden darauf verlassen können, das unsere Mitarbeiter richtig Ahnung davon haben …

Der Beitrag 50 Mitarbeiter Zertifizierungen für AWS erschien zuerst auf tecRacer Amazon AWS Blog.

]]>
0
Gernot Glawe <![CDATA[Clouds – einfaches Management von CloudFormation Templates]]> http://www.aws-blog.de/?p=2634 2017-07-21T13:59:27Z 2017-07-21T13:54:43Z Infrastruktur als Code ist eine (Heraus)Forderung von DevOps. Die Infrastrukturbeschreibungssprache von AWS heißt CloudFormation. Hat man sich erstmal eingearbeitet, greift man immer häufiger zum Texteditor statt zur Console, um AWS Ressourcen zu erstellen. Und eh […]

Der Beitrag Clouds – einfaches Management von CloudFormation Templates erschien zuerst auf tecRacer Amazon AWS Blog.

]]>
Infrastruktur als Code ist eine (Heraus)Forderung von DevOps. Die Infrastrukturbeschreibungssprache von AWS heißt CloudFormation. Hat man sich erstmal eingearbeitet, greift man immer häufiger zum Texteditor statt zur Console, um AWS Ressourcen zu erstellen. Und eh man es sich versieht, hat man eine unüberschaubare Anzahl von Cloudformation Templates. Und dann steht man vor der Aufgabe, diese zu verwalten. Hier wollen wir ein paar Möglichkeiten dafür vorstellen.

Verwaltung mit der AWS Console

Die WebGui von AWS ist zu Anfang der schnellste und einfachste Weg für die Verwaltung. Wie bei den meisten AWS Diensten wird eine einfache Liste angezeigt.

Umständlich wird es, wenn man viele Stacks hat. Hier im Beispiel sieht man nicht alle 12 Templates, man muss runterscrollen. Hilfreich ist es, den angezeigten Listenbereich zu maximieren. Dazu gibt es rechts in der Mitte die Symbole zur Größenanpassung des LIstenbereichs:

. Mit dem linken Symbol vergrößert sich der Listenbereich.

Arbeiten in verschiedenen Regionen – Resource Groups

Hier sieht man immer nur die Stacks in einer Region. Versieht man jedoch alle Templates mit Tags, z.B. „Project = Cloudformation“ so kann man überregional in den „Resource Groups“ Templates verschiedener Regionen ansehen:

Beim Erstellen der Resource Group sind folgende Attribute zu befüllen:

  1. Group Name: Ein sprechender Gruppenname, hier „Cloudformation Templates“
  2. Die Tags, die man sammeln will. Hier werden nur bereits vorhandene Tags zur Auswahl angezeigt. Im Beispiel „Project“
  3. Der Inhalt des Tags, im Beispiel „Cloudformation“
  4. Unter Regionen gibt man an, ob man über alle Regionen zusammenfassen will.
  5. Unter Resource Types gibt man nun Cloudformation Stacks an.

 

 

Als Ergebnis sieht man alle Ressourcen, die in diesem Fall den Tag „Project“ gleich „Cloudformation“ haben. Ich habe hier zwei Stacks in unterschiedlichen Regionen angelegt und kann diese hier zentral sehen:

 

Für Profis – Verwaltung mit der Kommandozeile CLI

Will man weiter automatisieren, so kommt man an der aws cli (command line interface) nicht vorbei. Die Beispiele sind – soweit nicht anders angegeben- mit der bash Shell erstellt.
Hier kann ich mir mit einem einfache Befehl alle Stacks der aktuellen Region anzeigen lassen:

aws cloudformation list-stacks

Angezeigt wird jeweils ein vollen Datensatz der Stacks.

{

            "StackId": "arn:aws:cloudformation:eu-central-1:123453403305:stack/MOBILEHUB-1663486314-Development/2b3f8290-1075-11e7-80a2-500c52a6ce62", 
            "StackName": "MOBILEHUB-1663486314-Development", 
            "CreationTime": "2017-03-24T09:35:08.096Z", 
            "DeletionTime": "2017-03-31T08:52:47.891Z", 
            "StackStatus": "DELETE_COMPLETE"
 }

Um nur eine Liste der Namen zu bekommen, kann man die query Funktion der AWS Kommandozeile nutzen:

aws cloudformation list-stacks --query "StackSummaries[*].StackName"

Mitunter werden hier mehr Stacks angezeigt, als eigentlich aktiv sind. Das liegt daran, dass auch Stacks mit Status gelöscht enthalten sind:

"StackStatus": "DELETE_COMPLETE", 

Filtern der cli Ausgabe

Die Ausgabe kann ich mit einem Filter bereinigen:

aws cloudformation list-stacks --query "StackSummaries[?StackStatus == 'CREATE_COMPLETE']" 

Um auch hier wieder nur eine Liste der Namen zu bekommen, gebe ich die gewünschten Ausgabeattribute mit an:

aws cloudformation list-stacks --query "StackSummaries[?StackStatus == 'CREATE_COMPLETE'].{Name:StackName}" 

Ganz rund wird es dann, wenn ich noch das Ausgabeformat anpasse:

aws cloudformation list-stacks --query "StackSummaries[?StackStatus == 'CREATE_COMPLETE'].{Name:StackName}" --output table

Mögliche Formate sind:

  • text
  • Json
  • Table

Das sieht dann in etwa so aus:

Hier sind noch ein paar Stacks von der Vorbereitung auf das AWS Usergroup Treffen Hannover enthalten. Es ging wie man sehen kann um Codestar, Lambda und codebuild. 

Alle Stacks – Alle Regionen

Dennoch beschränkt sich hier die Ausgabe auf eine Region. Das kann man mit einem kleinen Shell Script lösen:

#!/bin/bash
for R in us-east-1 us-east-2 eu-west-1 eu-central-1 
do
  export AWS_DEFAULT_REGION=$R
  aws cloudformation list-stacks --query "StackSummaries[?StackStatus == 'CREATE_COMPLETE'].{Name:StackName}" --output table
done

Im Beispiel werden für die vier Regionen east1+2, Irland und Frankfurt alle Stacks ausgegeben.

Noch einfacher – Verwaltung mit dem Tool „clouds“

Für eine individuelle Automatisierung kann der manuelle Weg zum Zusammenbau von cli Scripten der beste Weg sein, er ist aber auch steinig. Es gibt bereits verschiedene Tools, die das Leben einfacher machen. Eins davon ist „clouds„.

Das Prinzip des Tools sieht vor, dass alle CloudFormation Stacks lokal auf der Festplatte in einem Unterverzeichnis names „stacks“ liegen. Diese lokalen Kopien synchronisiert man dann mit dem AWS CloudFormation Service. Hier ein Beispiel für die Verwendung:

Installation von clouds

Mit dem pip Installer beschränkt sich die Installation auf:

pip install clouds-aws

Wichtig ist das Setzen der Region Umgebungsvariable, hier für bash. Für Frankfurt dann bitte eu-central-1 statt us-west-1 verwenden.

export AWS_DEFAULT_REGION=us-west-1

Konfiguration

clouds geht von dem Unterverzeichnis „stacks“ aus. Zusätzlich erstellen wir noch zwei Template Verzeichnisse.

mkdir stacks
mkdir stacks/mystack1
mkdir stacks/mystack2

Erstellen von Templates

Jetzt muss ich noch dafür sorgen, dass syntaktisch korrekter Inhalt in den Templates enthalten ist. Man kann dazu vi oder jeden anderen Editor nehmen.

touch  stacks/mystack1/template.json
vi stacks/mystack2/template.json

Ein Beispielstack mit einer EC2 Instanz gibt es im Abschnitt „Basic Amazon EC2 Instance“ auf dieser Seite: http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/deploying.applications.html

In diesem Stack wird noch ein Parameter verwendet. Auch damit kann clouds umgehen. Die Parameter werden im selben Verzeichnis wie die Templates in die Datei „parameters.yaml“ geschrieben.

vi stacks/mystack2/parameters.yaml

Ich habe meinen Key „mykeyname-us-west-1“ genannt. Die parameters.yaml enthält also:

KeyName: "mykeyname-us-west-1"

Templateliste

Jetzt habe ich lokale Templates. Dies zeigt clouds mit „list“ an:

Eingabe:

clouds list

Ausgabe:

stack list and stack status:

mystack1 LOCAL-ONLY
mystack2 LOCAL-ONLY

Stack mit lokalem Template erstellen

Um die Template-Erstellung komme ich in keiner Variante – Konsole-cli oder clouds herum. Nach dem Erstellen wird es jetzt mit clouds einfacher. Der Name des Stacks ist durch den Namen des Unterverzeichnisses von „stacks“ festgelegt. Daher kann ich jetzt „mystack2“ einfach erstellen:

clouds update mystack2 -c

Der Befehl „update“ aktualisiert den AWS CloudFormation Stack aus der lokalen Datei. Mit dem Parameter „-c“ (create) wird der Stack angelegt, wenn er noch nicht existiert.

Um zu sehen, wie der Stack angelegt wird und ob es eventuell Probleme gibt, lasse ich mir die Protokolldatei anzeigen:

clouds events -f mystack2

Die Ausgabe sieht dann in etwa so aus:

2017-06-25/09:19:05 CREATE_IN_PROGRESS AWS::CloudFormation::Stack mystack2 User Initiated
2017-06-25/09:19:10 CREATE_IN_PROGRESS AWS::EC2::SecurityGroup WebServerSecurityGroup 
2017-06-25/09:19:11 CREATE_IN_PROGRESS AWS::EC2::SecurityGroup WebServerSecurityGroup Resource creation Initiated
2017-06-25/09:19:12 CREATE_COMPLETE AWS::EC2::SecurityGroup WebServerSecurityGroup 
2017-06-25/09:19:15 CREATE_IN_PROGRESS AWS::EC2::Instance WebServerInstance 
2017-06-25/09:19:16 CREATE_IN_PROGRESS AWS::EC2::Instance WebServerInstance Resource creation Initiated
2017-06-25/09:19:33 CREATE_COMPLETE AWS::EC2::Instance WebServerInstance 
2017-06-25/09:19:36 CREATE_COMPLETE AWS::CloudFormation::Stack mystack2

Mit dem Template arbeiten

Ich kann nun das Template lokal bearbeiten und jeweils mit dem update Befehl als Stackupdate ausführen.

Den aktuellen Status alle Stacks in der aktuellen Region kann ich mir dann mit

clouds list

Anzeigen lassen.

Will ich den Detailstatus eines Stack sehen, z.B. „mystack2“, so ist „describe“ das Kommando:

clouds describe mystack2

Die Ausgabe solle in etwa so aussehen:

Parameters:
 InstanceType: m1.small
 KeyName: mykeyname-us-west-1
 SSHLocation: 0.0.0.0/0
Outputs:
 WebsiteURL: http://ec2-13-56-11-84.us-west-1.compute.amazonaws.com
Resources:
 WebServerInstance: AWS::EC2::Instance (i-056ebb015af809521)
 WebServerSecurityGroup: AWS::EC2::SecurityGroup (mystack2-WebServerSecurityGroup-84E66682CPUR)

Stacks löschen

Das Löschen von Stacks ist dann mit „delete“ möglich. Den „-f“ force switch sollte man mit Bedacht verwenden, da der Stack dann ohne Nachfrage gelöscht wird. Ein kleiner Vertipper könnte da große Folgen haben. Hier verwende ich ihn, um das Beispiel abzuschließen:

clouds delete mystack2 --force

Fazit

Es gibt auch noch weitere Tools wie z.B. „awless„, die einen Teil der Funktionalität abbilden. Clouds bietet meiner Meinung nach einen sehr vielversprechenden Ansatz. Alle Funktionen, die ich bei früheren Projekten selber mit Scripten auf der Kommandozeile gebaut habe, sind enthalten.

Wenn man vor der Grundlagenentscheidung steht, wie Infrastruktur auf aws gebaut wird, sollte man sich auch Terraform und sparkeformation anschauen.

Steht Cloudformation als Basis fest und werden keine umfangreichen Programmierungen von Templates benötigt, ist clouds definitiv eine echte Hilfe!

Der Beitrag Clouds – einfaches Management von CloudFormation Templates erschien zuerst auf tecRacer Amazon AWS Blog.

]]>
0
Sven Ramuschkat <![CDATA[Die Deutsche Bahn geht in die AWS-Cloud]]> http://www.aws-blog.de/?p=2624 2017-04-25T13:50:32Z 2017-04-25T13:50:32Z Der IT-Dienstleister der Deutschen Bahn, die DB Systel GmbH, verlagert ihr Rechenzentrum in die Amazon-Cloud … und wir von tecRacer dürfen dabei tatkräftig mit Trainings & Consulting unterstützen. Mehr dazu hier bei Heise / iX.

Der Beitrag Die Deutsche Bahn geht in die AWS-Cloud erschien zuerst auf tecRacer Amazon AWS Blog.

]]>
Der IT-Dienstleister der Deutschen Bahn, die DB Systel GmbH, verlagert ihr Rechenzentrum in die Amazon-Cloud … und wir von tecRacer dürfen dabei tatkräftig mit Trainings & Consulting unterstützen.

Mehr dazu hier bei Heise / iX.

Der Beitrag Die Deutsche Bahn geht in die AWS-Cloud erschien zuerst auf tecRacer Amazon AWS Blog.

]]>
0
Gernot Glawe <![CDATA[Call Center Service „Amazon Connect“ mit Lambda Integration – Alles möglich?]]> http://www.aws-blog.de/?p=2593 2017-04-01T15:59:39Z 2017-04-02T08:34:51Z Call Center Service „Amazon Connect“ mit Lambda Integration Connect ist der neue Service von AWS, in dem man einfach in der Cloud ein Call Center mit eigener Rufnummer erstellen kann. Mit einer grafischen Oberfläche kann […]

Der Beitrag Call Center Service „Amazon Connect“ mit Lambda Integration – Alles möglich? erschien zuerst auf tecRacer Amazon AWS Blog.

]]>
Call Center Service „Amazon Connect“ mit Lambda Integration

Connect ist der neue Service von AWS, in dem man einfach in der Cloud ein Call Center mit eigener Rufnummer erstellen kann. Mit einer grafischen Oberfläche kann man dann mit wenig Programmierkenntnissen eigene telefonische Abläufe erstellen, Anrufe auf S3 aufzeichnen, Statistik über Cloudwatch machen usw..

Alle telefonischen Agenten können vollständig mit einem Browser und Rechner ohne Telefonanschluss arbeiten. Hier stellen wir im Beispiel, vor wie Connect mit eigenen Lambda Funktionen zusammenarbeitet.

Dabei kann komplett dynamische Abläufe in der Anrufbehandlung erstellen. In Kürze wird dies mit Amazon lex auch mit tatsächlicher natürlicher Sprachsteuerung, also gesprochene Wörter möglich sein. Im Moment muss man immer noch auf Tastendrücke zurückgreifen.

In kurzer Zeit kann man Call Funktionen wie folgende in der Cloud realisieren:

Ein Anrufer mit Basis Support im Beispiel:

 

Contact Flows in Connect

Innerhalb von Connect wird der Anrufen durch Contact Flows geführt. Diese ermöglichen z.B. Zuweisung von Anrufern zu Agenten nach bestimmten Eingaben. Für komplexe Abläufe kann man Eingaben, die der Anrufen über das Telefon macht an Lambda Funktionen weiterleiten. Hier können dann komplexe Abfragen durchgeführt werden.

Anwendungsfall

Im Beispiel gibt der Kunde seine Kontonummer ein. In der Simulation ermittelt lambda aus der Kontonummer den Supportlevel. Der Rückgabewert steuert dann die weiteren Ansagen. In einem echten Szenario könnte man dann den Kunden je nach Support an verschiedene Bearbeiter weiterleiten.

Realisierung in der Übersicht

 

  1. Callcenter mit Connect aufbauen
  2. Deutsche Einwahlnummer claimen
  3. Eigenen Contact Flow erstellen
  4. Lambda Funktion erstellen
  5. Test

Voraussetzung

 

  1. AWS Account – eine Anleitung zu Erstellung eines AWS Account kann man hier finden.
  2. Installiertes node, Node kann über die Node Webseite runtergeladen werden.
  3. Installiertes serverless Framework, siehe Serverless Webseite
  4. AWS Credentials für Serverless einrichten, siehe Serverless Dokumentation

Callcenter mit Connect aufbauen

Connect versteckt sich in der AWS Console unter dem Punkt „Call Center:

Unter der Funktion „Claim a Number“ kann man für DID „Direct Inward Dailing“ einfach eine deusche Einwahlnummer bekommen.

Für diese Einwahlnummer kann man nun Contact Flow verbinden. Wir bauen hier im Beispiel einen eigenen Contact Flow. Zuerst sollte man die Sprache mit Set Voice auf Deutsch stellen. Beide deutschen Stimmen von Amazon Polly stehen zur Verfügung. Auch eine Sprachweiche könnte man dazu erstellen.

Danach kann man eine Ansage in der gewählten Sprache mit Play prompt ausgeben. Jetzt könnte man schon eine Lambda Funktion bauen, die mit der Einwahlrufnummer Berechnungen durchführt. In unserem Beispiel wird zuerst eine vierstellige Kontonummer mit „Store Customer Input“ eingegeben:

Der Input wird auf 4 Ziffern begrenzt, die der Kunde mit der Telefontasten eingibt..

Aufruf der Lambda Funktion

Die Eingabe wird dann in eine Lambda Funktion übergeben. Dazu stellt man unter key ein, wie der Parameter heißt, den Lambda dann als Input bekommt. Im Beispiel wird account innerhalb der Lambda Eingangsdatenstruktur als Parameter übergeben:

 "Parameters": {
            "account": "5678"
        }

In der Funktion ARN wird die ARN der Lambda Funktion eingetragen.

Lambda gibt dann als servicelevel einen „berechneten String zurück:

  if( account == "5678"){
    level = "premium";
  };

  callback(null, { servicelevel : level });
In dem Contact Flow kann dann eine Weiche entsprechend dem Lambda Rückgabewert eingebaut werden:
Im einfachsten Fall verweist man auf verschiedene Ansagen.

Lambda Funktion mit Serverless einfach erstellen

Jetzt muss man noch eine Lambda Funktion erstellen, die die eigentliche Berechnung macht.

Mit den beiden Dateien im Anhang kann die Lambda Funktion mit einer Kommandozeile erzeugt werden:

sls deploy

Dabei ist sls die Abkürzung für Serverless. Die ARN der erzeugten Funktion wird wie oben beschrieben im Connect eingetragen.

'use strict';
module.exports.hello = (event, context, callback) => {
  var account = event.Details.Parameters.account;
  var level = 'none';
  if( account == "1234"){
    level = 'basis';
  };
  if( account == "5678"){
    level = "premium";
  };

  callback(null, { servicelevel : level });

};

Die Lambda Funktion besteht aus wenigen Zeilen:

Aus der Eingabe in event wird die Nummer aus account ausgelesen. Ein „berechneter“ Wert wird dann als servicelevel zurückgegeben. Durch den ersten Parameterwert null im Callback wird die fehlerfreie Ausführung angezeigt. Um zu wissen, welche Struktur die Eingabe Json hat, empfiehlt es sich, zuerst ein console.log(JSON.stringify(event))  einzubauen. Mit der im cloudwatch log ausgegebenen Struktur kann man dann weiter entwickeln.

Serverless Konfiguration

Bei der serverless Konfiguration haben wir ein kleines Henne Ei Problem: Zuerst muss die Lambda Funktion „connect-supportlevel-dev-hello“ erzeugt werden, damit die LambdaInvokePermission keinen Fehler wirft.

Diese lambda function policy ist notwendig, damit der connect service mit dem principal connect.amazonaws.com diese Lambda Funktion aufrufen darf.

Daher muss man die Zeilen 16-24 vor dem ersten sls deploy auskommentieren (mit „#“) , dann wieder einkommentieren und sls deploy erneut ausführen. Das geht natürlich auch noch eleganter.

 

Weitere Einsatzmöglichkeiten

Durch Lambda hat man Zugriff auf alle möglichen Szenarien, auch im Backend. Denkbar sind unter anderem:

  • Sprachausgabe eines Status, z.B. von Bestellungen
  • Ermitteln der Kundendokumente, während der Kunde sich noch ein paar Sätze anhört
  • Runterfahren von EC2 Instanzen sprachbasiert (gesehen auf einem chinesischem Blog!)

Was sind Ihre Ideen für die Einsatzgebiete?

Anhang:

Dateien:

Die Node Funktion: handler

Serverless Konfiguration:

service: connect-supportlevel 

provider:
  name: aws
  runtime: nodejs4.3
  stage: dev
  region: us-east-1
  ## Hier Account ID einsetzen
  account: 12345678

functions:
  hello:
    handler: handler.hello

resources:  
  Resources:
    LambdaInvokePermission: 
      Type: "AWS::Lambda::Permission"
      Properties: 
        FunctionName: "connect-supportlevel-dev-hello"
        Action: "lambda:InvokeFunction"
        Principal: "connect.amazonaws.com"
        SourceAccount: 
          Ref: "AWS::AccountId"

Lambda Funktion Policy:

{
 "Version": "2012-10-17",
 "Id": "default",
 "Statement": [
 {
 "Sid": "connect-supportlevel-dev-LambdaInvokePermission-xxxxxxx",
 "Effect": "Allow",
 "Principal": {
 "Service": "connect.amazonaws.com"
 },
 "Action": "lambda:InvokeFunction",
 "Resource": "arn:aws:lambda:us-east-1:xxxx:function:connect-supportlevel-dev-hello",
 "Condition": {
 "StringEquals": {
 "AWS:SourceAccount": "xxxxxxx"
 }
 }
 }
 ]
}

 

Der Beitrag Call Center Service „Amazon Connect“ mit Lambda Integration – Alles möglich? erschien zuerst auf tecRacer Amazon AWS Blog.

]]>
0
Sven Ramuschkat <![CDATA[AWS Organizations Mail bei Umstellung auf „All Features“]]> http://www.aws-blog.de/?p=2589 2017-03-14T17:31:57Z 2017-03-14T17:31:57Z AWS Organizations ist ja nun seit Ende Februar verfügbar. (siehe auch hier im AWS Blog) Wenn man einen bestehenden Consolidated Billing „Master Account“ umstellen möchte auf „All Features“ … damit ist gemeint auch die Möglichkeit […]

Der Beitrag AWS Organizations Mail bei Umstellung auf „All Features“ erschien zuerst auf tecRacer Amazon AWS Blog.

]]>
AWS Organizations ist ja nun seit Ende Februar verfügbar. (siehe auch hier im AWS Blog) Wenn man einen bestehenden Consolidated Billing „Master Account“ umstellen möchte auf „All Features“ … damit ist gemeint auch die Möglichkeit von Service Control Policy für die Unter-Accounts … dann versendet AWS an JEDEN Unter-Account folgende Mail und braucht von jedem Unter-Account eine entsprechende Freigabe, erst danach wird der „Master Account“ auf „all Features“ umgestellt.

 

Der Beitrag AWS Organizations Mail bei Umstellung auf „All Features“ erschien zuerst auf tecRacer Amazon AWS Blog.

]]>
1
Uwe Strahlendorf <![CDATA[Filter mit AWS CLI – effizient und hilfreich]]> http://www.aws-blog.de/?p=2583 2017-03-13T17:04:02Z 2017-03-13T17:04:02Z Das die AWS CLI ein mächtiges und sehr hilfreiches Tool für die Kontrolle und das Monitoring einer Infrastruktur in AWS ist, ist allgemein bekannt. Oft hindern die vorhandenen umfangreichen Optionen und deren korrekter Syntax zur […]

Der Beitrag Filter mit AWS CLI – effizient und hilfreich erschien zuerst auf tecRacer Amazon AWS Blog.

]]>
Das die AWS CLI ein mächtiges und sehr hilfreiches Tool für die Kontrolle und das Monitoring einer Infrastruktur in AWS ist, ist allgemein bekannt. Oft hindern die vorhandenen umfangreichen Optionen und deren korrekter Syntax zur Ermittlung des gesuchten Ergebnisses eine häufigerer Nutzung der AWS CLI im täglichen Betrieb.
In diesem Artikel wird gezeigt, wie durch den Einsatz des Parameters ’–filter’  häufig wiederkehrende Fragestellungen in Zusammenhang mit EC2 Instanzen effizient beantwortet werden können.

Die gezeigten Kommandos beziehen sich dabei auf die Filterung der Ausgabe von „aws ec2 describe-*“.

Beispiel für Fragestellungen:

Liste aller EC2 Instanzen in einer bestimmten Availability Zone.

aws ec2 describe-instances --filter Name="availability-zone",Values="us-east-1b"

Liste aller EC2 Instanzen mit einem bestimmten Tag.

aws ec2 describe-instances --filter "Name=tag-key,Values=Name" "Name=tag-value,Values=string"

Auch die Nutzung eines Wildcards(‚*‘) in „Values“ ist zulässig, ebenso wie die Verwendung von mehreren Filter-Kriterien.

Eine Liste von weiteren nützlichen Filter-Kommandos ist hier zu finden: How to use AWS CLI ‘–filter’ parameter

Anmerkungen:

  • Beim Parameter ‚–filter‘ erfolgt die Arbeit der Filterung auf der Server-Seite, sprich bei AWS. Im Gegensatz zum Parameter ‚–query‘, der auf der Client-Seite abgearbeitet wird.
  • Die Parameter ‚–filter‘ und ‚–query‘ können in einem Kommando kombiniert werden
  • Der Parameter ‚–filter‘ steht bei einigen CLI Komponenten zur Verfügung, Details sind in der Dokumentation unter „Command Reference“ nachzulesen.

Der Beitrag Filter mit AWS CLI – effizient und hilfreich erschien zuerst auf tecRacer Amazon AWS Blog.

]]>
0
Sven Ramuschkat <![CDATA[AWSome Days 2017 mit tecRacer in Köln – München – Berlin – Hamburg – Stuttgart – Dortmund]]> http://www.aws-blog.de/?p=2579 2017-03-10T15:39:52Z 2017-03-10T15:39:52Z Die Cloud Roadshow ist zurück in Deutschland – für Startups, Mittelstand und Großunternehmen. Von Ende März bis Anfang April in sechs unterschiedlichen Städten in Deutschland in Ihrer Nähe. Lernen Sie die AWS Cloud kennen und […]

Der Beitrag AWSome Days 2017 mit tecRacer in Köln – München – Berlin – Hamburg – Stuttgart – Dortmund erschien zuerst auf tecRacer Amazon AWS Blog.

]]>
Die Cloud Roadshow ist zurück in Deutschland – für Startups, Mittelstand und Großunternehmen.

Von Ende März bis Anfang April in sechs unterschiedlichen Städten in Deutschland in Ihrer Nähe.

Lernen Sie die AWS Cloud kennen und nutzen Sie jetzt die kostenfreien Weiterbildungsmöglichkeiten von Amazon Web Services. Sie lernen unsere Lösungen kennen, die u.a. die Bereiche Computing, Storage, Datenbank und Netzwerk abdecken. Melden Sie sich jetzt an, die Plätze sind begrenzt!

tecRacer ist natürlich Sponsor und gestaltet den inhaltlichen Teil jeweils ab 11:00 Uhr bis zum Schluß!

Weitere Infos und Anmeldung

Der Beitrag AWSome Days 2017 mit tecRacer in Köln – München – Berlin – Hamburg – Stuttgart – Dortmund erschien zuerst auf tecRacer Amazon AWS Blog.

]]>
0
Sven Ramuschkat <![CDATA[Technische Details & Hintergründe zu den S3 Problemen am 28.2.2016 in Virginia]]> http://www.aws-blog.de/?p=2572 2017-03-04T10:10:53Z 2017-03-02T17:38:37Z „At 9:37AM PST, an authorized S3 team member using an established playbook executed a command which was intended to remove a small number of servers for one of the S3 subsystems that is used by […]

Der Beitrag Technische Details & Hintergründe zu den S3 Problemen am 28.2.2016 in Virginia erschien zuerst auf tecRacer Amazon AWS Blog.

]]>
„At 9:37AM PST, an authorized S3 team member using an established playbook executed a command which was intended to remove a small number of servers for one of the S3 subsystems that is used by the S3 billing process. Unfortunately, one of the inputs to the command was entered incorrectly and a larger set of servers was removed than intended. The servers that were inadvertently removed supported two other S3 subsystems.“ … mehr dazu hier: https://aws.amazon.com/de/message/41926/

Der Beitrag Technische Details & Hintergründe zu den S3 Problemen am 28.2.2016 in Virginia erschien zuerst auf tecRacer Amazon AWS Blog.

]]>
0
Sven Ramuschkat <![CDATA[Tim Cook as Fan of the Digital Concert Hall powered by AWS]]> http://www.aws-blog.de/?p=2565 2017-02-13T11:06:26Z 2017-02-13T11:05:49Z As part of his current trip to Europe, Apple’s CEO Tim Cook also visited the Berliner Philharmoniker. He was particularly interested in the Digital Concert Hall, which can be accessed via apps for iPhone, iPad […]

Der Beitrag Tim Cook as Fan of the Digital Concert Hall powered by AWS erschien zuerst auf tecRacer Amazon AWS Blog.

]]>
As part of his current trip to Europe, Apple’s CEO Tim Cook also visited the Berliner Philharmoniker. He was particularly interested in the Digital Concert Hall, which can be accessed via apps for iPhone, iPad and Apple TV, among others. You can find out more in our video report.

AWS Success Story über die Digital Concert Hall unter Mitwirkung von tecRacer:

https://aws.amazon.com/de/solutions/case-studies/bph/

Der Beitrag Tim Cook as Fan of the Digital Concert Hall powered by AWS erschien zuerst auf tecRacer Amazon AWS Blog.

]]>
0